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

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

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

4
00:00:19,860 --> 00:00:22,420
in a cloud-native environment.

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

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

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

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

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

10
00:00:40,580 --> 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,900
In order to do so, Kubernetes uses different resources.

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

13
00:00:54,299 --> 00:00:57,099
are related together.

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

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

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

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

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

19
00:01:22,419 --> 00:01:23,820
Kubernetes cluster.

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

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

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

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

24
00:01:47,220 --> 00:01:48,860
decoupling.

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

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

27
00:01:56,779 --> 00:02:02,980
Well, first, you are going to work with what we call the PVC, the persistent volume claim.

28
00:02:02,980 --> 00:02:09,660
And a persistent volume claim is what is normally going to reach out to get access to PV, which

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

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

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

32
00:02:23,619 --> 00:02:30,020
Now, there are other resources as well, like, for instance, the config map.

33
00:02:30,020 --> 00:02:31,580
Why do we want a config map?

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

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

36
00:02:40,539 --> 00:02:42,300
it wouldn't be changeable.

37
00:02:42,300 --> 00:02:47,580
And that is why you are going to inject the config map in your application.

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

39
00:02:53,820 --> 00:02:57,699
as a secured alternative to the config map.

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

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

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

43
00:03:12,940 --> 00:03:14,419
a system D service.

44
00:03:14,419 --> 00:03:15,860
No, not at all.

45
00:03:15,860 --> 00:03:21,080
In Kubernetes, a service resource is like a load balancer that is giving you access

46
00:03:21,080 --> 00:03:23,399
to the port IP addresses.

47
00:03:23,399 --> 00:03:26,320
And that is necessary if your port has been scaled out.

48
00:03:26,320 --> 00:03:31,360
If there are multiple port instances, the service resource will make sure that your

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

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

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

52
00:03:43,600 --> 00:03:48,039
And on modern Kubernetes, we call that gateway API.

53
00:03:48,039 --> 00:03:55,000
Gateway API or Ingress, they are receiving the HTTP and the HTTPS traffic that is coming

54
00:03:55,000 --> 00:03:56,000
in.

55
00:03:56,000 --> 00:03:59,600
So as you can see, quite a lot of resources play a role in Kubernetes.