1
00:00:00,000 --> 00:00:10,920
Docker and Podman are used for running containers in a standalone environment.

2
00:00:10,920 --> 00:00:14,600
If you want to take it to cloud, Kubernetes is commonly used.

3
00:00:14,600 --> 00:00:19,840
Kubernetes is what we call a container orchestrator platform, and it's built to run containers

4
00:00:19,840 --> 00:00:22,400
in a cloud-native environment.

5
00:00:22,400 --> 00:00:23,400
So what is orchestration?

6
00:00:23,400 --> 00:00:27,920
Well, simple, orchestration makes that your container is running where it needs to be

7
00:00:27,920 --> 00:00:28,920
running.

8
00:00:28,920 --> 00:00:34,480
A cloud is normally a multi-server platform that can stretch out over a big region, and

9
00:00:34,480 --> 00:00:40,560
the orchestrator makes sure that your container is running exactly where it needs to be running.

10
00:00:40,560 --> 00:00:45,720
Using Kubernetes allows you to run containers in a flexible and cloud-native way.

11
00:00:45,720 --> 00:00:49,880
In order to do so, Kubernetes uses different resources.

12
00:00:49,880 --> 00:00:54,279
Let me make a drawing for you to talk about these resources and explain how all of them

13
00:00:54,279 --> 00:00:57,119
are related together.

14
00:00:57,119 --> 00:01:00,639
So Kubernetes is about running orchestrated containers.

15
00:01:00,639 --> 00:01:05,639
It all starts with the container.

16
00:01:05,639 --> 00:01:11,199
To add properties that allow you to manage the container, Kubernetes uses the notion

17
00:01:11,199 --> 00:01:17,919
of a pod, and the pod is a minimal entity that is used by Kubernetes.

18
00:01:17,919 --> 00:01:22,400
And in the pod, you can specify options for running the pod in the right location in your

19
00:01:22,400 --> 00:01:23,959
Kubernetes cluster.

20
00:01:24,959 --> 00:01:31,519
But the pod needs some scalability, and it needs some update strategies as well, and

21
00:01:31,519 --> 00:01:35,040
that is brought by the deployment.

22
00:01:35,040 --> 00:01:41,839
And that makes the deployment the most used resource for offering application access.

23
00:01:41,839 --> 00:01:47,239
Now, the deployment by itself needs help as well, and that is because of what we call

24
00:01:47,239 --> 00:01:48,879
decoupling.

25
00:01:48,879 --> 00:01:53,680
Because let's face it, a container is based on a read-only image, and how are you going

26
00:01:53,680 --> 00:01:56,800
to add your site-specific information to the deployment?

27
00:01:56,800 --> 00:02:03,000
Well, first, you are going to work with what we call the PVC, the Persistent Volume Claim.

28
00:02:03,000 --> 00:02:09,679
And a Persistent Volume Claim is what is normally going to reach out to get access to PV, which

29
00:02:09,679 --> 00:02:15,199
is a persistent volume, and this persistent volume is offered on the cloud.

30
00:02:15,199 --> 00:02:19,240
And that allows you to store your data in a way that it can be accessed independently

31
00:02:19,240 --> 00:02:23,639
of the application, and it will survive if your application goes down.

32
00:02:23,639 --> 00:02:30,039
Now, there are other resources as well, like, for instance, the ConfigMap.

33
00:02:30,039 --> 00:02:31,520
Why do we want a ConfigMap?

34
00:02:31,520 --> 00:02:35,960
Well, on Linux, you have a configuration file in the etc directory.

35
00:02:35,960 --> 00:02:40,399
In your container, well, you don't want to hard-code the configuration file, because

36
00:02:40,399 --> 00:02:42,320
then it wouldn't be changeable.

37
00:02:42,320 --> 00:02:47,600
And that is why you are going to inject the ConfigMap in your application.

38
00:02:47,600 --> 00:02:53,440
And if your configuration needs to be secured, you are going to use a secret, and inject

39
00:02:53,440 --> 00:02:57,720
that as a secured alternative to the ConfigMap.

40
00:02:57,720 --> 00:03:01,240
And then, still, you need to be able to access your application.

41
00:03:01,240 --> 00:03:06,720
And in order to access your application, Kubernetes uses the notion of a service resource.

42
00:03:06,720 --> 00:03:12,960
Now, this word is very confusing, because you would say a service resource, that's like

43
00:03:12,960 --> 00:03:15,880
a system D service, no, not at all.

44
00:03:15,880 --> 00:03:21,100
In Kubernetes, a service resource is like a load balancer that is giving you access

45
00:03:21,100 --> 00:03:23,419
to the port IP addresses.

46
00:03:23,419 --> 00:03:26,339
And that is necessary if your port has been scaled out.

47
00:03:26,339 --> 00:03:31,380
If there are multiple port instances, the service resource will make sure that your

48
00:03:31,380 --> 00:03:35,800
traffic is directed to the appropriate port.

49
00:03:35,800 --> 00:03:40,279
And to make the picture complete, you want to reverse HTTP proxy on top of that.

50
00:03:40,279 --> 00:03:43,619
And that is what is delivered by Ingress.

51
00:03:43,619 --> 00:03:48,059
And on modern Kubernetes, we call that gateway API.

52
00:03:48,059 --> 00:03:55,020
Gateway API or Ingress, they are receiving the HTTP and the HTTPS traffic that is coming

53
00:03:55,020 --> 00:03:56,020
in.

54
00:03:56,020 --> 00:03:59,619
So as you can see, quite a lot of resources play a role in Kubernetes.