Kubernetes Plugins — CRI CNI CSI
Kubernetes is the household name when it comes to Cloud Native World. It is known for its flexibility and modularity. It's quite interesting to explore the significant plugins available for Kubernetes, which are super helpful to enable seamless integration with the custom modules.
The handiest plugins that I came across in Kubernetes are CRI, CNI, and CSI.
CRI — Container Runtime Interface
CNI — Container Network Interface
CSI — Container Storage Interface
Yeah, You are right !! We talked a bit about Container Runtime Interface in the last article.
Container Runtime Interface (CRI) enables a flexible environment that supports different runtimes (contained, CRI-O, or any other runtimes) without the hassle of recompilation.
Container Network Interface (CNI) is quite helpful when you wanted to insert a network interface into a container network namespace.
And now let's see about Container Storage Interface (CSI), Which is going to be the prime focus of this article. Kubernetes CSI made persistent storage integration very easy. It was created via out-of-tree development, thus an external plugin rather than being an in-tree module.
The in-tree modules are developed and released inside the Kubernetes repository. With these in-tree modules, Kubernetes deployment is possible without the installation of any additional components.
Evolution from Kubernetes Volume Plugin to CSI
While sometime back, we were relying on Kubernetes Volume plugins. They are in-tree modules. Thus, If the user wants to add support for new storage, it's possible only by inserting it into the Kubernetes repository. But the developer finds it hard to push their code every time into the official repo because their development should always be aligned with Kubernetes releases.
The out-of-tree module encouraged the fact that drivers/plugins can be developed independently out of Kubernetes core.
Flex Volume Plugin came as the savior. This plugin has used exec based model to integrate external storage with Kubernetes. This gave an opportunity for developers to write out-of-tree drivers. But a trap here is, to deploy any third-party drivers, it becomes a necessity to have access to the root file system.
Again, a pain point has been spotted !!
Finally, Container Storage Interface has been introduced. This plugin let the storage suppliers expose their products to all the container orchestrators like Kubernetes. That is, Any vendor can expose their storage options to Kubernetes without having to touch Kubernetes code by any means.
Thus, In addition to being an out-of-tree driver, It also offers other sophistications like, it can be containerized, and deployed via standard Kubernetes primitives which eventually can be consumed via Storage classes (of course using Persistence volumes, Persistent Volume Claims).
And Life becomes simple. Happily ever after :)
