How the Container Storage Interface can aid Kubernetes use

Top uses for CSI and Kubernetes

The primary use for the Container Storage Interface is storage abstraction. It enables Kubernetes to work with any storage device for which an interface driver is available.

These drivers also make Kubernetes more stable and reliable, since they reside outside of the core Kubernetes code. CSI drivers replaced the old system of plugins.

CSI benefits compared to in-tree plugins

The main benefit of the Container Storage Interface is simplicity. Before Kubernetes made the interface generally available in version 1.13, storage was exposed through "in-tree" plugins, which were integrated directly into the Kubernetes binaries. Although these in-tree plugins worked, there were at least three major challenges with their use.

First, if a vendor wanted to make its storage product work with Kubernetes, it would have to collaborate with several levels of bureaucracy to integrate its plugin with Kubernetes software.

Second, vendors could not easily fix bugs in -- or add enhancements to -- their plugins, since they were a part of the core Kubernetes code.

Third, and most importantly, a poorly written plugin could potentially destabilize the Kubernetes platform.

Now, rather than these plug-ins, vendors can use an API to create a Container Storage Interface driver that enables their hardware to work with Kubernetes. Storage vendors no longer face the hassle of trying to get support for Kubernetes integration. Rather, they can create interface drivers at any time and offer new versions of those drivers.

Implementation best practices

Test CSI drivers thoroughly before using them in a production environment. Testing helps avoid buggy drivers but is also important because not all drivers are created equally.

Drivers include several subcomponents -- one of which is the Container Storage Interface Controller. The controller is the mechanism that tells Kubernetes how to perform various functions at a low level.

For example, the controller might include hardware-specific instructions to provision a volume, attach a volume to a Kuberentes node or create a volume snapshot. Kubernetes will only be able to perform hardware-level functions identified within the controller.

It's possible that an early release driver might only include basic functionality, with additional functions in subsequent versions. Testing will identify any missing functionality.

In addition, only use release versions of CSI drivers. Hardware vendors provide some drivers, but the community develops others. Websites that host community development projects often list the current stable version of the code but may also make one or more prerelease versions available. These prerelease builds may contain significant bugs. Never use them in production environments, even if they offer additional functionality.