The Importance of Pure Open-Source Kubernetes

In a short time, the open-source ecosystem has evolved from niche projects with limited corporate backing to the de facto way to build software. 
 

Today, organizations large and small are adopting open-source software to accelerate product development and innovation. In the government sector, the U.S. Department of Defense issued a memorandum on adopting open source software as its preference versus proprietary software, calling open-source “critical in delivering software faster.”
 

Why is a Kubernetes management platform’s openness important? Deviating from the Kubernetes standard can create problems. As The Journal of Cloud Computing notes, “without an appropriate standardized format, ensuring interoperability, portability, compliance, trust, and security is difficult.”
 

What Is Pure Upstream Open-Source Kubernetes?

Upstream Kubernetes is an open-source version of Kubernetes hosted and maintained by the Cloud Native Computing Foundation (CNCF) where code and documentation is developed, and where contributions are made. It consists of core Kubernetes components (often called “plain vanilla” Kubernetes) for orchestrating containers without add-on applications. All of these are publicly accessible for inspection, modification, and redistribution.
 

These free and open-source software projects start with good intentions – making available technology that benefits the whole community. Anyone can access the code, so community collaboration can fix bugs, add patches, and improve performance relatively fast. But as a project grows and matures, different goals, perspectives, and needs arise. This is where project contributors introduce forks in the code.
 

What Is a Fork of Kubernetes?

A fork of Kubernetes is a version of the open-source project developed along a separate workstream from the main trunk. Forking occurs when part of the development community or a third-party vendor makes a copy of the upstream project with modifications to start a completely independent line of development.

Why would you fork Kubernetes? There can be honorable and selfish reasons. There might be differences in opinion (technical or personal). Development of the upstream project might have stagnated. A developer might want to create different functionality or steer the project in a new direction. This can happen in open-source or proprietary environments.
 

In an open-source environment, when you create a fork of Kubernetes that improves the original source code, other forks can take advantage of it. And because the code is freely available to use, other forks can merge the code into their fork to better meet the needs of developers and end users.
 

But a fork of Kubernetes in a proprietary environment can have different consequences. Vendors or cloud companies can modify the source code to meet their specific needs, repackage the software, and offer it to customers as a proprietary distribution, or they might modify the add-ons needed to run Kubernetes in production. This can complicate the management of the solution and create vendor lock-in.
 

Challenges of a Fork of Kubernetes

Deploying and managing Kubernetes at scale in an enterprise is difficult! Many organizations turn to proprietary distributions to obtain enterprise support for their container platforms. But significantly forked versions of Kubernetes have emerged as proprietary Kubernetes deployments.
 

Customers deploying proprietary Kubernetes distributions face many challenges, including the following:
 

Complications with Patches, Bug Fixes, Upgrades, and New Features

Every time you introduce changes to a platform, it becomes more difficult to make the new code work with your custom distribution. This can make the maintenance process slow, error-prone, and costly. In fact, by the time a new feature comes out, a custom distribution typically is a few releases behind the latest release. Vendors who fork Kubernetes often have an older version of the cluster API because it takes them six months or more to get improvements and bug fixes from the upstream.
 

Vendor Lock-in

Forks in Kubernetes can create lock-in. Vendor lock-in, or proprietary lock-in, happens when a customer cannot easily replace or migrate the solution. A proprietary fork in Kubernetes doesn’t give you the flexibility to move your applications and data seamlessly between public, private, and on-premise services. It also doesn’t provide you with multiple options as your company grows.
 

Even if the source code is open-source, vendors can wrap Kubernetes in many features that make it difficult to migrate to other platforms without incurring cost and excess resource allocation. And because most custom distributions are not built with FluxCD, you can’t switch vendors without re-architecting your whole stack.
 

Lack of Functionality

A forked version of Kubernetes can break application functionality. Some custom distributions rely on proprietary APIs and command line interfaces (CLIs) to get full functionality, which creates lock-in. And if the custom distribution only runs on the vendor’s custom Linux kernel, it also creates lock-in. As time goes on, it will become harder to maintain this fork. Merging the latest upstream patches into the fork won’t be possible without major additional work for patch and feature compatibility. And if a vendor discontinues a product or application, you might be out of luck.
 

Less Secure

A fork in Kubernetes can potentially run less secure code. If a vulnerability is found in open-source code and fixed by the community in the upstream, a forked version of the code might not benefit from the fix because it is different from the upstream version.
 

Lack of Interoperability

Vendors might modify code for their custom distributions or the supporting applications you need to make Kubernetes run in production. While a modified version of Kubernetes will work with a particular vendor’s application stack and management tools, the proprietary modifications lock you into customized component builds, preventing you from integrating with other upstream open-source projects without lock-in. If their stack consists of multiple products, it can become extremely hard to achieve interoperability, which can cause a host of downstream issues as you scale.
 

Technical Debt
It’s incredibly difficult to merge back a fork that has diverged drastically over the years from the upstream. This is called “technical debt” – the cost of maintaining source code caused by deviation from the main branch in which joint development happens. The more changes to forked code, the more money and time it costs to rebase the fork to the upstream project.
 

Why Is Pure Upstream Kubernetes Important?

Pure upstream open-source Kubernetes is more than just the place where the project lives. It’s the focal point where decisions are made, where contributions happen, and where the project is maintained within a community that continuously improves the source code.
 

By doing work upstream first, you can share ideas with the larger community and get new features and releases accepted upstream. When features and patches are accepted upstream, every project and product based on the upstream can benefit from that work when they pick up the future release or merge recent (or all) upstream patches.
 

Conversely, it takes more time and effort to send patches or report bugs from the downstream project back upstream. Often the code has already changed by the time it has shipped downstream, making it harder to integrate changes developed against an older version of the project.
 

While anyone can copy, install, or distribute Kubernetes from the upstream repository, larger companies and organizations require certified products, tested and hardened for enterprise use. As such, organizations rely on vendors to turn upstream Kubernetes into downstream products that meet their business needs.
 

The D2iQ Difference: Pure Open-Source Kubernetes

Unlike other vendor distributions, the D2iQ Kubernetes Platform (DKP) is built on pure upstream open-source components, enabling you to migrate easily to any environment with immunity from lock-in to proprietary solutions. With DKP, you can leverage the best innovation the industry has to offer while ensuring the security, resilience, and lowest cost-of-ownership.
 

D2iQ was a founding member of the CNCF, and since our earliest days open-source software has been a critical part of the D2iQ mission. We build innovative open-source products based on upstream projects and we contribute to open-source projects that benefit the entire community. We position customers for open-source success by providing a completely open CNCF-conformant Kubernetes management platform, enabling them to achieve innovation faster and to easily accommodate new open-source technologies as they arise.
 

To learn how your organization can achieve agility through a pure open-source Kubernetes management platform, contact the experts at D2iQ.