Let us now look at container storage interface.
In the past, Kubernetes used Docker alone
as the container runtime engine,
and all the code to work with Docker
was embedded within the Kubernetes source code.
With other container runtimes coming in,
such as rkt and CRI-O,
it was important to open up and extend support
to work with different container runtimes
and not be dependent on the Kubernetes source code.
That's how container runtime interface came to be.
The container runtime interface is a standard that defines
how an orchestration solution like Kubernetes
would communicate with container runtimes like Docker.
In the future,
if any new container runtime interface is developed,
they can simply follow the CRI standards.
That new container runtime would work with Kubernetes
without really having to work
with the Kubernetes team of developers,
or touch the Kubernetes source code.
Similarly, as we saw in the networking lectures,
to extend support for different networking solutions,
the container networking interface was introduced.
Now, any new networking vendors could simply develop their plugin
based on the CNI standards
and make their solution work with Kubernetes.
As you can guess,
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,
Dell EMC Isilon, PowerMax, Unity,
XtremIO, NetApp, Nutanix, HPE, Hitachi,
Pure Storage, everyone's got their own CSI drivers.
Note that 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.
Currently, Kubernetes, Cloud Foundry, and Mesos are onboard with CSI.
Here's what the CSI looks like.
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.
For example, CSI says
that when a pod is created and requires a volume,
the container orchestrator, in this case, Kubernetes,
should call the create volume RPC
and pass a set of details such as the volume name.
The storage driver should implement this RPC
and handle that request and provision a new volume on the storage array,
and return the results of the operation.
Similarly, container orchestrator should call the delete volume RPC
when a volume is to be deleted
and the storage driver should implement the code
to decommission the volume from the array
when that call is made.
The specification details exactly
what parameters should be sent by the color,
what should be received by the solution,
and what error codes should be exchanged.
If you're interested, you can view all these details
in the CSI specification on GitHub at this URL.
That's about it for now, about container storage interface.
I'll see you in the next lecture.