| I run kubernetes as... a standalone node. I run it on a dedicated server with two disks on btrfs RAID1, with a subvolume for each pod that needs it (hostPath). Not the minikube version, not the kubespray version: the kubeadm version, installed by hand and minimally tweaked (NodePorts 0-65535), with dual-stack networking support. I have ~3 tenants, 5-15 pods each, and managing this configuration with docker was a steadily increasing pain for the last few years: - I had docker-compose split-files for each service for each tenant to keep a consistent state, so I used a simple bash script to generate a really long docker-compose line to bring everything together, networking was a real pain - Dual-stack support in docker does not exist/work in compose v3 to this day, but v2 has it - Querying the configuration and state of a container was an exercise in debugging the output - For certificates, I had to run letsencrypt/certbot externally (2 tenants with separate accounts for wildcard certs), but use traefik in docker-compose (the syntax pain was on top of the rest, of course) Kubernetes simplified all the pain points above: - I still have the service split-files, but I don't care about network addresses and links between pods anymore, just their names - better isolation between all the architecture points, and clearer definition and integration - IPv4&IPv6 native just working - "describe" gets me all the information I need in a pretty format, "get type name -o yaml" if I need the configuration - standard nginx ingress + cert-manager, and I can have multiple tenants without resorting to hacks DBs are regular containers in the pod that requires them, just like any other container. Daily subvolume snapshots are small and effective to make sure the data is safe. Kubernetes is a much better orchestrator than docker compose, availability is a plus if you really need it. You don't need to build an HA control plane plus 3 workers if you have no use for it. |