The yaml for my home test cluster takes up more lines than the full orchestrator and config I wrote at one of my past jobs to manage a 1000 VM cluster. Kubernetes might well make sense "at scale" but for anything of moderate size I can't help but feel it's massive overkill.
Literally every single one of those are well supported by Kubernetes and YAML.
1 and 3 are actually foundational to how k8s works.
Forgive me for saying this, but I’m getting a “i don’t want to invest any effort understanding anything and so Kubernetes is bad” vibes from these comments.
Hey, so I thought I remembered your username. This isn’t the first interaction we’ve had, or I’ve seen you have, that follows this similar pattern. In fact it’s the third example from you under this post!
It’s not a particularly pleasant experience to discuss anything with you, as after you make a particularly vapid comment that is naturally rebuffed you seem to just try to make snarky replies rather than engage.
Please understand that if you post your hot takes here they may be discussed and challenged, and if you don’t want this then I would refrain from initially commenting.
In response to your comment: They do. All Kubernetes resources are typed with JSON-schema definitions. Because of course they are, how else would kubernetes validate anything. https://kubernetesjsonschema.dev/
Anyone who’s used k8s at all knows this, if only from the error messages. From this you get autocompletion and a wide ecosystem of gui configuration tools that work with everything, including custom resource definitions, which is really cool.
Yes, your lack of knowledge was never in question.
> The Dunning–Kruger effect is a cognitive bias whereby people with low ability, expertise, or experience regarding a certain type of task or area of knowledge tend to overestimate their ability or knowledge
I'm perfectly capable of writing correct code by hand (be it XML or YAML), my problem is with the contents of the configuration files. Especially for the legacy Java EE servers there's loads of boilerplate stuff that has to be there for some reason but you don't have any idea why. Until something breaks and somewhere a magic setting has to be 'fixed'...
“Bad” is a value judgement. I’d go more with “taking on problems we don’t have” - J2EE made more sense if you were in a business like Atlassian’s where you sell an app to customers who wants to be able to run in it a bunch of different ways and configure many things without access to the source code. That especially made sense in the older era where apps were managed by sysadmins who didn’t have compilers and wouldn’t have gotten the source code from a vendor or wanted to pull it out of CVS.
That’s legitimate but, especially for open source developers, overkill and it pulls in a ton of maintenance work (e.g. I have several apps with a ton of CVEs in components which were never used but can’t be removed without breaking things, and thousands of lines of XML configuration which has to be analyzed to look for intentional customization to upgrade to the release version which has been patched. Now, maybe that’s doing it wrong but that’s multiple separate Java specialist development shops so it’s not just me being dense.).
Part of that is scope (Kubernetes does so much more) but most of it is the benefits of decades of experience and having a clean design. Java application servers were designed by and for Java applications so they blur a lot of lines whereas a Java (or Python or Node, etc.) developer can use Kubernetes without learning any Go tools.
You should really try the k8s plugin in intellij. It does all of the things OP asked for without adding a single extra line of complexity to the yaml file.
