I would rather sink in an ocean of kubernetes YAML documents than having to deal with Docker swarm issues ever again. Thankfully Docker swarm is kinda dead so it’s unlikely to be relevant again. Kubernetes won.

Can you elaborate on its issues? I've never used it on production myself, but it looks like a simplified k8n, which is something I feel a lot of people desire

Last used it years ago, networking would just die randomly, requiring container restarts when using multiple nodes

I have heard (though haven't tried) that V2 of Compose/Swarm is significantly better.

Anything can and will break. Symptomatically similar thing happened to me with K8s with (IIRC) Calico. And I’ve had issues with Swarm too, although of a different kind (it quietly refused to run a data channel for me over an IPv6-only network, while control channel worked just fine).

It was all quite a while (3-4 years) ago, so I don’t remember much details, except that Swarm was then not exactly capable of working in IPv6-only environments. It was significantly easier to navigate Docker’s codebase than Kubernetes’.

Ultimately, my solution was that I understood that I didn’t need any kind of orchestration there, just HA/failover.

I've been very happy with until now, though i must admit i'm using one node swarms. But i'd rather use that (1) than sticking together a custom solution using docker compose as i see it mentioned sometimes.

(1) https://dockerswarm.rocks/traefik/

I haven’t used it for many years but in short it just didn’t work reliably. I mostly encountered network iptables issues from memory.

Infinite issues with overlay networking once you scale past 30 nodes in a swarm. Weave aside, network drivers for anything not CNI are basically deprecated/dead.

I like what kube achieves, I don't like the power and memory hungry requirements of it, it seems ill optimized. A cluster with no pods uses 5%-15% CPU, that's a lot of electricity being used for nothing. It's really odd since Google claims to have green datacenters.

Does Google use carbon swaps to conceal their emissions? Maybe that's how they reconcile the difference.

A quick search turned up this: https://www.greencentury.com/google-parent-alphabet-pledges-...

Looks like a possible case of greenwashing to me.

Google doesn’t use kubernetes to run anything production. They use Borg

I got into an argument with someone at google who said they don't use carbon swaps and ended up pulling up a shareholder report that said they did. Google is real big on the greenwashing.

Google doesn’t run on Kubernetee.

I'm curious, are you seeing that on cloud instances, or what?

My experience with bare-metal Kubernetes hasn't been that bad. On my home cluster with very underpowered J4105 CPUs, I get about 5% CPU usage on the master node at idle, and 2% on workers.

People need to check their logs for any oddities more frequently. A lot of the setups I’ve seen have subtle misconfigurations that leak/busy loop resources needlessly

I'd bet you're running a "stacked" control plane and if you moved etcd off to its own machines you'd localize the churn to be that. Which, if correct, doesn't exactly refute your "kubernetes is power and memory hungry" claim but would more clearly distinguish why

I had high hopes back in my earlier days of them offering pluggable KV stores so folks could make tradeoffs if etcd doesn't align with their goals and risks but as best I can tell they've declared it a non-goal

That's part of what k3s does

I've actually been using docker swarm for an odroid cluster that runs a lot of services in my house. I really like it- it's extremely low overhead and the network mesh works way better than I was expecting considering I put no effort into configuring it.

That said this is a three node cluster running a handful of containers, with services accessed by my wife and I. So not exactly a large scale production experience.

As someone whose wife will immediately call me if the important services in our household (Plex, pihole, home assistant), I think those definitely count as production services!

Kubernetes won because of its composability. The API is the killer feature. The notion of objects, labels, pretty much an object oriented, declarative interface.

You'd have to do a lots of custom morphing if you want that kind of interface over docker swarm.

For smaller setups, simplicity of docker swarm might be useful but I am curious to know from people who are running clusters of 25 to 50 nodes.

> Docker swarm is simpler and superior solution to Nomad

This is the voice of absolute delusion. Swarm is a mess. Nomad actually scales.

Recent nomad versions replace lots of consul functionality. Consul is definitely not needed at small scale, even for service discovery.

With Nomad 1.3 and newer, you can run a Nomad cluster without Consul, there's support for built-in service discovery: https://www.hashicorp.com/blog/nomad-service-discovery

I am a happy swarm user for a long time now. It is pretty simple. The only complicated part was the reverse proxy, but traefik has been a solid solution.

You will spend quite some time figuring the labels out, but once you have them for one service, it works for many.

A new solution that might be even better is Kamal by 37 Signals. It runs all their production stuff, so it must be capable. Can’t wait for a version 2 where, I’d suspect, by then there will be more community contributions for some more diverse setups merged in.

Having worked with Nomad, K8s and Docker Swarm at reasonable scale, Docker Swarm is the only one of those three that I would never use again under pain of death.