Let us now look at container storage.
Interface in the past carbonate is used Docker alone as the container runtime engine and all the code
to work with Docker was embedded within the net a source code with other container run times coming
in such as rocket and cryo.
It was important to open up and extend support to work with different container run times and not be
dependent on the carbonated source code and that's how container runtime interface came to be the container
runtime interface is a standard that defines how an orchestration solution like carbonates would communicate
with container run times like Docker.
So in the future if any new container runtime interface is developed they can simply follow the CRC
standards and that new container runtime would work with carbonates without really having to work with
the Coburn and his team of developers or touch the Coburn at its 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 renders could simply develop their plug in based on the CNI standards and make their
solution work with coordinates and 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.
Notice how it works.
Amazon UBS as your desk.
Dell EMC isolation power Max unity extreme IO NetApp Newton x hp Hitachi Pure Storage.
Everyone's got their own CSI drivers note that CSI is not a a 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 plug in.
Currently coordinators Cloud Foundry and measles are onboard with CSI.
So here's what the CSI kind of looks like.
It defines a set of our pieces or remote procedure calls that will be called by the container orchestrator
and 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 coordinates should call the create volume RBC and pass a set of details such as the volume
name the storage driver should implement.
This RBC and handle that request and provision and new volume on the storage array and return the results
of the operation.
Similarly container orchestrator should call the delete volume RBC whenever 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 and the specification details exactly what parameters should be sent by the caller
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 you URL so that's about it for now about container storage interface.
I'll see you in the next lecture.