1
00:00:01,330 --> 00:00:04,060
Let us now look at container storage.

2
00:00:04,060 --> 00:00:12,100
Interface in the past carbonate is used Docker alone as the container runtime engine and all the code

3
00:00:12,280 --> 00:00:19,450
to work with Docker was embedded within the net a source code with other container run times coming

4
00:00:19,450 --> 00:00:22,400
in such as rocket and cryo.

5
00:00:22,450 --> 00:00:29,200
It was important to open up and extend support to work with different container run times and not be

6
00:00:29,200 --> 00:00:37,070
dependent on the carbonated source code and that's how container runtime interface came to be the container

7
00:00:37,070 --> 00:00:44,450
runtime interface is a standard that defines how an orchestration solution like carbonates would communicate

8
00:00:44,510 --> 00:00:47,390
with container run times like Docker.

9
00:00:47,420 --> 00:00:53,690
So in the future if any new container runtime interface is developed they can simply follow the CRC

10
00:00:53,690 --> 00:01:00,000
standards and that new container runtime would work with carbonates without really having to work with

11
00:01:00,000 --> 00:01:07,050
the Coburn and his team of developers or touch the Coburn at its source code similarly as we saw in

12
00:01:07,050 --> 00:01:12,260
the networking lectures to extend support for different networking solutions.

13
00:01:12,390 --> 00:01:16,620
The container networking interface was introduced now.

14
00:01:17,010 --> 00:01:23,940
Any new networking renders could simply develop their plug in based on the CNI standards and make their

15
00:01:23,940 --> 00:01:32,160
solution work with coordinates and as you can guess the container storage interface was developed to

16
00:01:32,160 --> 00:01:36,000
support multiple storage solutions with CSI.

17
00:01:36,090 --> 00:01:40,360
You can now write your own drivers for your own storage to work with.

18
00:01:40,360 --> 00:01:42,820
Notice how it works.

19
00:01:42,960 --> 00:01:45,780
Amazon UBS as your desk.

20
00:01:45,780 --> 00:01:54,400
Dell EMC isolation power Max unity extreme IO NetApp Newton x hp Hitachi Pure Storage.

21
00:01:54,420 --> 00:02:02,450
Everyone's got their own CSI drivers note that CSI is not a a specific standard.

22
00:02:02,670 --> 00:02:09,960
It is meant to be a universal standard and if implemented allows any container orchestration tool to

23
00:02:09,960 --> 00:02:13,980
work with any storage vendor with a supported plug in.

24
00:02:14,290 --> 00:02:20,700
Currently coordinators Cloud Foundry and measles are onboard with CSI.

25
00:02:20,840 --> 00:02:23,800
So here's what the CSI kind of looks like.

26
00:02:23,900 --> 00:02:30,740
It defines a set of our pieces or remote procedure calls that will be called by the container orchestrator

27
00:02:30,920 --> 00:02:34,380
and these must be implemented by the storage drivers.

28
00:02:34,430 --> 00:02:42,980
For example CSI says that when a pod is created and requires a volume the container orchestrator in

29
00:02:42,980 --> 00:02:50,600
this case coordinates should call the create volume RBC and pass a set of details such as the volume

30
00:02:50,600 --> 00:02:54,430
name the storage driver should implement.

31
00:02:54,440 --> 00:03:01,670
This RBC and handle that request and provision and new volume on the storage array and return the results

32
00:03:01,790 --> 00:03:03,330
of the operation.

33
00:03:03,530 --> 00:03:10,130
Similarly container orchestrator should call the delete volume RBC whenever volume is to be deleted

34
00:03:10,520 --> 00:03:15,930
and the storage driver should implement the code to decommission the volume from the array.

35
00:03:15,950 --> 00:03:23,750
When that call is made and the specification details exactly what parameters should be sent by the caller

36
00:03:24,200 --> 00:03:29,540
what should be received by the solution and what error codes should be exchanged.

37
00:03:29,540 --> 00:03:35,300
If you're interested you can view all these details in the CSI specification on github.

38
00:03:35,330 --> 00:03:41,700
At this you URL so that's about it for now about container storage interface.

39
00:03:41,730 --> 00:03:43,380
I'll see you in the next lecture.
