That isn’t a lot. You could easily run that from one host. The reason people reach for Kubernetes (and similar) is because they need to scale past that single host dependency.
I have some stuff on single-node k3s. Because it's standard so I don't have to care.
It's great.
They’re multi-region, but that doesn’t mean they’re running across multiple hosts in each region.
Docker compose doesn’t support pooling multiple hosts, so if they are running multiple hosts per region then there’s a lot more complexity to their setup than they’re documenting in that blog. Even if that complexity is human toil managing each host as a separate entity.
To be fair: using Kubernetes anyways builds the skill just in case you become one of the 0.1% who actually need it down the line.
K3S takes about 5 minutes to setup the first time and you instantly have an entire universe of standardized operational tooling. I wouldn't touch docker compose with a 20 foot pole for production work.
Setting up K8s isn't rocket science, but maintaining it are offputting, to say the least.
Which is exactly what is happening with us, too bad we didn't choose K8S from the get-go and stuck with a "simpler" tool (gaining very little in the process).
This shittake was probably valid 10y ago, I would have agreed with you back then
> The entire infra the vast majority of Kubernetes users have could run on a single bare metal machine
Where are you pulling this out of? A large number of k8s users don't need it, but the alternative you have sounds hyperbolic.
sounds like ghetto engineering
But if someone wrote a blog to brag about not using k8s, they can't stop people from wanting to compare their work against k8s. If there's any arrogance in the air, it feels stronger on the other side.
EKS is literally one click of a button away and you dont need to handroll this.
even if you dont know AWS console nor terraform, claude code with aws mcp can do that for you
Out came Docker, dnsmasq, miles of duct tape and a whole lot of swearing. Just to come nowhere close to reinventing something better folks were doing years prior.
Just because you can (or think you can) doesn't mean you should. I sure do hope no one is maintaining that NIH monstrosity now!
This is pretty small scale, Kubernetes comes in when you've got a larger workload.
“We don’t know how to scale Traefik so we went with haproxy”
Well doh. Haproxy is designed for this. You can make haproxy serve copious amount of traffic on a single arm core and a little bit of ram. Imagine what you can do with a few replicas on your large clusters.
This has nothing to do with the choice of CI/CD or docker versus kubernetes.
Over the past decade, I'm seeing k8s used everywhere for everything, companies setting up clusters to run literally one simple app with couple of hundred requests per hour.
But yeah, pretty cool DNS resolving features in HAProxy, that's nifty
These are things I'm trying to figure out at work using Podman. Would love to hear about any experience in these areas.
The readme covers connection draining with Traefik which should solve one of the issues the author mentions
the site is down for me.
