WEBVTT 00:00.000 --> 00:00.900 Welcome back everybody. 00:00.900 --> 00:08.970 In this section we're going to talk about namespaces these logical boundaries that we use to group closely 00:08.970 --> 00:11.370 related resources in our cluster. 00:11.370 --> 00:17.520 But before we do that I want to start off by imagining that we've got this Kubernetes cluster deployed 00:17.520 --> 00:18.600 on AWS. 00:18.630 --> 00:19.020 All right. 00:19.050 --> 00:27.810 We've got many master nodes that decide when and where your container workloads will run, and worker 00:27.810 --> 00:31.710 nodes that do the actual work of running your containers. 00:31.710 --> 00:35.610 So each worker node has a container runtime that's used to create the containers. 00:35.610 --> 00:41.520 The Cubelet which wraps the pod construct around the containers, the kube proxy, which takes care 00:41.520 --> 00:43.620 of all the internal networking. 00:43.620 --> 00:47.700 So we've got all of these things happening behind the scenes. 00:47.700 --> 00:48.240 Right. 00:48.240 --> 00:52.800 And these worker nodes and master nodes, they work together. 00:52.800 --> 00:55.920 They collaborate in a very seamless way. 00:55.920 --> 01:01.080 That gives us the illusion that we're not working with all of these different machines, that we're 01:01.080 --> 01:06.840 working with just one, uh, Kubernetes environment, one Kubernetes entity. 01:06.840 --> 01:13.230 So while the Kubernetes cluster is physically divided into many, many machines, we kind of don't get 01:13.230 --> 01:15.660 that impression when we're interacting with it. 01:15.660 --> 01:21.600 Using the kubectl command line tool, we get the impression that we're working with just one entity 01:21.630 --> 01:28.230 now because we're prototyping, uh, we only have a single node cluster, our laptop that takes the 01:28.230 --> 01:29.760 role of master and worker node. 01:29.760 --> 01:31.530 So it is indeed one entity. 01:31.530 --> 01:37.680 But when you have a cluster on, let's say AWS or Azure, you're going to have many, many machines 01:37.680 --> 01:42.690 running Kubernetes that work together to, you know, orchestrate your containers. 01:42.690 --> 01:49.650 But regardless, the experience as the as a developer is not going to change whether I'm using a single 01:49.650 --> 01:55.050 node cluster or a multi node cluster, it's always going to feel like I'm working with this, with this 01:55.050 --> 01:58.770 one Kubernetes entity that's managing all of my pods. 01:58.770 --> 02:02.450 So while the cluster is physically divided into many, many machines. 02:02.450 --> 02:08.030 As developers, when we're interacting with the cluster, we get the experience that it's simply divided 02:08.030 --> 02:11.840 into logical boundaries called namespaces. 02:12.200 --> 02:15.170 A namespace is not a physical construct. 02:15.170 --> 02:19.490 It doesn't actually consume any resources, any memory or CPU. 02:19.520 --> 02:26.330 It's this logical construct created by the Kubernetes control plane that makes it really easy for us 02:26.330 --> 02:30.050 to group resources that are closely related. 02:30.050 --> 02:36.590 They are these invisible boundaries, these illusions created by the etcd database that make it really 02:36.590 --> 02:41.360 easy for us as developers to manage closely related resources. 02:41.360 --> 02:49.490 So I could have one namespace called Great Submission that stores all of the resources involved in the 02:49.490 --> 02:50.630 great submission experience. 02:50.630 --> 02:57.260 So the great submission portal, the great submission API, I could have one namespace called Freescale 02:57.260 --> 03:01.340 that has all the resources involved in setting up API gateways. 03:01.340 --> 03:07.090 I could have one namespace for logging that contains, you know, Elasticsearch Logstash, Kibana, 03:07.120 --> 03:14.410 one namespace for monitoring that has Prometheus and Grafana, whatever you need to monitor and visualize 03:14.410 --> 03:15.190 your metrics. 03:15.190 --> 03:21.280 So these namespaces allow us to group closely related resources. 03:21.280 --> 03:25.660 And this is really important because let's say you're working at an at an enterprise. 03:25.660 --> 03:28.240 You can't just access the cluster, okay. 03:28.270 --> 03:31.270 You're given credentials that you need to log in with. 03:31.270 --> 03:38.620 And based on your role, you can be given access to certain namespaces and be restricted to interact 03:38.620 --> 03:39.910 with other namespaces. 03:39.910 --> 03:46.060 So if your role is to just work on the great submission application, you would typically only be given 03:46.060 --> 03:50.290 access to the namespace that contains all of the great submission resources. 03:50.290 --> 03:55.210 So namespaces allow us to implement role based access control. 03:55.450 --> 03:59.080 Uh, namespaces can be given resource quotas. 03:59.080 --> 04:03.700 So I can say something like the group of resources for great submission. 04:03.700 --> 04:12.130 Only allocate to them one gigabyte of memory and one CPU core. 04:12.130 --> 04:20.830 So you can do things like this when you group your resources under one namespace under these logical 04:20.830 --> 04:21.730 groups. 04:21.760 --> 04:22.660 Okay. 04:22.660 --> 04:23.650 Enough preamble. 04:23.650 --> 04:28.180 Let's go ahead and look at things uh, in Kubernetes. 04:28.180 --> 04:30.760 So I'm going to clear the output from before. 04:31.510 --> 04:34.450 And what I'm going to do is just say section three. 04:37.360 --> 04:37.960 All right. 04:37.960 --> 04:43.180 And in order to maintain ordering I'm going to preface each folder with section one. 04:45.310 --> 04:54.070 0203 and I'm going to copy all of the contents of section two into section three. 04:54.070 --> 04:55.240 And let's begin. 04:56.830 --> 05:04.620 We'll start by saying kubectl get namespaces And I'm not running my Kubernetes cluster. 05:04.650 --> 05:06.540 Let me go ahead and start this up. 05:07.020 --> 05:08.790 Doo doo doo doo doo doo. 05:08.820 --> 05:10.380 It should be started up now. 05:10.620 --> 05:12.990 Um, kubectl get namespaces. 05:12.990 --> 05:18.510 So you can see that my cluster has been divided into these logical groupings. 05:18.510 --> 05:26.850 This default namespace groups together default workloads, this ingress engine X namespace groups together 05:26.880 --> 05:31.410 all resources related to ingress, which we'll talk about in another section. 05:31.410 --> 05:33.720 You probably don't have that namespace, so don't worry. 05:33.750 --> 05:39.720 The kube system namespace, which groups together all the Kubernetes critical system level components. 05:39.720 --> 05:45.390 So our cluster is logically divided into these groupings called namespaces. 05:45.390 --> 05:51.060 And by default we've been deploying all of our pods into the default namespace. 05:51.060 --> 05:57.030 So if I say kubectl get pods and if I say dash n default. 05:57.030 --> 05:59.760 So look inside of the default namespace. 05:59.760 --> 06:04.840 We've actually been deploying our pods to the default namespace this whole time. 06:04.870 --> 06:06.280 Okay, we don't want to do that. 06:06.280 --> 06:10.210 We want to put them in a in a great submission namespace. 06:10.240 --> 06:10.900 Okay. 06:10.900 --> 06:15.280 So we're going to delete pods dash dash all automatically. 06:15.280 --> 06:20.290 When you don't specify a namespace your current context is set to default. 06:20.290 --> 06:23.980 So it's going to delete all the pods in the default namespace. 06:23.980 --> 06:27.250 But just for clarity I'll say dash n default. 06:27.280 --> 06:30.010 Delete all the pods in the default namespace. 06:36.550 --> 06:40.660 Choo choo choo choo choo takes a bit of time. 06:44.830 --> 06:48.610 Okay, any time now. 06:58.630 --> 07:02.050 There you go and I'll CD out of section two. 07:02.080 --> 07:03.970 CD into section. 07:04.970 --> 07:06.230 003. 07:06.260 --> 07:07.340 Section three. 07:08.570 --> 07:18.860 And then what I can do is deploy every single artifact inside of the section three folder, so I can 07:18.860 --> 07:21.980 apply everything inside of the current directory. 07:22.010 --> 07:23.840 Dot means current directory. 07:23.840 --> 07:26.420 Apply everything inside of section three. 07:26.450 --> 07:28.730 Apply it in the namespace. 07:28.940 --> 07:30.620 Great submission. 07:30.830 --> 07:32.120 And what am I doing? 07:32.120 --> 07:34.310 I haven't even created that namespace yet. 07:35.030 --> 07:36.170 Sorry about that guys. 07:36.170 --> 07:39.560 Kubectl create namespace. 07:39.800 --> 07:41.270 Great submission. 07:42.770 --> 07:47.900 Okay, if I say kubectl get namespaces beautiful. 07:47.900 --> 07:53.660 We have a great submission namespace where we can put all of our great submission resources in all of 07:53.660 --> 07:59.540 our great submission services, all of our great submission pods, we can group them all under the great 07:59.540 --> 08:00.380 submission namespace. 08:00.380 --> 08:07.750 I'll say kubectl apply dash f apply every single configuration in the current directory and do it inside 08:07.750 --> 08:09.970 of the great submission namespace. 08:12.310 --> 08:13.720 Service is invalid. 08:13.720 --> 08:14.230 Invalid. 08:14.230 --> 08:14.590 Valid. 08:14.950 --> 08:20.350 Oh, remember how when the default namespace I deleted all the pods? 08:20.350 --> 08:23.410 I still didn't delete the services from there either. 08:23.410 --> 08:29.740 And here I'm trying to deploy a node port that conflicts with one that we already have. 08:29.770 --> 08:37.150 So back inside of the default namespace I'm going to say kubectl get services dash and default. 08:37.480 --> 08:40.990 And I want to delete the great submission API and the great submission portal. 08:40.990 --> 08:45.940 So I'll say kubectl delete uh service. 08:45.940 --> 08:47.620 Great submission API. 08:49.030 --> 08:55.180 Um I could have said dash and default and it would have known to do it inside of the default namespace. 08:55.180 --> 08:55.930 But you know what? 08:55.930 --> 08:57.370 I'll do it for the portal. 08:57.730 --> 09:05.440 Just to be clear, vary things up dash and default Same thing. 09:05.440 --> 09:09.660 Now if I say kubectl get services and default, they're both gone. 09:10.470 --> 09:16.440 So now I'm just going to rerun my command apply everything. 09:16.440 --> 09:21.720 So now our great submission portal service was created. 09:21.720 --> 09:22.740 Beautiful. 09:23.040 --> 09:25.050 Everything is happening. 09:25.260 --> 09:30.150 Get pods and services inside of the grade submission namespace. 09:30.750 --> 09:34.710 So now all of our pods are inside of the grade submission namespace. 09:34.710 --> 09:36.810 All of our services are as well. 09:36.840 --> 09:38.340 Everything should work the same way. 09:38.340 --> 09:44.490 You can feel free to test this out now instead of always saying dash n grade submission when we're applying 09:44.490 --> 09:45.660 our artifacts. 09:45.660 --> 09:47.070 What I want to do. 09:47.370 --> 09:52.650 So I just did this to show you, because you should always be aware of different ways of doing things. 09:52.650 --> 09:57.120 What you can also do is specify the namespace within the configuration itself. 09:57.120 --> 10:02.280 That way, no matter what the current context is, it'll always deploy in that namespace. 10:02.310 --> 10:02.910 Okay. 10:02.940 --> 10:13.290 It's uh, I believe it's, uh, less error prone when you concretely define it inside of the configuration 10:13.290 --> 10:13.680 itself. 10:13.680 --> 10:23.670 So within the metadata of each, um, definition, we say the name of the primitive as well as which 10:23.670 --> 10:25.980 namespace it will belong to. 10:26.010 --> 10:26.850 Okay. 10:27.060 --> 10:36.030 So spec always defines the behavior of that Kubernetes object and the metadata things like name namespace 10:36.030 --> 10:37.440 labels etc.. 10:38.700 --> 10:41.760 All right I think we're good now. 10:41.760 --> 10:46.020 So now what I want to do is delete every single pod. 10:46.050 --> 10:53.730 Delete pods and services dash dash all inside of the great submission namespace. 10:56.040 --> 10:56.550 Okay. 10:56.550 --> 11:02.880 So again, whether we're using a single node cluster as we are on our, uh, local machine currently, 11:02.880 --> 11:06.780 or whether we're interacting with a multi node cluster on AWS. 11:07.340 --> 11:13.820 We don't get the impression as developers that the cluster is actually made up of all of these physical 11:13.820 --> 11:19.460 machines that are collaborating together to, you know, schedule containers, manage all the control 11:19.460 --> 11:21.950 loops, set up the networking, etc. we don't. 11:21.980 --> 11:28.730 All of this is abstracted away from us, and all we see is this one entity with all of these logical 11:28.730 --> 11:32.630 boundaries that make it really easy for us to manage our resources. 11:32.810 --> 11:34.790 Okay, so we've deleted everything. 11:34.790 --> 11:46.040 And now if I simply apply every single configuration inside of the section three folder without specifying 11:46.040 --> 11:50.060 the namespace in my command, they're all going to go there by default. 11:50.090 --> 11:52.220 How do I verify kubectl. 11:52.250 --> 11:54.560 They're all going to go to the great submission namespace by default. 11:54.590 --> 11:57.470 I can verify this by saying kubectl get services. 11:57.500 --> 12:01.310 Get pods inside of the great submission namespace. 12:01.310 --> 12:03.080 If they're there, that means everything worked. 12:03.110 --> 12:04.280 Of course it's going to work. 12:04.310 --> 12:05.960 That's all we are done. 12:05.990 --> 12:07.430 See you in the next one.