10 videos 📅 2025-06-26 09:00:00 America/New_York
2:14:39
2025-06-26 09:07:32
1:12:32
2025-06-26 09:11:34
6:42
2025-06-26 11:08:41
35:51
2025-06-26 11:24:37
38:41
2025-06-26 13:21:35
20:37
2025-06-26 15:06:35
51:46
2025-06-27 09:06:19
58:45
2025-06-27 09:06:25
36:01
2025-06-27 11:26:09
1:12:38
2025-06-27 13:45:09

Visit the Kubernetes Comprehensive 2-Day course recordings page

                WEBVTT

00:00:00.590 --> 00:00:05.590
All right, I'm recording, but I don't do you.

00:00:05.590 --> 00:00:10.590
So you might have to refresh you or...

00:00:10.590 --> 00:00:12.590
Oh, there we go.

00:00:12.590 --> 00:00:15.590
Okay, all right, so what I was trying to say

00:00:15.590 --> 00:00:18.590
before I lost internet is you had an extra L in there,

00:00:18.590 --> 00:00:19.590
which is...

00:00:19.590 --> 00:00:23.590
Let's describe the pod and take a look at the pod.

00:00:23.590 --> 00:00:26.590
Or describe...

00:00:26.590 --> 00:00:27.590
Correct.

00:00:27.590 --> 00:00:29.590
And what did we label the node?

00:00:29.590 --> 00:00:38.030
Yep, so we're just going to re-vene on that file and just change the very bottom to test from fail.

00:00:40.530 --> 00:00:42.610
So we need to delete it first.

00:00:42.850 --> 00:00:45.690
So do you use that, but just change apply to delete.

00:00:46.990 --> 00:00:47.450
Oh, whoops.

00:00:47.550 --> 00:00:53.810
And you're going to use that same command, but that you had Coup control, apply them on itself.

00:00:53.910 --> 00:00:55.350
Just change the word apply to it.

00:00:55.350 --> 00:00:57.530
All right, friend your same test again.

00:00:57.530 --> 00:01:00.470
And we have node type equals test, right?

00:01:01.070 --> 00:01:02.690
So we put that in there correct.

00:01:03.190 --> 00:01:05.090
So now let's go look at the node.

00:01:05.550 --> 00:01:07.750
Let's just get the labels from the node.

00:01:07.750 --> 00:01:13.570
Q control, get nodes, and then hyphen, hyphen, show, hyphenly.

00:01:13.610 --> 00:01:15.590
All right, see if you can find that in there.

00:01:16.170 --> 00:01:17.750
Okay, what's in front of node type?

00:01:18.130 --> 00:01:18.330
Yep.

00:01:18.630 --> 00:01:22.170
Okay, so let's pseudo them again.

00:01:24.250 --> 00:01:29.840
There you go.

00:01:29.840 --> 00:01:31.920
And you will see teams use shortcuts.

00:01:32.520 --> 00:01:40.280
on node labels, but the proper convention is to use whatever the API is in front of it.

00:01:40.280 --> 00:01:44.200
In this case, it just happens to be Kubernetes.io, but there are others as well.

00:01:44.200 --> 00:01:49.160
And so if you get in a habit of using the Kubernetes convention in front of it,

00:01:49.160 --> 00:01:53.400
then you'll start to notice other teams that just use shortcut for label names.

00:01:53.400 --> 00:01:56.280
So if the label name needs to match, exactly.

00:01:56.280 --> 00:01:58.760
Okay, and test it again.

00:01:58.760 --> 00:02:00.200
All right.

00:02:00.200 --> 00:02:03.800
Yeah. Go ahead and check those events out.

00:02:05.000 --> 00:02:06.600
Take a look at the logs.

00:02:07.800 --> 00:02:09.560
There we go. We're up and running.

00:02:11.000 --> 00:02:14.280
All right. So how do we check the node resource utilization?

00:02:15.000 --> 00:02:19.240
So let's describe the node. All right, so you can see we have

00:02:20.440 --> 00:02:27.680
resource utilization. We've got requests for CPU of 5%,

00:02:27.680 --> 00:02:31.760
limits are zero, memory is 1%, limits are

