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?
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.
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.
Comments
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.
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.