Understanding Kubernetes Interfaces: CRI, CNI, and CSI
Understanding Kubernetes Interfaces: CRI, CNI, and CSI
In this article, take a look at more information on Kubernetes interfaces, including CRI, CNI, and CSI.
Join the DZone community and get the full member experience.Join For Free
Kubernetes is designed to support modular cloud-native applications from the ground up, so it is not surprising to find the platform to be equally modular and flexible. Kubernetes incorporates plugins, add-ons, services, and interfaces to extend the core functionalities of the platform. Kube’s integral configuration is how you can make changes and customize your environment, but customization goes beyond changing flags and local configuration files.
Extensions are defined as components that integrate seamlessly with the rest of the environment, offering native-like features and extending the commands available to cluster administrators. Extensions can also be used to add support for custom (and new) hardware.
In this article, however, we are going to focus more on interface plugins that serve three specific functions: device plugins, storage plugins, and network plugins. More specifically, we are going to cover how Container Network Interface (CNI), Container Runtime Interface (CRI), and Container Storage Interface (CSI) works in extending the functionality of Kubernetes as well as its support for new and custom hardware. Let’s get started, shall we?
Network Plugins for Kubernetes
There are some interesting CNI plugins to add to your Kubernetes clusters too. Calico, a popular plugin used by many cluster administrators, offers scalable networking functions using the standard L3 approach. It automatically enables compartmentalized networking in environments like AWS. It also enables seamless networking in on-premise deployments.
Flannel is another CNI plugin that utilizes the L3 network fabric approach. It doesn’t depend on a database to perform network functions. Instead, it taps directly into the Kubernetes API and sets default VXLAN architecture out of the box. When used with other tools, Flannel offers support for a large number of users.
Canal, on the other hand, offers a nice balance between ease of use and robustness. It is basically a ready-to-use VXLAN networking solution that takes advantage of existing CNI plugins like Calico, including for defining network policies and policy isolation. Canal simply makes the process of constructing network architecture easier.
We really cannot talk about CNI plugins without mentioning Weave Net, or Weave. Weave Net utilizes a different approach, incorporating an overlay network across different cloud networking configurations and making networking more universal. For instance, support for encryption and Kubernetes network policy is made universal across the network mesh.
CNI plugins are not the only network plugins available for Kubernetes. While CNI plugins are designed to work seamlessly with Kubernetes as a platform and offer functionalities in a more open way, you still have the option to use Kubernetes plugin working with CNI plugins through the implementation of basic cbr0.
Enhanced Container Runtimes
Container Runtime sits at the core of every Kubernetes environment. It is basically the component of the architecture that organizes hardware resources, runs, and stops containers, and makes sure that containers receive the resources they need to operate optimally. Container Runtime, however, is no longer a limited function.
Container Runtime Interface or CRI plugins are here to allow for new CR API to be fully utilized. Runtimes like Docker can be made more flexible with the right plugin. Naturally, CRI plugins offer one major benefit: they allow you to run different container runtimes without having to recompile.
Upon closer inspection, CRI plugins offer three main functionalities, the first one being the aforementioned support for interchangeable container runtimes. This means you can alter the runtime used by your Kubernetes environment at any stage and for any reason. If you find one runtime to be more efficient than another, making the switch is now easy.
CRI also bundles protocol buffers and gRPC API, so you can utilize languages like Dart and Go in one part of your environment, and Python or Java in another. gRPC API, in particular, simplifies service definition and makes scaling to millions of RPCs per second easy. The RPC framework is designed to run on top of any environment or network architecture.
gRPC is actually very interesting as a component. It integrates additional features like load balancing and health checking into the API, turning them into functions that operate at a lower level. The result is easier management of services through protocol buffers as well as the easy scaling mentioned earlier.
The most popular CNI plugin is CRI-O, a container runtime known for being incredibly light and nimble. It works with Kubic (which is configured to run CRI-O out of the box) as well as Minikube and Kubeadm. It fully integrates the Open Container Initiative (OCI) and eliminates dependency on Docker; you can run Kata Containers or fire up containers using any OCI container image.
Volume Plugins With CSI
The last component is storage, but it is certainly not the least important. Kubernetes has always relied on a volume plugin system for managing storage blocks, but the approach wasn’t open enough to allow for third-party management tools to run without issues. CSI is considered to be the answer, offering CSI volumes and dynamic provisioning of storage blocks as functions.
CSI allows third-party storage providers to offer persistent and dynamic storage blocks without forcing cluster administrators to jump through hoops to implement them. The main difference between CSI plugins and the core Kubernetes volume plugins is the fact that CSI plugins don’t need to be compiled and shipped with the core Kubernetes binaries.
Other CSI plugin features are just as interesting. Raw block volume lets you create CSI drivers for block volumes and enable allocation of those blocks to Kubernetes runtimes. Snapshot, on the other hand, supports the creation and restoration of storage block snapshots at any point. Plugins like MapR Data Fabric even support commands like livenessprobe, which allows containers to probe storage drivers.
There are several certified CSI drivers and plugins that can be integrated into your Kubernetes environment right away. Plugins from Blockbridge, VMware, and Portworx automatically enables dynamic provisioning and presents a GUI for managing CSI deployment.
Combined with CNI and CRI plugins discussed earlier, there is no application — no matter how complex it is — that you cannot fully support using Kubernetes. The Kubernetes cloud environment becomes incredibly robust and substantially more capable of answering modern cloud computing challenges.
Published at DZone with permission of Mauricio Ashimine . See the original article here.
Opinions expressed by DZone contributors are their own.