Is K8s Too Complicated? 

If you follow that link on Twitter, there are a lot of reasonable answers to his (rhetorical?) question - "In a single tweet — can you name a technical benefit you and your team have gained by switching to Kubernetes?"

"Sensible configuration, fast deployments, awesome community, and flexible control plane...among others"

"single root of truth for configuration"

"predictable deploys"

"Standardized orchestration, which makes talent easier to find."

"the capability to deploy on more than one platform, more than one cloud."

"Not called in at midnight when an entire node segment went down due to hardware failure."

"The ability to deploy hundreds of services within minutes."

Even though I fully agree with you, running a little 3 node cluster just for fun is amazing. Thanks to Rook and an Nginx ingress controller with kube-lego, I’m able to deploy applications leveraging distributed storage and getting tls secured endpoints without a single ssh session. This, in my point of view, is absolutely powerful.

Shameless plug, I‘ve been working on a project explaining how to run small scale clusters in the cloud for more than a year: https://github.com/hobby-kube/guide

I'd say it's actually just a convention vs configuration argument.

Kubernetes isn't giving you anything you couldn't have already built with configuration management. It just happens to a standard written by a bunch of people with a background in the problem domain.

Personally, I think the abstractions are thoughtful and the system isn't really inherently more complicated than what you'll eventually build anyways, but as the article said, we all have a bias towards that crap we ourselves invented, because we already know how that works, and we find learning something like kubernetes a chore.

That said, I wouldn't say it's about how many servers you manage. If you have a single monolith, written and ran by a single team, it doesn't neccessairly get more complex as you throw more servers at it. But when you have several teams, writing and hosting several systems, it's nicer to have a convention framework instead of an undocumented snowflake platform.

I have to agre on your final point though. If you find running kubernetes complicated, go to GKE and treat it like you do your IaaS provider, which is more complicated but isn't something you typically deal with.

Might be, but one thing it certainly is not: worthy of yet another acronym. Call the thing by its name, kubernetes. T2t w3d be so m2h e4r to r2d.

>In a single tweet — can you name a technical benefit you and your team have gained by switching to Kubernetes?

- Continuous delivery made easier

- Code-as-infra you can deploy anywhere (Pi, GCP, AWS...)

- Ability to pack VMs tighter, viewing your cluster as a pool of resources.

Kubernetes may seem too complicated if you miss the point. It's throwing the baby out with the bathwater, but it's doing so with purpose. Kubernetes didn't become popular by accident.

The benefit is hard to explain for the same reason that it's hard to learn: it's a complicated piece of tool that solves a problem most people don't understand. That problem is scheduling. Most people view systems administration as the practice of managing machines that run programs. Google flipped the script: they began managing programs that run on clusters, probably about as early as any other company, if not earlier.

The key insight here is that with Kubernetes, you are free from the days of SSHing into machines, apt-get installing some random things, git cloning stuff, and setting up some git hook for deployments. No matter how much more advanced your process is, whether you have God's gift of a Chef script, or you have the greatest Terraform setup in the world, you're still managing boxes first, and applications second, in the traditional model. You have to repeat the same song and dance every time.

To be fair, Kubernetes is not the only platform to provide this sort of freedom. Obviously, it's based on Google's famous Borg, and Docker Swarm also exists in this realm, as well as Apache Mesos. I think Kubernetes is winning because it picked the right abstractions and the right features to be part of itself. Docker Swarm did not care enough about the networking issues that came with clustering until recently. Specifically, one of the first problems becomes "What if I need multiple applications that need to be exposed on port 80?" Kubernetes IMMEDIATELY decided that networking was important, providing pods and services with their own IP addresses first thing, including LoadBalancer support early on. In my opinion, pods and services are the sole reason why Kubernetes crushed everything else, and now that other solutions are catching up and implementing better abstractions, and other solutions for networking are appearing, the problem now is the massive headstart Kubernetes had. Kubernetes let you forget about managing ports the same way you forget about managing machines. Docker Swarm wasn't offering that.

Yeah, it took a few paragraphs to explain why it makes sense, but once you "get" it, it's hard to unget.

That does not mean that Kubernetes is not too complicated. It's probably way too complicated for most of us, and a lighter solution with similar properties would be fine. But that doesn't mean the complexity is all a waste; it's just not useful to all of us.