WEBVTT

00:01.190 --> 00:04.700
Let us now look at
container storage interface.

00:05.570 --> 00:08.710
In the past, Kubernetes used
Docker alone

00:08.880 --> 00:10.790
as the container runtime engine,

00:10.960 --> 00:13.740
and all the code to work with Docker

00:13.930 --> 00:16.820
was embedded within the Kubernetes
source code.

00:17.500 --> 00:19.640
With other container runtimes
coming in,

00:19.810 --> 00:21.860
such as rkt and CRI-O,

00:22.290 --> 00:25.620
it was important to open up
and extend support

00:25.790 --> 00:28.260
to work with different
container runtimes

00:28.430 --> 00:31.440
and not be dependent
on the Kubernetes source code.

00:32.190 --> 00:35.530
That's how container runtime
interface came to be.

00:36.340 --> 00:40.150
The container runtime interface
is a standard that defines

00:40.330 --> 00:43.070
how an orchestration solution
like Kubernetes

00:43.360 --> 00:46.640
would communicate
with container runtimes like Docker.

00:47.280 --> 00:48.140
In the future,

00:48.300 --> 00:51.570
if any new container runtime
interface is developed,

00:51.730 --> 00:54.370
they can simply follow
the CRI standards.

00:54.530 --> 00:57.940
That new container runtime
would work with Kubernetes

00:58.110 --> 00:59.570
without really having to work

00:59.730 --> 01:01.790
with the Kubernetes team
of developers,

01:01.960 --> 01:04.080
or touch the Kubernetes source code.

01:05.260 --> 01:08.180
Similarly,
as we saw in the networking lectures,

01:08.490 --> 01:11.970
to extend support
for different networking solutions,

01:12.270 --> 01:15.350
the container networking interface
was introduced.

01:16.080 --> 01:21.020
Now, any new networking vendors
could simply develop their plugin

01:21.280 --> 01:23.030
based on the CNI standards

01:23.190 --> 01:26.180
and make their solution
work with Kubernetes.

01:27.620 --> 01:28.850
As you can guess,

01:29.020 --> 01:31.770
the container storage interface
was developed

01:31.930 --> 01:34.350
to support multiple
storage solutions.

01:34.920 --> 01:38.070
With CSI, you can now write
your own drivers

01:38.230 --> 01:40.890
for your own storage
to work with Kubernetes.

01:41.690 --> 01:44.220
Portworx, Amazon EBS,

01:44.390 --> 01:45.490
Azure Disk,

01:45.660 --> 01:48.550
Dell EMC Isilon, PowerMax, Unity,

01:48.720 --> 01:52.970
XtremIO, NetApp, Nutanix, HPE,
Hitachi,

01:53.140 --> 01:57.000
Pure Storage, everyone's got
their own CSI drivers.

01:57.940 --> 02:01.940
Note that CSI is not a Kubernetes
specific standard.

02:02.540 --> 02:05.340
It is meant to be
a universal standard

02:05.580 --> 02:09.550
and if implemented, allows
any container orchestration tool

02:09.720 --> 02:13.520
to work with any storage vendor
with a supported plugin.

02:14.120 --> 02:19.570
Currently, Kubernetes, Cloud Foundry,
and Mesos are onboard with CSI.

02:20.710 --> 02:23.140
Here's what the CSI looks like.

02:23.740 --> 02:27.880
It defines a set of RPCs
or remote procedure calls

02:28.050 --> 02:30.640
that will be called
by the container orchestrator.

02:30.810 --> 02:33.930
These must be implemented
by the storage drivers.

02:34.330 --> 02:36.460
For example, CSI says

02:36.650 --> 02:40.720
that when a pod is created
and requires a volume,

02:41.010 --> 02:44.170
the container orchestrator,
in this case, Kubernetes,

02:44.390 --> 02:47.260
should call the create volume RPC

02:47.430 --> 02:50.960
and pass a set of details
such as the volume name.

02:51.770 --> 02:55.480
The storage driver
should implement this RPC

02:55.720 --> 03:00.150
and handle that request and provision
a new volume on the storage array,

03:00.330 --> 03:02.660
and return the results
of the operation.

03:03.420 --> 03:08.330
Similarly, container orchestrator
should call the delete volume RPC

03:08.500 --> 03:10.190
when a volume is to be deleted

03:10.350 --> 03:13.320
and the storage driver
should implement the code

03:13.490 --> 03:15.700
to decommission the volume
from the array

03:15.860 --> 03:17.110
when that call is made.

03:18.010 --> 03:20.430
The specification details exactly

03:20.600 --> 03:23.670
what parameters should be sent
by the color,

03:24.080 --> 03:26.140
what should be received
by the solution,

03:26.310 --> 03:28.690
and what error codes
should be exchanged.

03:29.390 --> 03:32.050
If you're interested,
you can view all these details

03:32.220 --> 03:36.190
in the CSI specification on GitHub
at this URL.

03:37.100 --> 03:41.110
That's about it for now,
about container storage interface.

03:41.550 --> 03:43.360
I'll see you in the next lecture.