> If you need granular control over every tiny aspect of your container orchestration — network policies, pod scheduling, resource quotas, multi-tenant isolation, custom admission controllers, autoscaling on custom metrics — Kubernetes gives you knobs for all of it. > The problem is that 99% of teams don't need any of those knobs. I keep hoping for a Docker Swarm revival. It's the right size for small-to-medium-size…
Docker Swarm vs. Kubernetes in 2026
21–30 of 31 posts
Re: Docker Swarm vs. Kubernetes in 2026
#22Kubernetes solves real problems for the 1% who need it. The other 99% are paying a massive complexity tax for capabilities they never use, while 87% of their provisioned CPU sits idle. is where the author is just wrong: - abstracts away ssh - makes it pretty unnecessary - rbac multi tenancy - better automations - orchestating more than one cluster - better infra as code - provisions are as good as you make them, if y…
The author claimed cert-manager as inherent k8s overhead (its not) but then didn't mention certificate management with docker swarm at all. They lost me there.
Re: Docker Swarm vs. Kubernetes in 2026
#23Kubernetes solves real problems for the 1% who need it. The other 99% are paying a massive complexity tax for capabilities they never use, while 87% of their provisioned CPU sits idle. is where the author is just wrong: - abstracts away ssh - makes it pretty unnecessary - rbac multi tenancy - better automations - orchestating more than one cluster - better infra as code - provisions are as good as you make them, if y…
The author claimed cert-manager as inherent k8s overhead (its not) but then didn't mention certificate management with docker swarm at all. They lost me there.
And the docker swarm example didn’t even accomplish the same thing.
Re: Docker Swarm vs. Kubernetes in 2026
#24Can you control the docker swarm API from within a container that is running inside of it? I think one of the killer features of k8s is how simple it is to write clients that manipulate the cluster itself, even when they’re running from inside of it. Give them the right role etc and you’re done. You don’t even have to write something as complete as an actual controller/operator - but that’s also an option too
You can. I think there's a couple approaches - bind mount the docker socket, or expose it on localhost, and use host networking for the consuming container, or there exist various proxy projects for the socket. There may be other ways, curious if anyone else knows more.
Bind-mounting /var/run/docker.sock gives 100% root access to anyone that can write it. It's a complete non-starter for any serious deployment, and we should not even consider it at any time.
Re: Docker Swarm vs. Kubernetes in 2026
#25Earlier quoted context omitted.
The author claimed cert-manager as inherent k8s overhead (its not) but then didn't mention certificate management with docker swarm at all. They lost me there.
I agree. Honestly, this overhead doesn't exist in practice. I've never even checked what's inside cert-manager namespace, it gets deployed for every new cluster, it works, someone automated this, now who cares.
Re: Docker Swarm vs. Kubernetes in 2026
#26https://k3s.io/ is my new goto for this Docker Swarm doesn't have the mindshare for effective hiring
Not a fan of their curl -sfL https://get.k3s.io | sh - installation method. Kind, on the other hand, has multiple installation methods, including via wget for their binary: https://kind.sigs.k8s.io/docs/user/quick-start/#installing-f... .
Re: Docker Swarm vs. Kubernetes in 2026
#27K3s + FluxCD. There's something nice about using git to add a helm repo, a helm release with a few values, then 'git push'. Shortly afterwards there's a new DNS record, TLS cert and I can hit https://mynewservice.example.com
Re: Docker Swarm vs. Kubernetes in 2026
#28> If you need granular control over every tiny aspect of your container orchestration — network policies, pod scheduling, resource quotas, multi-tenant isolation, custom admission controllers, autoscaling on custom metrics — Kubernetes gives you knobs for all of it. > The problem is that 99% of teams don't need any of those knobs. I keep hoping for a Docker Swarm revival. It's the right size for small-to-medium-size…
ECS Fargate is basically this on AWS. It’s just not cloud agnostic. But Swarm itself while being cloud agnostic is a proprietary product as well, so you still get the lock in, just at a different layer
Re: Docker Swarm vs. Kubernetes in 2026
#29K3s + FluxCD. There's something nice about using git to add a helm repo, a helm release with a few values, then 'git push'. Shortly afterwards there's a new DNS record, TLS cert and I can hit https://mynewservice.example.com
Re: Docker Swarm vs. Kubernetes in 2026
#30Earlier quoted context omitted.
You can. I think there's a couple approaches - bind mount the docker socket, or expose it on localhost, and use host networking for the consuming container, or there exist various proxy projects for the socket. There may be other ways, curious if anyone else knows more.
That's not even close to the same as a well thought out rbac system, sorry.
The question didn't ask about RBAC, well thought out or not.