Re:Google admits Kubernetes container tech is too complex
by stewartmcgown on Friday February 26, 2021 @06:03AM
(#26273541)
Absolutely. We use Swarm in production at ecoeats and it's a dream for simple clustering with multiple services. Using Hetzner clouds volume plugin gives EBS-like functionality too.
Re:Google admits Kubernetes container tech is too complex
by rigrassm on Friday February 26, 2021 @02:29PM
(#26278802)
> Nomad's read-only Web UI,
Nomad's UI has a good number of functionalities that can be controlled through it. Sure, there are some more lower level operations that are CLI only(though this seems to be something they are actively working to improve on) but most of that probably won't be needed but someone just trying to run a couple containers on a single node.
Re:Google admits Kubernetes container tech is too complex
by KronisLV on Friday February 26, 2021 @07:50AM
(#26274234)
Correction:
> Swarmpit and Podman
I actually meant Swarmpit ( https://swarmpit.io/ ) and Portainer ( https://www.portainer.io/ ).
Podman is another container runtime that acts as an alternative to Docker (even if it is not feature complete), so i misspoke.
Re:Google admits Kubernetes container tech is too complex
by drewlander on Friday February 26, 2021 @09:00AM
(#26274791)
We use swarm for a small cluster in production a well. Extremely easy, zero downtime deployments are fantastic. I can explain it to someone else and quickly get them up to speed.
Having said that, the fact that it seems to be on life support has made me look at other alternatives, even a simple docker-compose per node.
Re:Google admits Kubernetes container tech is too complex
by alephu5 on Friday February 26, 2021 @08:35AM
(#26274586)
I quite like swarm for its compatibility with docker-compose, in particular to have the option of zero downtime deploys. If I wanted to manage a real cluster though I'd probably use nomad or GKE to avoid getting burned when the system is under load.
Hashicorp's Nomad is good if you have a strong engineering department or need to run mixed workloads (e.g. both containers and native processes) because its abstractions are well suited for this, but HCL, their DSL for describing deployments, doesn't map nicely to neither Docker, nor Docker Compose files, knowledgebases or tutorials. Nomad's integration with Consul is a major boon, but the need to run your own CA for safe communication between nodes, Nomad's read-only Web UI, and the oddity of HCL at times also makes it a non starter for me and some other people.
At the end of the day, these are just two data points, sadly the job market for Kubernetes also dwarfs everything else and sadly many companies will be burned by this and will learn nothing at the end of the day. Ideally, i think that the best route would be evaluating the orchestrators and other technologies that you want to use by doing pilot projects and such, and looking at them in real world circumstances, to determine their fit for your goals and needs (Web UIs will matter for some, but not for others, for example; as will onboarding and the need for long term investment vs plug and play).
Edit: as for Kubernetes, personally i find the K3s distribution to be an almost reasonable alternative to Swarm/Nomad, if the situation calls for it: https://k3s.io/
Edit #2: it would actually be pretty awesome to read more about your experience in this article that you're writing!