Hacker News new | ask | show | jobs
by ocd 13 days ago
I still don't know really what Kubernetes is for or why so many people outside specific environments are using it, but it's cool that you're using Ruby.
3 comments

Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible irrespective of the underlying cloud/hardware with a good and standardized API.

It's absolutely overkill for small teams and homelabs (I run a cluster myself) but an absolute godsend if you do need the advanced functionality.

Somehow we were doing that with deployment scripts and VM management tooling before Kubernetes became a thing, and without having to deal with YAML spaghetti.
Yes, and Kubernetes came around as another player in that ecosystem and became popular for a reason, largely so we didn't have to manage clusters with imperative non-idempotent scripts with no runtime introspection or self-healing. I've done light devops (lab scale, not enterprise) off and on since cfengine was a thing, and while I'm no fan of the explosion of YAML (there's a special place in hell for helm in particular for using text/template to generate yaml), I'll take the controller loop design any day over most of the alternatives. Just having a sane API alone is a godsend: you ever try scripting vSphere?
What sane API, for what Kubernetes runtime, in what version?

Because that is the thing, not only it is a YAML spaghetti, everything changes depending on the puzzle pieces.

I had to follow CNCF related podcasts only to be aware of what cool projects were changing Kubernetes all the time.

Thankfully nowadays I only care about managed containers, regardless how the hyperscalers do it, it is no longer my headache.

Never needed to deal with vSphere directly.

Kubernetes is built around a JSON API: those yaml files are just an encoding of the objects that it manipulates with fairly vanilla REST commands. You could actually use JSON in your manifests instead, it's a proper subset and all, though it's not going to help the verbosity. For that you need a better abstraction like Pulumi, cdk8s, Yoke, or even just good old Terraform/OpenTofu. Or just write your own, there's an openapi spec and clients in every language out there.

I'm hardly trying to pretend like I'm a hyperscaler: I usually run k3s on a single node, and most of the time I admin it "clickops" style with k9s, something I find much easier than most other management tools.

> there's a special place in hell for helm in particular for using text/template to generate yaml

Indeed. Using text templating for structured documents is already quite bad, doing it with a significant whitespace language it's absolute hell.

Yes but Kubernetes takes these battle-tested scripts, and allow everyone to use them with a few lines of YAML ;)

I understand the dislike of YAML but a Kubernetes deployment is ~50 lines, if I had to build my own scripts with a similar feature set I don't think I would be able to get it down much more than that.

Also your script often might not be that battle tested, more likely it will have bugs and miss a few important edge cases.
>Kubernetes makes complex things (e.g blue/green deployment, auto-scaling, failover) possible

How?

Kubernetes is good for two things. Zero downtime deployments and self-healing (where the looping state mechanism comes in). There are people who want k8s to handle every single operation that can run on a server, do not listen to those kinds of people they will lead you astray.
It's the industry standard for running and shipping containerized applications, at least for the ones which are more complex and/or dynamic than an application container and maybe 1-2 databases. It provides a well defined and stable orchestration API which is also quite capable. It's even sometimes worthwhile to spin up a single node cluster for that reason. Does not mean it is perfect, is it sometimes a bit complex? yes, is it verbose? yes, could the established ecosystem be better (thinking about e.g. helm)? yes. But at some point it's still easier with k8s than without it.

It is of course not the best choice for everything, there are enough things where you better just spin up a VM and deploy directly or with only a simple container runtime if you use containers.

Kubernetes is an attempt to solve the problems that come from deploying, Microservices™ across a gigantic enterprise with hundreds (or thousands) of contributors.

If you are one person and just need to expose a handful of macro-services, Kubernetes is almost entirely made of waste in terms of complexity, abstraction, indirection and resource consumption.