Because of this, I'm forced to either use another orchestrator (Docker Swarm is lightweight enough to work on a single node or a small cluster), or pay for machines I don't really need.
What are is the current thinking on this issue at Rancher?
Because of this, I'm forced to either use another orchestrator (Docker Swarm is lightweight enough to work on a single node or a small cluster), or pay for machines I don't really need.
What are is the current thinking on this issue at Rancher?
If you have many such projects, perhaps something like Saltstack or Ansible, both of which have support for Docker container management built in.
I already use Ansible to setup machines and automate deployments.
I used systemd unit files until I switched to Docker. I don't use them anymore since dockerd supervises the container itself.
I use Docker Compose to describe the set of services composing my app and it's great.
But in production, Docker Compose is unable to provide zero-downtime deployments, and this is why I'm looking at Docker Swarm or Kubernetes.
systemd unit files are not very useful for Docker containers, and they don't solve the zero-downtime deployment issue.
Are you saying that the overhead on the worker nodes is about 10 % for the kubelet, the containerd and the logging daemons?
GKE documentation says 25 % of the first 4 GB are reserved for GKE:
https://cloud.google.com/kubernetes-engine/docs/concepts/clu...