4 ms·

K3s is definitely more lightweight than K8s, but it still requires non-negligible resources. Compared to just a Docker engine, it takes more memory and CPU, whi

K3s is definitely more lightweight than K8s, but it still requires non-negligible resources. Compared to just a Docker engine, it takes more memory and CPU, which can be noticeable on smaller servers, Raspberry Pi, and such.

StavrosK 6y ago
Ah, I see, thank you. Sounds like just manually starting docker-compose stuff will be preferable right now.
- tinco 6y ago
  I'd make systemd unit files around the docker-compose deployments. Upload everything with something like Ansible. If you want to go perfect go for NixOS instead, but that might be controversial.
  - StavrosK 6y ago
    Doesn't Compose take care of that with "restart: always"? Though that probably doesn't work on reboot...
    - 0_gravitas 6y ago
      It does!
    - easton 6y ago
      "restart: always" and "restart: unless-stopped" both work fine after reboot on my system. (Although Docker recommends managing it using systemd or upstart if you want more granular control). https://docs.docker.com/config/containers/start-containers-automatically/ https://docs.docker.com/config/containers/start-containers-a...
      - StavrosK 6y ago
        This is for Docker, right? Not Compose? Though I guess Compose would just set the flag in Docker, in which case it'd do the same thing. I don't want more granularity than "unless stopped", basically, so this is ideal, thanks!
        mldbk 6y ago
        Docker-compose is just a wrapper by itself. It just make volumes, port forwarding, etc based what you you will describe in your docker-compose file. So if you have proper Docker installation, containers will restart on reboot.
  - 3np 6y ago
    I think the main question is: do you need orchestration? Ie scheduling workloads dynamically to different machines. If yes, then ks/Nomad/Swarm. If no and you want minimal overhead then the above is the answer. I’d also suggest Podman as a Docker alternative, especially for these scenarios. Images and Dockerfiles (and many commands) are 1-to-1 compatible but there are some nice things especially with this scenario. I wouldn’t say NixOS is controversial, at all, but it’s a very steep learning curve.
- neurostimulant 6y ago
  Docker compose is certainly enough for personal use, but if you ever want your apps to be available during update process (on docker compose you'll have to shut down your app container before you can update it), it's very easy to setup a basic blue/green deployment using the readiness probe option in kubernetes. Also, kubernetes load balancer is pretty easy to setup and plays well with multiple services and letsencrypt. On docker compose, I'll have to either use nginx and update it everytime I add more apps or use something like traefik if I want a load balancer that can read configuration from app's label. On kubernetes you simply specify several lines of ingress definition in your yaml file, which is not too complex for a typical app.
alexellisuk 6y ago
K3s needs 500MB of RAM on a server and 50MB on an agent. That's the lowest we've ever seen for Kubernetes and Darren is planning on getting something working on 256MB SoC devices next. If you want to go ultra-lean, and only need a single node RPi or VPS (many applications don't need massive scale-out) then take a look at what we've been building with "faasd" and containerd - https://github.com/openfaas/faasd https://github.com/openfaas/faasd

StavrosK 6y ago

Ah, I see, thank you. Sounds like just manually starting docker-compose stuff will be preferable right now.

tinco 6y ago
I'd make systemd unit files around the docker-compose deployments. Upload everything with something like Ansible. If you want to go perfect go for NixOS instead, but that might be controversial.
- StavrosK 6y ago
  Doesn't Compose take care of that with "restart: always"? Though that probably doesn't work on reboot...
  - 0_gravitas 6y ago
    It does!
  - easton 6y ago
    "restart: always" and "restart: unless-stopped" both work fine after reboot on my system. (Although Docker recommends managing it using systemd or upstart if you want more granular control). https://docs.docker.com/config/containers/start-containers-automatically/ https://docs.docker.com/config/containers/start-containers-a...
    - StavrosK 6y ago
      This is for Docker, right? Not Compose? Though I guess Compose would just set the flag in Docker, in which case it'd do the same thing. I don't want more granularity than "unless stopped", basically, so this is ideal, thanks!
      - mldbk 6y ago
        Docker-compose is just a wrapper by itself. It just make volumes, port forwarding, etc based what you you will describe in your docker-compose file. So if you have proper Docker installation, containers will restart on reboot.
- 3np 6y ago
  I think the main question is: do you need orchestration? Ie scheduling workloads dynamically to different machines. If yes, then ks/Nomad/Swarm. If no and you want minimal overhead then the above is the answer. I’d also suggest Podman as a Docker alternative, especially for these scenarios. Images and Dockerfiles (and many commands) are 1-to-1 compatible but there are some nice things especially with this scenario. I wouldn’t say NixOS is controversial, at all, but it’s a very steep learning curve.
neurostimulant 6y ago
Docker compose is certainly enough for personal use, but if you ever want your apps to be available during update process (on docker compose you'll have to shut down your app container before you can update it), it's very easy to setup a basic blue/green deployment using the readiness probe option in kubernetes. Also, kubernetes load balancer is pretty easy to setup and plays well with multiple services and letsencrypt. On docker compose, I'll have to either use nginx and update it everytime I add more apps or use something like traefik if I want a load balancer that can read configuration from app's label. On kubernetes you simply specify several lines of ingress definition in your yaml file, which is not too complex for a typical app.

alexellisuk 6y ago

K3s needs 500MB of RAM on a server and 50MB on an agent. That's the lowest we've ever seen for Kubernetes and Darren is planning on getting something working on 256MB SoC devices next. If you want to go ultra-lean, and only need a single node RPi or VPS (many applications don't need massive scale-out) then take a look at what we've been building with "faasd" and containerd - https://github.com/openfaas/faasd https://github.com/openfaas/faasd