Kubernetes Distribution or Vanilla Kubernetes?
Recently, I came across an article by a well-respected reporter who came to the conclusion that organizations are better off with vanilla Kubernetes than a Kubernetes distro. After reading the article, it was clear that even this author, who has covered the space for years, still struggles to understand what a production-grade Kubernetes deployment really takes. Here’s my attempt to bring some clarity.
In his article, the author states that Kubernetes only has a dozen of components, some of which are even optional. From this premise, the author states that it’s not that hard to master them. Yes, Kubernetes may only have a dozen components, but to implement Kubernetes in production you need a lot more than just Kubernetes. While the stated argument stands for development, it doesn’t translate into production — and that’s what really matters.
Kubernetes, Only One Technology in the Stack
For production-grade deployments, you’ll need an entire stack: orchestration (aka Kubernetes), container runtime and OS, add-ons and extensions (like overlay network, DNS, etc). monitoring, logging, infrastructure automation, policy management, security hardening, etc. You also need to integrate with existing systems such as RBAC, PKI, and identity management (for more details on what an enterprise-grade Kubernetes platform should tackle, check out this No-BS Kubernetes Checklist). Once you get serious, things start adding up.
So, can you do it in-house? Yes. But there are a lot of moving pieces that have to be properly configured and fine-tuned to provide the level of reliability and security an enterprise needs. And that does require serious expertise. You can’t just build that quickly.
But let’s say you do manage to build an in-house platform, you still have to maintain it. That means, updating Kubernetes on a quarterly basis and doing the same for all other components. While some enterprises may want to go that route, it will certainly exceed the capacities of others.
An alternative is leveraging a Kubernetes distribution. That’s when a vendor takes vanilla Kubernetes — the unmodified, upstream open source components (although some do fork it) — and adds some or all of the above-mentioned features. Distributions exist because they cost less than the team of experts needed to maintain a homegrown platform and keep it up to date with the technology and the ecosystem.
Kubernetes distributions play an important role within the ecosystem. For some companies, they are the only way to adopt the cloud native stack quickly. Others can and will opt for a home-grown platform — it just depends on their human and financial resources.
Does Kubernetes Distribution Mean Lock-in?
The author does make a great point. When selecting a distribution that locks you in, you’re giving away the much-needed flexibility to pivot with market demands. That’s why we, at Kublr, built a platform that is fully customizable, uses plain upstream vanilla Kubernetes components, and works with any Kubernetes-compatible toolkit. It is possible to create a distribution in the spirit of open source, it just depends on the vision of the team building it.
Here are two key distro lock-in warning signs:
- Forked Kubernetes: in this case, the platform includes proprietary features that aren’t compatible with upstream Kubernetes or other vendors. If used, the apps are locked-in.
- Vendor provisioned Kubernetes cluster reliant on vendor platform: that’s when the Kubernetes clusters cannot “survive” and/or be used without vendor-specific additional components or active licenses.
The author also rightly points out that a Kubernetes distribution may die, and that’s exactly why you need to select one that doesn’t lock you in.
In summary, you can’t compare a Kubernetes distribution to vanilla Kubernetes — that’s an apples to oranges comparison. One is the entire stack while the other one is only one technology needed to run in production. That being said, it is important to educate readers on the implications different vendor design decisions have.
The cloud native stack offers enterprises the opportunity to adopt or build flexible, modular systems that allow them to pivot with market demands — probably the most critical ability in today’s rapidly evolving technology landscape. Locking yourself into yet another stack is negating the very benefit of Kubernetes and the cloud native stack at large.
