'Boringly reliable': Red Hat architect thinks Kubernetes is 'mostly done' – but there are still plenty of bugs Red Hat architect and Kubernetes contributor Clayton Coleman, who leads development of OpenShift, reckons Kubernetes is "mostly done" – it needs tidying up and bugs fixed but not major new features. Coleman has worked on Kubernetes since it first went open source in mid-2014. OpenShift is older than Kubernetes and originally …
Imagine if we did the same with bridges. Yeah the skeleton is done but while you are using it we're going to be removing bits of the road from under you. Oh and some things that you relied on, well when we don't like them, or its a bit hard to maintain them, we'll get rid of them, and claim that we helped you by improving the security.
I'm trying to understand what "mostly done" actually means in Googlespeak.
Kubernetes is typical of computer software that is driven by the technical requirements not the user problem or "human" usable interfaces. that's fair enough - but to concentrate on the bugs is to miss the point for me. Concentrate on making it consumable to the simpletons *and* fix the bugs* please. Then you won't get usurped by the next big container thing. Sigh - it won't happen.
"computer software that is driven by the technical requirements not the user problem or "human" usable interfaces"
Think you've just described Blockchain there too. Every supplier and presentation that I had seen from various account managers were trying to convince me I need Blockchain in my estate. It just felt like a solution looking for a non-finance problem (as Bitcoin etc all seem to work).
Kubernetes is designed to be declarative and extensible, a core design principle is "meet the user where they are" as opposed to being overly opinionated. Cloud Foundry had a lot of opinionated design choices to improve the UX and it look where it is now. Part of the reason of K8s success is the ability to extend with CRDs for a more opinionated experience
A lot of these technologies (including Docker) are supposedly to simplify managing infrastructure.
In my experience all they do is take a lot of previous manual work and create a huge burden elsewhere.
I'm not convinced the learning curve and management of a K8s cluster really has as many advantages as people who use it like to think. I mean it involves a metric fuckton of work, months of learning how to use it, and nowhere to hide when it all goes wrong.
At least some of the manual management methods used previously were more tried and tested. They need to focus on usability, rather than telling the 1% who think it's amazing about how great it is - they are already the converted.
So k8s is hideous, it's sprawling, complex burdened with stupid names and written in yaml.
But it's about self service, when I have a templating problem, I reach for sed.
K8s gives them an override file to change a line, and a special command 'kustomize' which exists exclusively to change a line in this sort of yaml file. I didn't know this existed but it's really a thing, and now it's adopted into the main kubectl command with the -k flag.
So a way to look at it is an output target for various tooling, the result of which are some yaml.
So your scripts queries a db, runs perl over the results and spits out some yaml which k8s interprets.
The commands are verbose but sensible once you grok the concepts. You can run shell scripts with environment variables being injects from various useful sources, which something genuinely useful when combined with replication.
So I can tell a user, here is the platform contract, use the following env-vars in your service/script and the configuration management will do the right thing in development and production.
It is far, *far* from done. There are major issues with stability and the tools present in the ecosystem have catastrophic failings (e.g. ".local" causing Rancher to segfault).
Containers etc are super-useful but they still require highly skilled operators and a lot of attention.
I think that was his whole point, he himself clearly it ugly and difficult. He's saying that the new feature list should be done, and work on squishing bugs. That the features that have been lingering in the "we'll get to that" pile need to either be pushed forward to get them complete or kill them off to focus on bug hunting
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
