Hacker News Reader

Comment by jjeaff | Hacker News Reader

The thing that all the "you don't need kubernetes" articles seem to ignore or skim over, is the huge network effect of a popular setup like k8s.

Not only is it much easier to find services (like helm) and articles for k8s, but there are so many ready to go configurations. For most major services, there is already a ready to go helm chart or at least some well vetted yml config on GitHub to start from.

And most any issue I have come across, I have been able to search and find solutions.

View on HN

The thing the 'there's a ready to go helm chart' folks always seem to skim over is that outside of an absolute startup position where you can curlbash to hello world heaven, you will have integration to do, often huge amounts of customization (read: complete rebuild) to do to take a toy helm app configuration to a production configuration, and I've never seen even so much as a nascent k8s (or nomad, mesos, etc.) buildout leveraged in a preexisting environment without quite a bit of pipeline, acl/naming convention and ux glue.

The proliferation of operators, CRDs, things like k3s and the growing ecosystem of vendor distributions makes 'stock k8s' an increasingly nebulous target.

I think CRDs are mostly going to be a quagmire. It's Wordpress plugins all over again, if Wordpress plugins could also affect the OS kernel.

Haven't looked into helm-charts deeply, but the ones that I found often needed a considerable amount of time to configure for production. For example, the Logstash chart uses a YAML config whereas we use Logstash's standard config format with many filters and options. Porting these features over to YAML is not a lot of fun. And in the end we would also have to maintain these configs and keep them in sync with upstream changes.

Speaking of documentation, I sometimes feel a bit overwhelmed by the amount of literature on Kubernetes these days. Many articles are quite outdated already and new ones get written every day. It's hard to know what the best practices are - and the ecosystem is still rapidly evolving.

So I don't think I was skimming over these parts, I just think that inertia can also become a disadvantage.

As well as hiring engineers who will be familiar with it from day 1, as opposed to having to learn whatever custom system you use.

This. In a perfect world, it should be more useful to say to an employer, "I know Kubernetes" than "I know AWS". It's a unified abstraction for cloud resources. They all, more or less, do the same thing. Why learn the proprietary, vendor-specific way to do it, when you learn it once, and apply your knowledge to any cloud, e.g, if you switch jobs and your new one uses a different cloud provider.

Unfortunately, Kubernetes isn't a unified abstraction, because vendor-managed Kubernetes setups are not very similar (to each other, or to an unmanaged solution). Somebody who "knows Kubernetes" but has only worked with GKE will not be very well prepared to operate a bare-metal Kubernetes cluster.

In my experience, pods, deployments, and load balancers work similarly enough to not cause any discernible problems (with basic web application processes, like a Dockerized Node.js server) on AWS, GKE, and Digital Ocean. But that's only my experience, and there are more managed offerings than just those few. Even if it's not fully unified, it's unified enough for the use case of basic scaling of a process up/down.

And, if you'll indulge me here, I was referring mostly to managed k8s offerings. Because that's what the vast majority of people would use, if they chose to go in on k8s at all and want to get out the door quickly.

Reply on news.ycombinator.com