The Kubernetes interfaces

Kubernetes aims to be flexible and modular, so cluster administrators can modify the networking, storage, and container runtime capabilities to suit the organization’s requirements. Currently, Kubernetes provides three different interfaces that can be used by cluster administrators to use different capabilities within the cluster. These are discussed in the following subsections.

The container networking interface

To provide you with a better understanding of the Container Network Interface (CNI) and its role within the Kubernetes architecture, it’s important to first clarify that when a cluster is initially installed, containers or Pods do not have network interfaces, and therefore, they cannot communicate with each other. CNI helps implement K8s’ network model (we will deep dive into more details in the next chapter, Chapter 2, Kubernetes Networking). The CNI integrates with the kubelet, enabling the use of either virtual interfaces or physical networks on the host, to automatically configure the networking required for pod-to-pod communication.

To achieve this, a CNI plugin must be installed within the system. This plugin is utilized by container runtimes such as Kubernetes’ CRI-O, Docker, and others. The CNI plugin is implemented as an executable, and the container runtime interacts with it using JSON payloads.

The CNI is responsible for attaching a network interface to the pod’s network namespace and making any necessary modifications to the host to ensure that all network connections are working as expected. It takes care of tasks such as IP address assignment and routing, facilitating communication between pods on the nodes.

The container storage interface

Kubernetes introduced the container storage interface (CSI) in v1.13. Before 1.13, new volume plugins were part of the core Kubernetes code. The container storage interface provides an interface for exposing arbitrary blocks and file storage to Kubernetes. Cloud providers can expose advanced filesystems to Kubernetes by using CSI plugins.

By enforcing fine-grained access controls, the CSI driver significantly strengthens data security in Kubernetes. It not only facilitates isolated, secure storage access but also integrates seamlessly with encryption and key management, enhancing data confidentiality and compliance in containerized environments. The CSI driver allows for fine-grained access control to storage volumes, making it possible to enforce access permissions at the Pod level.

A list of drivers available can be found in the Further reading section of this chapter.

The container runtime interface

At the lowest level of Kubernetes, container runtimes ensure containers start, work, and stop. You need to install a container runtime into each node in the cluster so that Pods can run there. The most popular container runtime is Docker. The container runtime interface gives cluster administrators the ability to use other container runtimes, such as CRI and CRI-O.

Note

Kubernetes 1.30 requires that you use a runtime that conforms with CRI.

Kubernetes releases before v1.24 included a direct integration with Docker Engine, using a component named Dockershim. That special direct integration is no longer part of Kubernetes.

Having discussed how Kubernetes interfaces are used to configure networking, storage, and container runtime capabilities, you will now gain a better understanding of their usage by exploring one of the most important topics, Kubernetes objects, in the upcoming section.