Let's get into it…
During the early days of Kubernetes, supporting new storage solutions, or different container run times resulted in code changes directly in the kubernetes repository. The code changes being mentioned are called in-tree development.
While in-tree development has some advantages, such as easier coordination and versioning, it also has several big drawbacks, especially for fast-adopted projects like Kubernetes.
What will be covered?
The disadvantages of in-tree development
The advantages of out-tree development
Kubernetes Interfaces
The Disadvantages of in-tree Development
In-tree development means that the project’s code, including core components, extensions, and plugins, is maintained in a single code repository. In the Kubernetes context, which has big adoption, this means a lot of development time on plugins and extensions and a less optimal experience for the providers and for the community.
The disadvantages of in-tree development are as follows:
Bottleneck: It is challenging to add new plugins and support for new technologies, as each addition requires integration with the core code base and development time.
CodeBase Bloating: Over time, as more plugins and extensions are being supported, the codebase becomes larger and more complex to maintain and follow.
Slower updates: Third-party integrations will take part in the core product development cycle, which has its own testing and versioning that may not be optimal.
Kubernetes maintainers decided to move away from in-tree development and started implementing interfaces in 2016, just two years after the first release of Kubernetes.
The Advantages of out-tree Development
Kubernetes had implemented out-tree development by implementing interfaces (which will be listed shortly). Several factors, including wider adoption, bloated source code, the need for flexibility, and other factors, drove the transition.
Some of the significant benefits of moving to interfaces:
Simplicity: Decoupling plugins from the kubernetes codebase streamlined the development process and reduced the burden on its maintainers.
Flexibility: Third-party developers can create and maintain their plugins independently without the need to learn other source code and go through the Kubernetes development cycle, leading to a bigger ecosystem and offerings.
Maintainers: By delegating responsibility to third-party developers, Kubernetes maintainers can focus on the core product rather than plugins and extensions.
Kubernetes Interfaces
Kubernetes shares standards and requirements in the form of interfaces to modularize and extend its functionality. With interfaces, 3rd-party developers can focus on their plugins, and kubernetes maintainers can focus on their core product.
A brief overview of Kubernetes Interfaces
Container Runtime Interface (CRI): The container runtime interface was introduced as an Alpah feature in kubernetes version 1.5 and became stable in version 1.10. Its purpose is to decouple kubelet from specific container runtimes, allowing many more providers to integrate with Kubernetes without changing the source code.
Container Storage Interface (CSI): The container storage interface was introduced in version 1.10. CSI allows third-party storage providers to write and deploy their plugins and expose new storage systems without touching the core kubernetes code.
We haven't mentioned CNI because it’s an agnostic solution to kubernetes, and its development was the initiative of CNCF rather than the other two, which originated from Kubernetes maintainers.
To Conclude,
With the adoption of interfaces and moving away from in-tree development, Kubernetes becomes truly extensible. Third-party developers teams can now write and deploy their own plugins without touching, learning and complicating the Kubernetes source code. This results in more options and vibrant solutions that Kubernetes users can enjoy.
