Docker swarm is to Kubernetes what SQLite is to PostgreSQL. To some extent.
My docker swarm config files are nearly the same craziness as my k3s config files so I figured I might as well benefit from the tooling in Kubernetes.
Edit for more random thoughts: being able to use helm to deploy services helped me switch to k3s from swarm.
IMO a sufficiently advanced Docker Compose stack is not appreciably simpler than the Kubernetes manifests would be, and you don't get the benefits of Kubernetes' objects and their controllers because Docker Compose is basically just stringing low-level concepts together with light automation.
That's system configuration and that'll become tedious for sure.
In my opinion, the complexity is symptomatic of success: once you make a piece of some kind of seemingly narrowly focused software that people actually use, you wind up also creating a platform, if not a platform-of-platforms, in order to satisfy growth. Kubernetes can scale for that business case in ways Docker Swarm, ELB, etc. do not.
Is system configuration avoidable? In order to use AWS, you have to know how a VPC works. That is the worst kind of configuration. I suppose you can ignore that stuff for a very long time, you'll be paying ridiculous amounts of money for the privilege - almost the same in bandwidth costs, transiting NAT gateways and all your load balancers, whatever mistakes you made, as you do in compute usage. Once you learn that bullshit, you know, Kubernetes isn't so tedious after all.
I'm not sure what to say here. The kubernetes docs and code speak for themselves. If you actually think that it's clean, simple, well designed, and easy to operate, with smooth interop between the parts, I can't change your mind. But in practice, I have found it very unpleasant. It seems this is common, and the usual suggestion is to pay someone else to operate it.
Also I never said Kubernetes was well-designed, easy, or simple.
There's no one size fits all approach. There are trade offs. The Kubernetes tractor needs lots of oiling and what not for all the bells and whistles.
Trade offs is the keyword here.
I see more risk of docker engine as a whole pulling some terraform/elastic search licensing someday as investors get desperate to cash out.
Docker is just one of many implantations of the Open Container Initiative (OCI) specifications. It’s not even fully open source at this point.
Under the hood Docker leverages containerd which in tern leverages runc which leverages libcontainer for spawning processes.
Linux containers at this point will exist perfectly fine if Docker as a corporate entity disappears. The most impact that would be felt would be Dockerhub being shutdown.
They also sort of already did pull something like Hashicorp with their Docker Desktop product for MacOS.
That’s a little different than if Docker disappeared completely, but one could easily switch to Podman (which has a superset of the docker syntax).
How so? I know Docker Desktop wraps its own stuff around docker, but AFAIK docker itself is FOSS.
Personally, I'd also consider throwing Portainer in there, which gives you both a nice way to interact with the cluster, as well as things like webhooks: https://www.portainer.io/
With something like Apache, Nginx, Caddy or something else acting as your "ingress" (taking care of TLS, reverse proxy, headers, rate limits, sometimes mTLS etc.) it's a surprisingly simple setup, at least for simple architectures.
If/when you need to look past that, K3s is probably worth a look, as some other comments pointed out. Maybe some other of Rancher's offerings as well, depending on how you like to interact with clusters (the K9s tool is nice too).
A better approach is to translate business requirements to systems capabilities and evaluate which tool best satisfies those requirements given the other constraints within your organization.
Managed Kubernetes solutions like GKE require pretty minimal operational overhead at this point.
If Docker Swarm satisfies, then yes.
curious what do you mean? To me Postgresql doesn't have disadvantages over SQLite, everything is just better..
And that’s only the installation. Interaction with SQLite as a database is also simpler.
They both have uses but it’s strange to me to assert that they’re equally complex.
that command will create postgres user in the system, you do su to that user, run psql and you all set.
> And you’ll have to do something about upgrades as well
apt will take care of it too
> but SQLite is just a file
there is some "file" in postgresql distribution, people just don't use it, because why they would?
> Interaction with SQLite as a database is also simpler.
any specifics?
PostgreSQL definitely says no to schema violations.
These are both features.
That's where the author also has following to say:
>My conclusion at this point is that if you can afford it, both in terms of privacy/GDPR and dollarinos then managed is the way to go.
And I agree. Kubernetes managed is also really hard for those of offering it and have to manage it for you behind the scenes.[0]