Was betamax superior to VHS?
https://www.youtube.com/watch?v=_oJs8-I9WtA
Docker Swarm vs. Kubernetes in 2026
11–20 of 31 posts
Re: Docker Swarm vs. Kubernetes in 2026
#12> 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
Yeah I was trying to give the post a serious consider, but the author just flatly dismissed network policies as not needed, suggesting that we just make new overlay networks for every set of containers that need to communicate. This post really doesn't resonate with me, even though I am on a small team using k8s in a small company.
Re: Docker Swarm vs. Kubernetes in 2026
#13Can 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.
That's not even close to the same as a well thought out rbac system, sorry.
Re: Docker Swarm vs. Kubernetes in 2026
#14Kubernetes 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
#15The author here repeatedly claims that teams would function identically on Swarm and are wasting resources using Kubernetes.
You don’t even need to be a mid-sized team to need stuff like RBAC, service mesh, multi-cluster networking, etc.
Claiming that kubernetes only “won” because of economic pressure is only true in the most basic of sense, and claiming it as a resume padder is flat out insulting to all its actual technical merits.
The multi-tenant nature and innate capabilities is part economics of it, but operators, extensibility, and platform portability across different environments are actual technical merits.
Claiming that autoscaling is optional and not required for most production environments is at best myopic.
It also greatly undersells the operational complexity that autoscaling actually solves, versus just the reactive script based solely on CPU. Metrics pipelines, cluster-level resource constraints, and pod disruption budgets.
As far as the repeated claim that it just “works”, great. Not working is more of a function of the application not the platform.
I dunno, this whole article frames kubernetes as a massive overhead and monolithic beast rather than the programmable infrastructure that it is.
It also tries to minimize many real world needs like multi-team isolation, extensibility, and ecosystem integrations
Re: Docker Swarm vs. Kubernetes in 2026
#16Kubernetes 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.
[dead]
Re: Docker Swarm vs. Kubernetes in 2026
#17https://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... .
[dead]
Re: Docker Swarm vs. Kubernetes in 2026
#18https://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... .
Docs actually cover your need. There is a section that describes manual install.
> If you choose to not use the install script, you can run K3s simply by downloading the binary from our GitHub release page, placing it on your path, and executing it. https://docs.k3s.io/installation/configuration#configuration...
Re: Docker Swarm vs. Kubernetes in 2026
#19The author here repeatedly claims that teams would function identically on Swarm and are wasting resources using Kubernetes. You don’t even need to be a mid-sized team to need stuff like RBAC, service mesh, multi-cluster networking, etc. Claiming that kubernetes only “won” because of economic pressure is only true in the most basic of sense, and claiming it as a resume padder is flat out insulting to all its actual t…
> I dunno, this whole article frames kubernetes as a massive overhead
Author describes his context being a setup with two $83/year VPS instances - a scale so incredibly minuscule compared to typical deployments, that any of his arguments against one of the core cloud technologies fall flat.
Of course he doesn't need Kubernetes. It's fine.
Re: Docker Swarm vs. Kubernetes in 2026
#20Kubernetes 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.
This is the thing about kubernetes that these short sighted takes always seem to miss. Kubernetes is complicated because deployment is complicated. For every little knob in k8s there is a pretty good standard path. Need certs? Cert manager. Autoscaling? Cluster autoscaler or KEDA. Load balancing? Handled. All wheels you will need to reinvent yourself otherwise.