What is Kubernetes Container Storage Interface
The Container Storage Interface (CSI) is a joint effort to create a cross platform interface for persistent storage to be used with container systems. Kuberntes is among the major players contributing to CSI and the CSI has just reached beta in Kubernetes 1.10 .
The need for persistent storage in an ephemeral world
Everyone who has container basics in mind knows that containers are ephemeral. All the data sitting in a container are lost as soon as the container is shut down. But most traditional workloads such as databases require persistent storage by nature. Each container platform has its own solution to this problem, such as Docker Volumes, but what happens when we add container orchestration to the equation? Things start to get complex. You may use existing hardware SAN in conjunction with volumes and all sort of tricks, but solutions engineered for the pre-container era hardly work well with containers.
The need for new storage solutions that would work well with containers and orchestrators culminated with fragmentation. Each storage provider, be it hardware or software came up with its own set of interfaces and protocols in order to work with containers and orchestrators. And that of course is not easily maintainable.
Kubernetes and Flex Volumes
The Kubernetes architecture makes it hard to develop storage solutions “out-of-tree”. A developer that needs to integrate its own storage solution with Kubernetes would have to make heavy changes to the Kubernetes code base. That was the situation before the Flex Volume plugin: a set of API to simplify the development of volume drivers “out-of-tree” to integrate storage solutions with Kubernetes.
In addition to being difficult to deploy, Flex did not address the pain of plugin dependencies: Volume plugins tend to have many external requirements (on mount and filesystem tools, for example). These dependencies are assumed to be available on the underlying host OS which is often not the case (and installing them requires access to the root filesystem of node machine).
Container Storage Interface: the game changer
The goal of CSI is to establish a standardized mechanism for Container Orchestration Systems (COs) to expose arbitrary storage systems to their containerized workloads. The CSI specification emerged from cooperation between community members from various Container Orchestration Systems (COs)–including Kubernetes, Mesos, Docker, and Cloud Foundry. The specification is developed, independent of Kubernetes, and maintained at https://github.com/container-storage-interface/spec/blob/master/spec.md.
The CSI is essentially an effort to further modularize Kubernetes and other orchestrators. Leveraging a common interface driver developers won’t have to support multiple drivers for each orchestrator, saving time and enabling faster development.
For administrators storage solutions will be easier to set up, configure and integrate. Installing and configuring storage solutions against Kubernetes will become less painful and CSI will be to storage what CNI has been for networking.
What changes will Kubernetes users?
CSI addresses all of these issues by enabling storage plugins to be developed out-of-tree, containerized, deployed via standard Kubernetes primitives, and consumed through the Kubernetes storage primitives users know and love (PersistentVolumeClaims, PersistentVolumes, StorageClasses).
Essentially none! Developers using Kubernetes will continue to consume storage using PersistentVolumeClaims, the mechanism behind will be different. Of course the administrator will have to configure CSI plugins accordingly before they can be consumed through Kubernetes primitives.
Lastly, most of the “in-tree” volume plugins and Flex Volumes will be slowly migrated to Container Storage Interface although the Kubernetes developers will still support Flex Volumes APIs for the time being.
- 2020 A year in review for Marksei.com - 30 December 2020
- Red Hat pulls the kill switch on CentOS - 16 December 2020
- OpenZFS 2.0 released: unified ZFS for Linux and BSD - 9 December 2020
Recent Comments