4 Ways Kubernetes Could Be Improved

Source:-containerjournal.com

Kubernetes is good, but it could be improved. Here are some things that could be better.

Like almost everyone else these days, I think Kubernetes is the best container orchestration solution. But that doesn’t mean Kubernetes isn’t without its flaws. For my money, there are a number of things that Kubernetes could do better—and needs to if it is going to remain the de facto open source container orchestrator.

Indeed, some days I think the best thing I can say about Kubernetes is that it has fewer shortcomings than its competitors (I’m looking at you, Docker Swarm) rather than that it truly stands apart for its strengths.

Here’s a list of areas where Kubernetes can be improved.

The Kubernetes Installation Process
No matter how much you love command lines and configuration files, installing Kubernetes is a pain.

It’s annoying partly because Kubernetes consists of so many different components (the Kubelet, API server, Dashboard and on and on), and you have to set up each one separately. I suppose there is no total solution to this conundrum; Kubernetes is a complex platform and it’s never going to have a one-click installer.

But there is a second reason why Kubernetes installation is a pain: The fact that there is no universal Kubernetes installer. Some Kubernetes distributions offer installation tools, but Kubernetes itself does not. And even if you do use an installation tool, the process is usually not exactly smooth.

I’d love to see a standard Kubernetes installer that everyone could use. If the various distributions pooled their efforts on building a universal installer instead of developing their own, the community might gain a more feature-rich and user-friendly installation process for Kubernetes.

YAML
I’m not one of those people who hates YAML. I actually like it.

But what I don’t like is that Kubernetes basically requires you to use YAML. I wish that it was more flexible.

I suspect that as long as Kubernetes keeps jamming YAML down admins’ throats, there will always be folks who strongly dislike Kubernetes.

Multi-Cluster Support
Technically, you can have multiple clusters in one Kubernetes installation using federation. But I’ve always sensed that this use case was an afterthought for Kubernetes developers. Cluster federation has never achieved general-availability status, and it hardly seems like a priority for developers.

I know that generally speaking, it’s better to use one cluster and divvy it up using namespaces (and, yes, implementing federation is more difficult than it might seem). But sometimes you just want multiple clusters. That approach gives you more isolation from a security and performance perspective. It also allows you to use Kubernetes as a central control plane for disparate sets of servers, which is a powerful selling point.

Here’s hoping multi-cluster Kubernetes gets the love it deserves. It would certainly please the 68% of Kubernetes users who are running more than one cluster.

Smaller-Scale Kubernetes Deployments
Kubernetes is a great tool if you’re deploying multiple applications that are distributed across dozens of servers and have to handle thousands of requests per hour. In that scenario, the complexity of setting up and managing Kubernetes is worth the value you get from its automation features.

But for smaller deployments, it’s difficult to justify all of the work that goes into Kubernetes. At the end of the day, Kubernetes is a tool designed only for hyperscale environments.

Maybe you consider that a feature. But I’d argue there would be a lot to be gained by making Kubernetes more friendly toward smaller-scale environments, too. Not everyone is deploying apps on the scale of Google or Netflix. But even smaller environments benefit from the type of orchestration and automation that Kubernetes can provide.

Maybe a smaller-scale Kubernetes solution would involve simplifying the K8s architecture so that only a handful of components are needed. Maybe it would also entail configurations that are easier and interchangeable across small-scale environments so you wouldn’t have to configure so much from scratch if you’re only deploying a few apps.

For now, if you want to use Kubernetes, you’re stuck either dealing with a level of complexity that is excessive for smaller environments or you run a “lightweight” variant such as K3s, which may not provide the level of functionality you need.

Conclusion
Lest I be accused of being a Kubernetes hater, let me state, once again, that Kubernetes is an excellent tool. But it’s more excellent for some people (those who like YAML, have massive deployments and only have one cluster to manage) than others. An improved Kubernetes would be much more useful for everyone.