00:02:31.840 --> 00:02:40.560
220 so that would be over here and then you can see our node nodal selector is zero CPU

00:02:40.560 --> 00:02:48.960
request zero memory zero limits so it has nothing that it is requesting okay delete the pod

00:02:48.960 --> 00:02:55.760
using a different method so we're going to do cube control delete on node nodule selector

00:02:55.760 --> 00:03:01.360
and we're going to also delete remove the label all right and it you can see it's very

00:03:01.360 --> 00:03:08.320
descriptive it told me that node nodal selector was deleted the pod and minicube was unlabeled right so we

00:03:08.320 --> 00:03:13.840
could go ahead and check those just to verify it it's pretty descriptive okay now we're going to check

00:03:13.840 --> 00:03:19.680
the kuk config expiration and signature algorithm locate the kube config file in the mini kube cluster and

00:03:19.680 --> 00:03:30.240
obtain the client search all right so ls there we go and we can see that um config is actually a file

00:03:30.240 --> 00:03:31.240
It's not very descriptive.

00:03:31.240 --> 00:03:32.240
It just says config.

00:03:32.240 --> 00:03:38.240
So I would name it a YAML file on my production clusters with a descriptive name.

00:03:38.240 --> 00:03:40.240
It's MiniCube.

00:03:40.240 --> 00:03:43.240
So you can cat the config and see what's in it.

00:03:43.240 --> 00:03:46.240
And where is the client cert located?

00:03:46.240 --> 00:03:50.240
So it's in the home minicube.

00:03:50.240 --> 00:03:54.240
Dot MiniCube Profiles minicube directory, right?

00:03:54.240 --> 00:03:58.240
So we're going to CD into that directory.

00:03:58.240 --> 00:03:59.240
Oh, yes, here's a student.

00:03:59.240 --> 00:04:06.240
student yeah they overwrite oh yeah and then remove the client dot cert so you can cd into that

00:04:06.240 --> 00:04:18.240
but then just remove client dot cert oh yeah it's remove client dot cert okay and cap the client

00:04:18.240 --> 00:04:27.040
dot cert okay what is the not after date show up to the top okay 20 25 so minicube gives you a three-year

00:04:27.040 --> 00:04:35.280
search. Now, production clusters typically have a one-year cert. MicroK8s gives you a 10-year,

00:04:35.360 --> 00:04:42.170
I believe. Then what type of signature algorithm is used? And you can change that, by the way,

00:04:42.210 --> 00:04:45.970
when you build your own clusters. You can use different types of signature algorithms.

00:04:47.230 --> 00:04:54.910
And then what X-519B3 extensions are present? And the CA is false. Did you notice that? So this cannot

00:04:54.910 --> 00:05:01.630
be used to generate server search within the cluster. This is just for connecting to the Kubernetes

00:05:01.630 --> 00:05:10.600
API. So this is your entrance into the cluster that you've protected all costs. All right. So in lesson

00:05:10.600 --> 00:05:17.000
one we learned how Kubernetes nodes and pods work together, how Kubernetes components work. We

00:05:17.000 --> 00:05:25.800
learned how Kubernetes versioning works and what needs to be done at the end of life, how to label nodes,

00:05:26.600 --> 00:05:31.600
how to pin nodes to a specific node using labels

00:05:31.600 --> 00:05:33.600
and node selectors.

00:05:33.600 --> 00:05:38.600
And what is the estimated life cycle

00:05:38.600 --> 00:05:40.600
of the Kubernetes cluster?

00:05:40.600 --> 00:05:41.600
And why?

00:05:41.600 --> 00:05:46.600
Well, the estimated life cycle is no more than 13 months, right?

00:05:46.600 --> 00:05:54.600
So when we look at the life, the end of life for each version,

00:05:54.600 --> 00:06:02.440
then the in a production cluster your TLS cert is good for 12 months typically so your life

00:06:02.440 --> 00:06:08.840
cycle of the Kubernetes cluster is about 12 months from the time it's created and you can

00:06:08.840 --> 00:06:14.520
extend your your cert out and you can definitely run a cluster past end of life without

00:06:14.520 --> 00:06:20.920
upgrading but it's designed to be upgraded it no more than a 12-month