Kubernetes Interfaces

 Kubernetes Interfaces

Kubernetes interfaces enable us to customize and build on the core functionality. Kubernetes interfaces are like definition or contract, on how something can be interacted with each other in Kubernetes Cluster. 

    In Kubernetes, we deploy plugins that satisfy these interfaces, providing functionality such as networking, storage, Runtime etc.

Types of Kubernetes Interfaces

    There are several interfaces that enable customization and additional functionality in Kubernetes. In short these are known as CNI, CSI, CRI, SMI, CPI and OCI, let's understand bit more about them.

CNI: Container Networking Interface

Enables networking providers to define how they do things from IPAM to actual packet routing.

CSI: Container Storage Interface

Enables storage providers to satisfy intra-cluster workload requests. Commonly implemented for technologies such as ceph, vSAN, and EBS.

CRI: Container Runtime Interface

Enables a variety of runtimes, common ones including docker, containerd, and cri-o. It also has enabled a proliferation of less traditional runtimes, such as firecracker which leverages KVM to provision a minimal VM.

SMI: Service Mesh Interface

One of the newer interfaces to hit the Kubernetes ecosystem. It hopes to drive consistency when defining things such as traffic policy, telemetry, and management.

CPI: Cloud Provider Interface.

Enables providers such as VMware, AWS, Azure, and more to write integration points for their cloud services with Kubernetes clusters.

OCI: Open Container Initiative Runtime Spec 

Standardizes image formats ensuring that a container image built from one tool, when compliant, can be run in any OCI-compliant container runtime. This is not directly tied to Kubernetes but has been an ancillary help in driving the desire to have pluggable container runtimes (CRI).