Up next in 10
Namespaces and Health Checks - Kubernetes Fundamentals Ep. 7
10K views
Nov 1, 2023
Join this live session with Rodrigo Díaz Concha for the next episode of Kubernetes Fundamentals on February, Wednesday at 7:30 AM Pacific Time (US). After attending this session, you will learn about Services. ABOUT SPEAKER Rodrigo Díaz Concha is a Solutions Architect, Microsoft Regional Director, and Microsoft MVP with more than 22 years of experience. In addition, he is a book author, speaker, and course author for LinkedIn Learning. Rodrigo has dozens of professional certifications from different companies such as Carnegie Mellon SEI Software Architecture Professional, Microsoft Certified: Azure Solutions Architect Expert, Microsoft Certified: DevOps Engineer Expert, and HashiCorp certifications. He also has the distinction of having written the first books on Silverlight 5 and Xamarin.Forms in the Spanish language. C# Corner - Community of Software and Data Developers https://www.c-sharpcorner.com #CSharpCorner #CSharpTV #Kubernetes
View Video Transcript
0:30
Welcome to another session of the Kubernetes Fundamentals series
0:38
only here in C Sharp Corner Live. My name is Rodrigo, and today I'm going to talk about namespaces
0:49
and health checks in Kubernetes. Before we do that, let me do a quick recap
0:57
about the things that we saw the other day. You might remember the labels and annotations and selectors
1:05
Those are quite important in Kubernetes because they allow you to match things, right
1:13
For instance, when you create a deployment or you create, say, a service, how in the world the service or the deployment knows what are those pods in the backend that it should manage
1:30
So the answer there is the label and the selector, right? The selector says, okay, I want to manage
1:38
or I want to communicate to all of these pods that have
1:43
I don't know, maybe this label key equals value or something. So that's the way that Kubernetes matches things, okay
1:55
So I think this is a very important thing And it's a very elegant way to solve this communication problem
2:04
because you need that when you are using some of the objects in Kubernetes
2:10
such as deployments and services, right? So labels is this field or element that we can include
2:19
in the metadata element inside the JML file, right? In the manifest file
2:26
Of course, you can use the imperative way to set your own labels
2:32
However, most of the time you want to do this by using your gamma files
2:37
So this is the labels field. And inside this labels field, you can include any label that you want
2:45
So for instance, I have three labels here, environment, tier, and app
2:51
Those are fictitious labels that I'm using in this fictitious code that I have here on the screen
2:56
and you can use labels for querying. That's actually the difference between labels and annotations
3:06
Annotations is just metadata that you want to include in your objects, in your cluster
3:12
for managing or for annotating. I mean, I'm going sideways, right? I'm saying the same thing
3:22
However, that's the difference. You don't use annotations for querying your objects
3:28
You use labels, okay? So the selectors are these elements that you said
3:34
for specifying what are those labels that you want to use in that particular object, right
3:42
And we have two different kind of selectors. We have set-based selectors and equality-based
3:52
set-based and equality-based. So the difference is the operators that you can use for specifying your selectors
4:01
For instance, in equality-based selectors, you use equality operators, right? That's why they're named like that, okay
4:13
So you use the equals to or not equals to and so on. In set-based selectors, you use logical operators
4:22
such as in, not in, exists, doesn't exist, and so on. So for instance, we have here on the screen
4:32
this other example, such as kubectl get pods. I'm obtaining all the pods that have the environment label
4:42
that is not production. Or in the second one, I'm returning all the pods that the environment label has the production or the QA value
4:59
And some other things that we can do with selectors. Actually, you can use those for specifying and querying your objects
5:10
And most of the time, we're going to use that in deployments and services
5:14
and all the objects that support selection of objects, and mainly pods, okay
5:25
So yeah, selectors, labels, and annotations, as I mentioned before, those are just key value pairs
5:32
to annotate, to add some additional metadata in your objects, right? They allow you to attach arbitrary metadata to objects
5:44
And the difference between annotations and labels is that annotations are not queryable
5:51
That's the difference. And you can use annotations that are a lengthy list of annotations that Kubernetes suggests to use
6:06
However, you can use any kind of annotation, right? That's on you
6:11
It depends on your project. It depends on the functionality that you want to express
6:16
in your own applications. For instance, I have here this phone numbers annotations
6:25
As you can see, this is the annotations label, or I mean, the annotations field, right
6:32
inside the metadata section in this manifest file. So labels are used to identify and organize objects
6:41
while annotations are used to provide additional information about objects. So that's the difference
6:47
And we use some other kubectl commands to manage labels in annotations
6:54
such as kubectl label and kubectl annotate. You might remember in this other session that we had in the past
7:02
when I created a deployment, when you create a deployment and you show the history
7:11
history of deployments, deployments by default, they don't have any kind of annotation
7:16
they don't have any kind of cause, right? So you can not know why a rollout was made or a rollback was made So that why we use annotations However remember those are not querible That the difference And today I going to talk about namespaces and health checks
7:40
And of course, let's get started with namespaces. Okay. So the thing about namespaces is that
7:49
If you are familiar with namespaces in programming languages, I guess that's the same concept
8:01
They allow you to logically group resources. That's what you do in Kubernetes
8:07
There's a default namespace that when you deploy a Kubernetes cluster, we have this default namespace that we can use all the time
8:16
Actually, in this series, I've been using the default namespace all the time
8:23
So let's go back here to the terminal. And I just deployed this Minikube cluster with three nodes
8:34
Say, Minikube, let me see if this is running because I just executed the command and I didn't test the cluster
8:43
so minikube status to know if this is running yes it's running so min um sorry kubectl
8:51
kubectl get nodes so as you can see i have three nodes and we have this other object that is the
9:01
namespace so the alias is ns or you can just type namespace or namespaces or ns okay remember that
9:11
those are alliances that we can use in Kubernetes. So as you can see, I just deployed this MiniCube cluster
9:20
and all of a sudden I have those namespaces, right? Default, kubenovelist, kubepublic, kubesystem
9:30
What in the world is going on here? So for instance, default is the default namespace
9:37
not surprisingly, right? So any kind of object that you deploy and you create in your Kubernetes cluster is going to be deployed in that particular namespace
9:48
For instance, if I go here to my session 7 folder and I create a new pod, let's create a new pod here
10:01
Newpod.jml and let's use this template. I want to use NGINX and the container port is 80
10:11
Actually, I don't mind about that in this moment. I don't want any kind of resources
10:18
So I'm going to get rid of this. So this is my pod, okay
10:24
Just for testing purposes. And let's say kubectl apply file new pod.yml. pod.yaml
10:34
So this pod was created in the default namespace. So actually, if I say kubectl get pods
10:44
I don't see any kind of namespace column here in this query
10:49
Let's see if I execute all wide. So there's nothing telling me
10:56
that this is in the default namespace. However, let's describe pod, my app
11:06
And as you can see here, this is inside the namespace that is the default namespace, right
11:13
This is the name of the namespace that I'm using. I didn't specify anything else
11:18
I didn't specify otherwise, okay? So all the time, if you don't specify a namespace
11:25
this is gonna be using the default namespace. So namespaces provide the scope for names
11:33
not surprisingly, and they're similar to namespaces in programming languages. So for instance, you can create this my app pod
11:44
or my pod, right? Inside the default namespace, and you can deploy another pod with the same name
11:53
because it already exists in that particular namespace, right? However, if you create another namespace, you can create my pod with the same name in another namespace
12:07
That's why we say that they provide the scope for names. That's actually one of the traits of namespaces
12:17
There are some basic rules that namespaces follow. So the first one is that names of objects must be unique within the namespace, just as I'm telling you right now
12:29
So you can create, you know, MyPod twice in the same namespace
12:36
Of course, you can create MyPod in another namespace. However, the namespace should exist beforehand
12:43
Okay, so you should create namespaces beforehand before using them in your manifest files or in your imperative commands
12:53
Okay, so the other basic rule is objects in one namespace can access objects in a different one
13:01
Yeah, it makes sense, right? So for instance, you can, I don't know, maybe you can create a namespace named backend or blah, blah, blah, microservices or this specific domain for your applications
13:16
And you need these other pods, these other services that they need to communicate to these other services or pods that are implemented in other namespace
13:29
You can actually do that. Okay. You can do that. Number three, deleting namespace will delete all child resources
13:39
So I guess this comes in handy when you want to tear down an entire group of objects
13:49
You put those objects in a particular namespace and then after you use them
13:54
you can just delete that namespace and you're good to go. to go. Okay. And finally, namespace should exist before assigning objects to it. That's actually
14:10
what I told you before. If you want to use a namespace, it should exist. It's not going to be
14:18
created dynamically for you. Okay. So you should create a namespace beforehand. So what happens
14:26
with namespaces is that they span it across all the different nodes
14:32
that constitute the cluster, okay? So for instance, I have this namespace one
14:39
And as you can see, I could have different objects in that same namespace
14:45
And those objects might be deployed in different nodes, okay? So it doesn't matter if a namespace
14:54
is grouping all the objects those objects will be deployed in different nodes that stand still okay that one of the traits that I told you in the first session or second session of this series
15:09
about how the scheduler in kubernetes decides to deploy an object in a node
15:18
and of course you can have a number of different namespaces like namespace 2 namespace 3
15:24
or what have you. And the same trait in this same behavior
15:34
will be the same, okay? You can have different objects in different namespaces
15:40
And of course, those objects will be deployed in different nodes of the cluster, okay
15:44
Remember, namespaces are just logical groups for isolating objects, for grouping objects altogether, okay
16:00
So as I've mentioned before, there are four prebuilt namespaces in Kubernetes
16:05
I mean, I just deployed this MiniKube cluster. Let me go back to the terminal
16:11
So as you can see, if I execute get namespaces, all of a sudden I have those four namespaces
16:21
And of course the default namespace is the one that I'm using all the time
16:26
if you don't specify otherwise. And this is the same with any kind of cluster
16:31
If you deploy Kubernetes, you're gonna get those different default namespaces and pre-built namespaces
16:40
Because default is the same name as the default namespace. So, of course, if you create your own applications or you install additional tools or other components in your cluster, those applications or components can create additional namespaces
17:02
And actually that happens all the time. For instance, if you, I don't know
17:07
maybe you enable the Kubernetes dashboard, the dashboard is gonna add a new namespace
17:14
in your Kubernetes cluster because it's gonna deploy all the different components
17:20
and pods and services and all the different things that it needs
17:24
in that particular namespace. So it makes sense because in that way
17:31
applications and components can be sure that there's no a noisy neighbor, you know
17:39
And I think it's for management purposes and for easily, you know, manage things in your cluster
17:50
So, okay, so let me go back here to the terminal. So another flag that you can use
18:00
when you're querying your objects by using get is namespace. Actually, I think that's the namespace flag
18:10
Let's go back here to the help documentation and see if I can find the namespace option
18:19
Actually, I think it's dash n and then the name of the namespace that you want to use
18:29
So it's dash n and the name of the namespace. In this way, you are querying only four objects
18:36
in that particular namespace that you're specifying in the flag. Make sense
18:42
So that's neat. So let's see what's going on inside the cube system
18:53
namespace, oh, there are a lot of different pods that are running in this cluster
18:59
I didn't deploy those. Those were deployed and run by Minikube when it created the cluster, right
19:11
So for instance, you might remember when I talked about the control plane
19:16
and we talked about the Kubernetes architecture. So you might remember that we have this ETCD database
19:25
or it CD, whatever you want to call it, ETCD. That's the way that I like to pronounce it
19:34
ETCD is the database. This is a key value database that Kubernetes uses
19:40
for storing all the data that is receiving from your input and it stores the state of the cluster
19:48
So, if this ED turns out that it's running inside a pod inside the kubesystem namespace
19:54
that's why when you run and execute kubectl get pods, you cannot see those different pods
20:02
related to the Kubernetes system, you know? So, we can see that we have the EDCD minikube component here
20:11
I mean the pod, the API server, and some other things related to this Kubernetes cluster
20:20
So this is neat. This is the way that you can use
20:24
for querying specific namespaces. So let's try to see what's going on
20:30
with the kube public namespace. It looks like there's nothing there. Maybe if I query for all
20:40
let's see if there's something. No. and what happens with Kube node leads
20:48
and there are no resources in those other namespaces. Actually, I think the Kube system namespace is
20:54
the most important one when you deploy a freshly created Kubernetes cluster
21:02
Anyways, you can use the dash and then the name of the namespace for querying objects in a particular namespace
21:12
What are some of the use cases for namespaces? Why it's not a good idea
21:21
to use the default namespace all the time? Well, because maybe you have this cluster
21:29
for your organization and you want to get the most out of it
21:33
So it makes sense to structure your applications and things with namespaces, right
21:41
So for instance, our use case could be to map the organization structure
21:47
say team one, team two, team three, sales division, marketing, development, I don't know
21:57
To map your organization structure is one of the use cases that we can use with namespaces
22:05
Or development environments, such as development, production, QA and so on, Customer partitioning
22:12
I've seen this in the wild. I've seen this in real world applications
22:17
Say Contoso, Northwind Traders, and, you know, your own customers can have their own namespace inside your cluster And finally applications partitioning such as the different domains and components
22:35
that your applications have, such as portal, backend, security, and I don't know, the different domains
22:46
that your system spans, okay? Sorry about that. I've been coughing since yesterday. Cool
23:00
So how in the world we can get all the namespaces, kipcuddle get NS, get namespaces or get namespace
23:08
That's the command that we can use to get all the namespaces, okay
23:13
How we can create a pod in one particular namespace, you can specify the namespace flag
23:22
and then equals to the name of the namespace. For instance, let's try to run this particular command
23:32
Let's try to do this. As you can see, I'm creating this new pod named Nginx
23:40
my Nginx or what have you, right? and then the namespace flag and team one
23:48
What's going to happen? Because I don't have a namespace name team one
23:53
Remember that I have default kubenote list public and system. So what happens if I execute this
24:03
This is gonna return an error. And this is expected because the namespace team one
24:08
is not available. So I need to create this namespace beforehand. Okay
24:15
So I'm going to tell you that in a minute, how to create a new namespace, right
24:22
And well, this other command is very easy to grasp, get pods namespaced in one
24:28
That's actually what I did with the dash N. This is an alias of the double dash namespace flag. Okay
24:36
So another command that we can use that comes in handy when managing namespaces
24:44
is config set context and the current flag, because in this way you can set the namespace
24:53
for all the subsequent commands. So you don't have to specify dash n, dash n, dash n
25:00
all the time, make sense? So you can specify in your context for kubectl
25:06
for kubectl, right? You can specify a particular namespace that you want to use for all your different commands
25:14
So in this example that I have here on the screen, I'm using the team one namespace
25:25
for all subsequent commands. So, okay, that's neat. And how in the world we can create namespaces
25:34
So there are two ways, like any other kind of objects in Kubernetes
25:40
we have the imperative way and the declarative way. Okay. So imperatively we can use kubectl create namespace
25:50
such as this is very similar to the other create commands that we've seen in the past
25:59
kubectl create namespace. And if you want to use the declarative way
26:04
As you can see, the kind of object is namespace. Remember that kind is this field or element
26:12
inside your jammal file that specifies the kind of object that you want to deploy, right
26:19
So namespace is the kind. Now let's do that. kubectl create in the name of the namespace, kubectl
26:29
So what happens if I want to use namespace, team one? Okay, cube cuddle create namespace team one
26:39
Okay, so as you can see, I created imperatively this namespace so I can query for all the namespaces team one
26:50
There's nothing inside team one yet, get all namespace team one. I don't have any object inside this namespace
27:02
However, if I execute this command that I had before, as you can see this my NGINX pod
27:10
was created inside the TeamOne namespace. So if I execute kubectl get pods in this moment
27:19
you can see that I have the my app pod that I created beforehand
27:24
This is not the my NGINX pod that I just created. And this is because kubectl get pods is running
27:32
inside the default namespace, right? So I should change the default namespace
27:39
by using kubectl config and set context and the command that I showed you before
27:45
Or you can use dash n and the name of the namespace
27:50
that you want to query. In this other case, I'm returning my NGINX
27:56
which is the only, this is the only object that I have inside Team1, right
28:03
So I guess this is a very easy to grasp topic. So what happens if I delete this namespace
28:14
you can use kubicl delete namespace and the name of the namespace, which is Team1
28:21
And of course, all the different objects that are inside the namespaces will be deleted
28:26
inside this team one namespace, right? So if I query for all the namespaces
28:35
I don't have team one anymore. So that's the imperative way. Let's go back here and create a new file
28:49
Say that I want to create me my namespace.yml, right? And let's type namespace
28:56
or Kubernetes namespace namespace. No, I don't think, oh yeah, this is gonna work
29:06
This is great API version, kind, namespace, metadata, and the name of the namespace
29:13
So say team two. As you can see, I'm not using the spec field
29:21
This is not required for namespaces. You only need the API version, kind and metadata
29:30
Okay, very easy stuff. So let's go back to the terminal and kubectl apply file my namespace
29:43
and I created this namespace, okay? kubectl, get namespace. And as you can see, I have team two
29:53
So I can use Team 2 for deploying my objects. Of course, I need to change my pod.jamml to
29:59
find that I want to deploy the new pod in team two
30:03
Anyways, very easy stuff, I guess. kubectl delete namespace team two. So I can do this
30:13
or I just can pass the myNamespace.jml file to the delete command
30:21
And it's not necessary to specify the name of the namespace. is kubectl is gonna figure out
30:30
what object I'm trying to delete and it's gonna do that for me
30:36
So this is great. This is for structuring your applications and objects
30:44
And I think this is a very easy topic to grasp. Now let's talk about health checks
30:54
So the thing about applications that are running inside a Kubernetes cluster is that they can go wrong, right
31:05
You can deploy your application and maybe one of those pods or microservices or what have you, they can be in a faulty state and you don't know about that until it's too late. okay
31:20
so we can use health checks to determine the state of a container
31:25
or pod inside your Kubernetes cluster so they allow Kubernetes to monitor
31:34
the health of your application and determine when to take action so health checks
31:40
are great because they can do things for you or wait for things to happen
31:48
and because sometimes your applications can be doing something when they start, right
31:59
Maybe you are querying this database. Maybe you are calculating some things
32:03
and maybe your application is not in a ready state. So you should notify Kubernetes about that
32:13
And that's another use case for health checks. Actually, we have three types of health checks in Kubernetes
32:24
The first one is liveness. It allows you to specify a health check
32:34
to be performed against a container to determine if it's alive, okay
32:41
This is the first health check that we can use to determine if it's alive
32:48
Because, again, maybe you deploy your application, maybe you create this deployment, right
32:56
And maybe those container images will be downloaded, and maybe your application is behaving correctly, and all of a sudden, the application is not running anymore, or is not responding to requests anymore
33:11
So you might use in that particular case, a liveness probe to notify Kubernetes
33:18
hey, this pod is not behaving correctly. It's not alive. I know that the container has this pod
33:28
I'm sorry, the pod has this container. However, maybe it's not responding anymore
33:35
In that particular case with a liveness probe, the container will be restarted if the probe fails
33:43
So actually it's like any kind of probe that we can deploy in our applications
33:49
This is very common when you deploy, say a load balancer in a cloud
33:55
you specify a probe to detect if the particular node that is backing the load balancer is alive or not, right
34:07
So it's a very similar concept. So in this way, Kubernetes can restart the container automatically
34:18
if the probe fails. So that's the first health check. The second one is readiness
34:26
This is a periodic probe of container service readiness. So readiness means that it specifies a health check
34:35
to be performed against a container to determine if it's ready to receive traffic
34:43
Why? Because again, maybe in your applications, you have this, I don't know
34:50
this script that you need to run or this calculation that you need to execute
34:58
or this query that is very lengthy. So maybe if you do that
35:07
when you start your container, the container is not ready yet, right
35:13
It's not ready yet to receive traffic. That's why we can use this kind of probes
35:18
to tell Kubernetes, okay, I'm alive, but I'm not ready yet. Okay, that's different
35:25
And what happens if this readiness probe fails? Well, the container will be removed
35:32
from the service endpoints. Remember that services use a backend pool of pods right To direct traffic to them So if a particular pod is not responding
35:47
because it's readiness probe failed, then that particular pod will be removed
35:55
from that back and pull of the service, okay? So it's not going to be restarted
36:02
That's for liveness probes. And finally, the third one is startup
36:15
This is used when you want to indicate that the pod has successfully initialized
36:22
Very similar to readiness. Okay. Again, if it fails, this pod will be restarted
36:34
Very similar to the liveness probe. So again, this is for, maybe you want to use this starter probe for
36:45
I don't know, maybe you want to run a script or you want to execute this particular application
36:51
I don't know. then you can use the startup probe. So as you can see here on the slides that I'm using
36:59
I have this pod.spec.containers.blahblahblah. Those are the different fields inside the pod specification
37:11
where you can deploy your probes. So for instance, let's go back here to liveness
37:18
of spec containers liveness probe. So I can go back here to the terminal
37:25
and execute kubectl explain and pod spec containers liveness probe
37:39
Okay. So again, explain is the best documentation that you can get for Kubernetes
37:48
In this way, you can understand what are those different fields that you can include in your manifest files
37:59
So as you can see, I have different fields that I can use for specifying this liveness probe
38:04
such as success threshold, TCP socket, HTTP GET, exec, and so on
38:15
Actually, I have a demo right here and I'm going to show you right now
38:22
that is using this liveness probe and it's using two different techniques
38:29
for probing this particular pod, right? The first one is command execution
38:36
and the second one is executing a HTTP GET request. So talking about mechanisms or techniques
38:47
there are three mechanisms that we can use in probes to understand and to detect
38:57
if the probes are behaving correctly. So the first one, as I mentioned before
39:03
is the command execution. Maybe you want to execute this particular command
39:07
in order to know if the pod is behaving correctly. The second one is a HTTP GET request
39:18
And this is of course for maybe you have this container that is using a web framework or something
39:26
Maybe you're using, I don't know, Node.js or maybe you're using ASP.NET Core
39:33
And then you can expose an endpoint in those particular applications so Kubernetes can create this HTTP GET request
39:45
It can send this request to that particular endpoint to know if that particular pod is behaving correctly
39:53
Make sense? This is a very popular way of detecting if things are behaving correctly
40:01
And the third one is TCP socket and it's very similar to the previous one
40:08
You specify something that you want to send via TCP instead of HTTP, the HTTP protocol
40:21
So as you can see here on the screen, Leibniz probes, readiness probes, and startup probes
40:31
Those are fields inside the containers field that is inside the spec of a pod, right
40:40
So in other words, probes and health checks are related to those containers
40:48
that are running inside your pods. That's why I executed pod.spec.containers, liveness probe
40:58
I passed this structure, this path to explain because Leibniz probe, or Redness probe
41:05
or Startup probe, those are part of containers. So as you can see here on the screen
41:14
there are a lot of things that are going on here in this demo The first one is that it using the busybox container image Busybox is very helpful container image
41:30
that we can use in our applications. Actually I have the official busybox container image
41:40
webpage here on the browser. And as you can see, This is the Swiss Army knife for embedded Linux
41:48
It's a very small container image, Linux based, that has dozens of different tools and applications
41:59
that we can use to execute things. For instance, it has, I don't know, wget or curl or whatnot
42:09
It has dozens and dozens of different applications and commands. So this demo is using busybox
42:18
And as you can see, this is executing touch. In other words, it's creating a new file
42:27
and then it's waiting for 30 seconds, okay? And then it's removing the file that was created
42:40
So it first creates the file and then it waits for a little bit
42:45
and then it removes or deletes the file and then it just waits forever
42:50
I mean, for 60 seconds, not forever, right? Sleep 600 is 60 seconds and 600, it's 600 seconds, okay
43:05
Not 60, 600, okay? And then, as you can see here on the Leibniz probe field, it's executing this command, which is cat. As you know, cat is used in Linux for returning the contents of a specific file, right
43:26
cat and then the name of the file. It's supposed to return the contents
43:32
of that particular file. And of course, if you deleted the file
43:38
then it would fail, right? So this is going on here on this demo
43:46
by using the command execution. And it's doing this after five seconds
43:52
and then it's doing this each five seconds, okay? So as you can see here
44:00
there are a lot of things that are happening, right? However, it comes in handy and it's quite interesting
44:08
So I'm not going to type this. That's why I created this pod.jml file already
44:22
So I created this file beforehand, just to expedite this process. As you can see, I'm creating this my app pod, right
44:34
And it's using the busy box and all the things that I just described, right
44:39
I just pasted the code that I showed you right here inside the spec, okay
44:48
So, I can, this is the pod.jama file. Actually I deployed this, get pods
45:02
As you can see, this is running. Okay. And this is because I deployed this pod
45:08
before I started today's session. So let me delete the, my app pod
45:17
Okay. so I don't have any more pods so let's apply file pod.jaml file and I deployed this pod
45:31
so I can execute kpods again and if I kubectl describe pod and
45:43
And this is running, right? Remember that it waits for 30 seconds
45:53
before deleting the file, right? So it's probing that everything is behaving correctly
46:03
That's why this application is running correctly, right? However, after 30 seconds, it's gonna fail
46:12
As you can see here, warning, unhealthy. This is the reason of why this is
46:20
this is the reason why I received this warning. Let me zoom out a little bit, okay
46:26
LivenessProbe failed, because I can't open the healthy file, no such file or directory
46:38
It makes sense, right? because the liveness pro was, each five seconds was executing cat, cat, cat, cat
46:50
and then all of a sudden the file is deleted. So this pod is not live anymore Okay So this is gonna be restarted and it gonna be restarted all over again
47:07
and all over again, because that's the trait and that's the behavior of liveness probes
47:14
Okay. Let's describe it again. So as you can see, the pod is restarted and restarted and so on
47:25
as you can see, it has one restart, right? And after a while it's gonna be two and then three
47:35
and then four and all over again. So this is great. This is great for notifying Kubernetes
47:49
Hey, this is not behaving correctly. This is the, actually, but the reason why you want to use health checks, okay
48:00
So here's another example with a different technique. In this case, it's using HTTP GET
48:10
So as you can see, it's using another container image, which is liveness
48:17
Liveness is another container image that comes from Kubernetes and it allows you precisely to test this, okay
48:26
So this is gonna expose an endpoint and if that HTTP GET request fails
48:37
then I'm going to receive the warning, okay? So as you can see, this is different
48:44
because I have to specify the HTTP GET field and the path of the endpoint, right
48:52
and the port number and some HTTP headers that you might want to use in your request
49:02
And again, initial delay seconds that you want to wait before starting the probe and period seconds is
49:12
the number of seconds that you want to use each time before sending the request
49:20
So again, very easy stuff. And of course this is just for testing purposes
49:28
I mean, the Leibniz container image. What would you do if you want to implement this
49:38
in your applications? You need to specify and you need to implement
49:42
this endpoint, right? In your microservices or containers. So for instance, I don't know, I'm just going to use .NET Core
49:54
because I happen to be a .NET user since 20 years ago
50:01
So I can do this test web API or something. I'm not going to deploy an entire web API in this moment
50:08
because I need to containerize this web API and I'm not going to use this
50:14
And I'm not going to do this because I don't have the time in this session
50:19
However, just for explanation purposes, you would need to implement a endpoint somewhere
50:31
Maybe you're using controllers. So you need to specify a HTTP GET attribute inside of
50:39
on top of those methods that you want to expose at endpoints
50:43
or maybe you're using minimal APIs, which is a new technique for creating web APIs
50:50
in .NET 6 and .NET 7. So at the end of the day, you need to express
50:58
and you need to deploy and implement this particular endpoint that you want to use
51:06
for your Leibniz pros, okay? I hope this makes sense. Anyways, if you want to test this
51:15
you can use the Leibniz container image. So, this is what I had for today
51:29
In the following session, we're going to talk about config maps and secrets
51:35
those objects allow developers and architects to use those places to store configuration keys
51:48
in values or secrets. You know, for storing dirt, I don't know
51:55
connection strings or API keys or whatnot, it's not a very good idea to, of course
52:01
use your hard coded the strings, right? That's not a good idea
52:07
So that's why we can use config maps and secrets and that's the topic for next session
52:18
Cool. So thank you for your time and see you in the following session
52:27
of the Kubernetes fundamentals series. Thank you
#Software