Core Idea
The platform plugs into containers through three interfaces: CRI for runtimes, CNI for networking, and CSI for storage, each a contract that keeps the pieces interchangeable.
- Container Runtime Interface: how the orchestrator talks to a container runtime.
- Container Networking Interface: how pod networks get wired.
- Container Storage Interface: how storage gets attached.
Container Runtime Interface
Most Popular Container Runtimes
What are Container Runtimes
- Kubernetes used Docker alone as the container runtime engine, and all the code to work with Docker was embedded within the Kubernetes source code. Other container runtimes, such as rkt and CRI-O.
- The Container Runtime Interface is a standard that defines how an orchestration solution like Kubernetes would communicate with container runtimes like Docker. If any new container runtime interace is developed, they can simply follow the CRI standards.
Container Networking Interface
- To support different networking solutions, the container networking interface was introduced. Any new networking vendors could simply develop their plugin based on the CNI standards and make their solution work with Kubernetes.
Container Storage Interface
-
The container storage interface was developed to support multiple storage solutions. With CSI, you can now write your own drivers for your own storage to work with Kubernetes. Portworx, Amazon EBS, Azure Disk, GlusterFS etc.
-
CSI is not a Kubernetes specific standard. It is meant to be a universal standard and if implemented, allows any container orchestration tool to work with any storage vendor with a supported plugin. Kubernetes, Cloud Foundry and Mesos are onboard with CSI.
-
It defines a set of RPCs or remote procedure calls that will be called by the container orchestrator. These must be implemented by the storage drivers.
-
https://www.nomadproject.io/docs/internals/plugins/csi#volume-lifecycle