|
|
|
|
|
by nimish
2950 days ago
|
|
I disagree. Kubernetes came out of Google, but has exploded in popularity due to its capability (which comes with extreme complexity): it can scale to extreme levels, but wrapping your head around it requires far more time and trouble for your most basic apps. Thus, you see the software consultants race to become the next Kubernetes experts, since choosing to deploy it essentially requires that you have dedicated professionals managing it (as Google does). Docker Swarm might be incomplete and missing quite a few features, and it won't scale to thousands of nodes with dozens of independent apps, but the use-cases I've seen are far from that. A single engineer can basically get a "good-enough" moderately scaled system going. If you have Google-scale problems with Google-caliber engineers and SREs backing you, use Kubernetes. Otherwise, using something else (Docker Swarm "just worked" for the cases I've seen) is easier. |
|
The core of Kubernetes is super simple and all the hard parts are hidden away on actually setting up and maintaining kubernetes the hard way on bare metal machines. Odds are, if you're doing that, you have the resources to take some time to dive deeper into how it works.
I've done multiple single engineer Kubernetes setups that are working on production today. So far I've had only a few problems with it. I know it's not a huge data range, but I'm not the smartest person in the world (or a true infrastructure guy) and still found it easy to work with.
Swarm has always been a rushed afterthought IMO. Although I have way less experience with it than k8s, so I'm biased on this.