Docker Swarm vs. Kubernetes in 2026
thedecipherist.com
Docker Swarm vs. Kubernetes in 2026
1–10 of 31 posts
Re: Docker Swarm vs. Kubernetes in 2026
#2> 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 deployments with normal requirements.
Re: Docker Swarm vs. Kubernetes in 2026
#3Kubernetes 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 you don't want them only use limits.
- large mind share, bitnami (was) great
I use k3s for my home network because it's simple and easy, thinking that k8s is overengineered just plain wrong - it's just different especially if you compare different versions of k8s designed for different things where for ex: k3s bundles csi, cni, ctl, ingress for you.
I actually struggle with compose ('orchestration' alternative) significantly more since it usually has complicated workarounds to missing features.
I have been running 5 k8s-flavored clusters for more than half a decade between 1 to 40 nodes.
Re: Docker Swarm vs. Kubernetes in 2026
#4> 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…
Every enterprise team (at least who are in B2B business) needs this. The number of security clearances (zero trust boundary), security compliance is must. May be in B2C space where you might not need that depending upon how secure you wanna be based on what data you hold
Re: Docker Swarm vs. Kubernetes in 2026
#5https://k3s.io/ is my new goto for this
Docker Swarm doesn't have the mindshare for effective hiring
Re: Docker Swarm vs. Kubernetes in 2026
#6Can 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
Re: Docker Swarm vs. Kubernetes in 2026
#7https://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
#8K3s + 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
#9This article is very clearly AI generated. I’d rather read the prompts next time, thanks.
Re: Docker Swarm vs. Kubernetes in 2026
#10Can 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.