Comment by movedx | Hacker News Reader

Comment by movedx | Hacker News Reader

Parent Full thread

My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?"

I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling.

I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't".

For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!"

(And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)

> For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!"

Isn't that what the managed kube offering you switched to gave you?

Managing your own kube deployment is very easy if you are only worried about that component.

> I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't"

The benift in kube isn't the cluster management. It's the abstractions. Let's say "I don't need kube." Now we need to have this series of conversations...

- "The client said we need to make sure the site doesn't go down during deployments."

- "Can we deploy something that needs to be rolled out, restarted, upgraded, and use persistent disk" (like MySQL)

- "We need to monitor some metrics from the machines"

- "We need to scale the number of machines based on system utilization."

- "We need to hire an engineer to manage our infrastructure, so we need to bring them up to speed with our tooling"

- "We need to switch from cloud A to cloud B to save x/year"

- "We need to run on two clouds to fulfil some legal requirements"

There are all documented, standardized, and hireable (engineers already know it) tooling to do. Also it's all declarative so it's just YAML and no magic needed or manual management.

That's the magic of kube. That, the tooling, the shared vocabulary (no ramp up time for engineers), the platform Independence, the automatic scaling, the network security features, and the ability to define your own internal constructs (CRDs).

I set up auto scaling for a kube cluster and it didn’t feel like switching on a feature that was included, it felt more like building a semi-custom solution out of some publicly available parts.

Yes, it is not included. It is a publicly available part that you plugged in.

There are a limited number of people who actually have a use case where they want to manage their own kube cluster. Most people would be happy if they tried a managed kube cluster like GKE [0] and DO [1] for example.

If you are managing your own cluster from scratch you're likely:

- At a company with huge sets of bare metal machines

- A massive organization that can afford to hire infrastructure experts to optimize every penny out of their cluster ops by vertically integrating their cluster management (rather than outsourcing to something like DO).

- Hobbyist who wants to learn how kube fits together.

If you're not one of those three then all you need is to setup Rook, setup some autoscaling component, pick out a few DB operators, setup monitoring, and setup a logging infrastructure. Compared to older solutions for similar things the "kube way" is a pre-planned roadmaps with minor choices along the way that are mostly personal preferences that weigh: "how much to I care about security", "does this need to be more or less debuggable", and more.

If you need a cluster, want a "managed-like" experience, then just go with Kops. If you just need a cluster to run your applications on just go with GKE, AKS, DO, or another offering.

0 - https://cloud.google.com/kubernetes-engine/docs/concepts/clu...

1 - https://www.digitalocean.com/docs/kubernetes/how-to/autoscal...

Reply on news.ycombinator.com