WEBVTT 00:01.085 --> 00:03.857 In this video, we're going to go over Mock Exam 2. 00:04.742 --> 00:08.828 Let me first set up my environment so I don't have alias. 00:09.457 --> 00:10.657 Let me do that first. 00:14.028 --> 00:16.228 Kubectl cheat sheet. 00:19.228 --> 00:21.428 Let me first have the auto-completion 00:22.542 --> 00:26.742 and the kubectl alias. 00:34.457 --> 00:35.885 That seems to be working. 00:37.000 --> 00:38.142 All right, so let's get started. 00:38.600 --> 00:41.685 The first question is to take a backup of the etcd cluster 00:41.771 --> 00:43.114 and save it to this location. 00:44.114 --> 00:44.971 To take a backup, 00:45.142 --> 00:47.942 we use the etcdctl utility but let's see. 00:49.685 --> 00:51.914 Let's look at the Kubernetes documentation pages. 00:52.200 --> 00:54.171 Etcdctl backup. 00:56.742 --> 01:00.314 Here you have a operating etcd cluster for Kubernetes 01:00.742 --> 01:02.628 and here if you look at here on the right, 01:02.714 --> 01:05.342 you have the backing up an etcd cluster section, 01:05.685 --> 01:08.828 and here we have this command. 01:09.657 --> 01:10.942 We're going to use this. 01:15.714 --> 01:17.542 Let me just save that here. 01:18.457 --> 01:23.457 Now we know that in order to communicate with the etdc server, 01:24.057 --> 01:26.771 we need the endpoint and we also need the certificates. 01:27.057 --> 01:34.971 If you do a etcdctl snapshot command, 01:36.885 --> 01:40.457 you look at the help, we have a few options that are required, 01:40.571 --> 01:43.028 the cacert, the cert, the key 01:43.542 --> 01:46.628 and then we're going to specify this as the location. 01:47.342 --> 01:49.142 First, we need to get those parameters. 01:49.228 --> 01:58.485 We're going to look at the etcd servers manifest file 01:58.714 --> 02:00.942 and we can just do a grab for file, 02:01.028 --> 02:04.828 and we get to see all of the files that are passed in as parameters. 02:05.428 --> 02:06.257 We'll start from there. 02:06.371 --> 02:07.171 Let's do-- 02:09.200 --> 02:11.114 The other thing is the endpoint. 02:11.228 --> 02:12.885 That's another thing that we need. 02:13.457 --> 02:16.057 If we go into this file, 02:17.400 --> 02:22.971 we see that the endpoint is 127001 and the port is 2379. 02:27.000 --> 02:28.457 Let's get out of that. 02:30.714 --> 02:32.085 We're going to start here. 02:32.228 --> 02:33.514 Let's get all of this. 02:36.050 --> 02:39.371 You can either set the endpoint as an environmental variable 02:39.457 --> 02:40.514 or just pass it through. 02:40.600 --> 02:41.571 Let's just do this. 02:41.714 --> 02:46.142 127001, 2379, that's the port. 02:47.657 --> 02:50.228 The file name is this. 02:52.942 --> 02:55.685 Then we'll just pass in the remaining things here. 02:56.942 --> 02:58.857 The first thing that we need is cacert. 02:58.971 --> 03:00.085 We're going to pass that in. 03:02.114 --> 03:05.257 The file name is ca file is right here. 03:09.200 --> 03:11.971 The next thing, we need is cert 03:15.600 --> 03:18.228 and the certificate file is right here. 03:21.657 --> 03:24.057 The next one is the key 03:27.200 --> 03:30.228 and the key file is right here. 03:34.028 --> 03:38.028 It says, "Snapshot saved at opt etcd backup." 03:38.114 --> 03:39.257 Let's just verify. 03:41.457 --> 03:45.371 That's ended there. 03:45.742 --> 03:47.142 Let's go to the next question. 03:48.114 --> 03:50.685 The next question is to create a Pod called redia-storage 03:50.885 --> 03:55.285 with the image resid:alpine with a Volume of type emptyDir 03:55.371 --> 03:58.657 that lasts for the life of the Pod. 03:59.285 --> 04:00.342 Specs are given below. 04:01.028 --> 04:02.200 To create a Pod, 04:02.342 --> 04:04.628 we're just going to use the kubectl run command 04:05.057 --> 04:08.657 and the Pod name, it's going to be redia-storage, 04:09.142 --> 04:12.657 and the image is going to be redis:alpine. 04:14.742 --> 04:16.857 Now we've got to specify the volume. 04:17.942 --> 04:22.542 For now, what we're going to do is we're just going to do a dry run 04:22.657 --> 04:23.542 and close client, 04:23.685 --> 04:26.000 and generate this into a yaml format. 04:26.628 --> 04:30.657 That's that and then we're going to move that to the file 04:30.971 --> 04:32.428 with the name of the Pod. 04:35.771 --> 04:37.457 Now we've got to specify the volumes. 04:37.571 --> 04:40.914 Let's look up pods and volumes 04:41.971 --> 04:44.285 and we have this one right here, 04:44.914 --> 04:49.200 and this talks about all of the different options for volumes, 04:49.314 --> 04:51.285 and what we want is the empthyDir. 04:51.914 --> 04:55.457 As you know the emptyDir is used to create a Pod 04:55.942 --> 04:59.657 and it's a temporary volume that's created 04:59.771 --> 05:01.742 and it exists as long as as long as the pod is running. 05:02.657 --> 05:04.428 Here's an example. 05:05.371 --> 05:07.400 You have the volume and you have the volume mount. 05:07.571 --> 05:08.857 Let's create the volume first. 05:09.914 --> 05:13.742 We'll just edit the yaml file we created 05:14.228 --> 05:19.457 and the volume is always under the pod spec, 05:19.771 --> 05:20.400 it's right here. 05:20.885 --> 05:26.257 Here we are using the emptyDir as given here, 05:26.914 --> 05:28.771 but let's see if there's a name. 05:28.942 --> 05:32.400 The question does not really ask us to use a specific name, 05:32.540 --> 05:33.685 so we could use any name. 05:33.771 --> 05:35.257 In this case, we'll just leave it as it is. 05:35.542 --> 05:38.714 We'll just call it cache volume, and then you have the volume mount. 05:38.857 --> 05:39.742 Let's copy that. 05:39.857 --> 05:45.142 This is inside the container section and we'll paste that here. 05:47.028 --> 05:50.171 Now, this volume name and this mount name, 05:50.800 --> 05:52.857 the volume name that's given here needs to match, 05:52.971 --> 05:56.257 so this needs to be the same, but the mount path could be anything. 05:57.085 --> 06:02.628 There is a path given here called /data, /Redis. 06:02.771 --> 06:06.485 We're going to use that as the path. 06:10.228 --> 06:17.657 Redis-storage, the name is Redis storage, image is Redis Alpine. 06:19.800 --> 06:23.428 The volume type, volume type is empty Directory 06:23.800 --> 06:26.285 and the mount path is data Redis. 06:26.850 --> 06:31.628 Let's save that and let's create the file. 06:36.142 --> 06:37.400 It's being created. 06:39.228 --> 06:40.857 Let's just give it a few seconds. 06:41.571 --> 06:47.000 It's done and we'll just do a describe pod Redis, 06:47.114 --> 06:49.314 just to verify if everything's good. 06:49.428 --> 06:52.514 Here you can see the mount is data Redis from cache volume, 06:53.114 --> 06:56.371 and here you have the cache volume and the type is empty directory, 06:56.457 --> 06:58.628 a temporary directory that shares a pod's lifetime. 06:59.857 --> 07:00.885 That's that. 07:01.228 --> 07:02.571 Let's go to the next one. 07:03.571 --> 07:06.800 The next one is to create a new pod called super-user-pod 07:07.050 --> 07:09.428 with image busybox 1.28, 07:09.571 --> 07:12.828 to allow the pod to be able to set system time. 07:13.142 --> 07:16.514 The container should sleep for 4,800 seconds. 07:17.342 --> 07:18.457 Let's first create a pod. 07:18.571 --> 07:23.485 So we're going to do kubectl, run, super-user pod, 07:24.000 --> 07:28.142 image is busybox 1.28. 07:29.000 --> 07:33.628 Then I'm not sure if we can pass in the capabilities. 07:34.400 --> 07:39.171 Let's just check help, security context. 07:49.971 --> 07:51.200 Search for security. 07:51.771 --> 07:53.171 No. I don't think so. 07:54.857 --> 07:58.571 We're just going to go the traditional route. 07:58.685 --> 08:01.428 We're going to create the pod 08:02.600 --> 08:10.800 with the image busybox 1.28, 08:11.714 --> 08:14.742 and we'll just do a dry run 08:18.542 --> 08:20.885 and output AML file for that 08:21.085 --> 08:26.257 and output that to super-user-pod.aml. 08:29.257 --> 08:32.885 Then we will edit that file. 08:34.542 --> 08:36.828 Then now the goal is to allow the pod-- 08:36.914 --> 08:39.657 There's also a command, so I could have given the command 08:40.114 --> 08:42.342 in the [?] command that I ran, 08:42.542 --> 08:44.285 but since I didn't do that I'm just going to add it here. 08:44.428 --> 08:51.000 The command is to sleep, sleep for 4,800 seconds. 08:53.628 --> 08:55.428 The only thing that's pending now 08:55.542 --> 08:58.542 is to allow the pod to be able to set the system time. 09:00.914 --> 09:04.428 We know that it's under security capabilities, 09:06.628 --> 09:10.085 so configure a security context for a pod in a container. 09:11.371 --> 09:14.314 If you look here, you have set capabilities for a container, 09:17.028 --> 09:18.600 and let's take a look. 09:19.800 --> 09:21.971 Right here, you have security context and capabilities. 09:22.114 --> 09:22.914 This is what we need, 09:23.142 --> 09:25.085 and this needs to go inside containers, 09:25.200 --> 09:28.857 so right here, inside the container section, 09:28.971 --> 09:31.000 we have security context and capabilities. 09:31.600 --> 09:33.857 We don't need the net admins, I'm going to remove that, 09:34.171 --> 09:36.114 and it just needs system time. 09:38.600 --> 09:39.571 Save that. 09:40.400 --> 09:42.714 Let's create the file, 09:45.228 --> 09:46.142 let's create the pod, 09:46.285 --> 09:48.742 and then let's check the status and its running. 09:49.057 --> 09:52.742 Let's do a describe pod, super-user-pod. 09:57.685 --> 10:01.142 Here we have the super-user-pod, we have the command. 10:05.628 --> 10:06.971 Let's go to the next question. 10:07.771 --> 10:13.342 The next question is a pod definition file is created at root CK use PV.Yaml. 10:13.485 --> 10:15.628 Let's take a look at that. 10:19.171 --> 10:20.685 We have a pod definition file. 10:20.942 --> 10:22.314 Make use of this manifest file 10:22.400 --> 10:25.400 and mount the persistent volume called PV1, 10:25.600 --> 10:28.028 and ensure the pod is running and the PV is bound 10:28.142 --> 10:29.457 so that there's a mount path given. 10:29.628 --> 10:32.028 There's also a persistent volume claim name given. 10:32.885 --> 10:35.228 There's a pod definition file. 10:35.571 --> 10:36.314 Let's check. 10:36.540 --> 10:39.514 There is there a PV, so there is a PV. 10:39.771 --> 10:41.742 Let's check if there is a PVC. 10:41.885 --> 10:43.200 There aren't PVCs. 10:43.457 --> 10:49.057 What we need to do is, in order to mount this PV to the pod, 10:49.428 --> 10:51.742 we know that we're going to add a volume mount here 10:51.885 --> 10:53.542 but the volume mount requires a volume. 10:53.657 --> 10:57.171 That volume is going to be from a persistent volume claim 10:57.285 --> 10:59.885 because that's how you claim a PV. 11:00.828 --> 11:02.800 We have to create a PVC. 11:03.057 --> 11:05.000 The first step is to create a PVC, 11:05.114 --> 11:08.085 and then configure that as a volume mount within the pod. 11:08.200 --> 11:09.171 As a volume in the pod 11:09.257 --> 11:11.542 and then configure that volume as a volume mount in the pod. 11:11.885 --> 11:15.171 PVC, volume, and then volume mount. 11:17.857 --> 11:19.685 Let's look at PVCs. 11:22.771 --> 11:24.600 We have personal volume here. 11:25.600 --> 11:28.714 If you go to persistent volume claims, 11:28.828 --> 11:31.000 you have persistent volume claim definition file here. 11:31.314 --> 11:32.457 Let's just copy this. 11:36.314 --> 11:39.171 What we want to do is we want to create a PVC 11:39.485 --> 11:43.142 but for that, we need to know the capacity and the access mode. 11:43.600 --> 11:44.828 We need to get those two, right, 11:45.314 --> 11:48.028 only then it's going to be bound to this PV. 11:48.828 --> 11:53.457 The capacity is 10 mebibytes, and access mode is read-write only. 11:53.828 --> 11:56.057 Let's create a PVC.Yaml. 11:59.685 --> 12:02.600 Let's copy this template. 12:04.085 --> 12:07.057 The name is my PVC. 12:07.514 --> 12:09.257 My-PVC. 12:09.657 --> 12:11.828 The access mode is read-write once. 12:12.057 --> 12:14.142 Volume mode is none. 12:14.228 --> 12:20.542 Then we have storage and that is 10 mebibytes. 12:21.171 --> 12:25.057 That should be it so let's create the PVC. 12:27.714 --> 12:31.428 Okay, let's check the status, get PVCs. 12:32.285 --> 12:35.571 We see that the PVC is created and it's bound. 12:35.857 --> 12:37.142 It's bound to the PV-1. 12:37.228 --> 12:39.028 The capacity and access modes match. 12:39.714 --> 12:42.114 We've done the first step of creating the PVC. 12:42.314 --> 12:46.771 The next step is to use it as a claim in the pod. 12:46.914 --> 12:48.600 Let's edit this file. 12:50.628 --> 12:53.485 We need two things. We need a volume and then a volume mount. 12:55.114 --> 12:56.257 Let's go back here. 12:56.400 --> 13:00.000 Let's look at claims as volumes, this section right here. 13:00.457 --> 13:02.114 Then we have the personal volume claim. 13:02.200 --> 13:03.771 We're going to copy this template. 13:04.171 --> 13:06.085 This is under the spec section. 13:06.914 --> 13:11.171 Volume, and does it need-- 13:11.485 --> 13:13.685 The volume name could really be anything. 13:15.828 --> 13:18.828 We haven't been given any volume name so we can leave that as my PV 13:19.028 --> 13:23.485 but the persistent volume claim has to be the one that we just created. 13:23.600 --> 13:25.314 That's My-PVC. 13:25.971 --> 13:29.942 Then inside here, we're going to have the volume mount. 13:35.342 --> 13:39.571 The mount path is going to be data so that's data. 13:40.457 --> 13:44.171 This name is MY-PD so this and this need to match. 13:44.885 --> 13:45.914 They're already matching. 13:46.657 --> 13:49.000 We've not been given a specific name to use 13:49.114 --> 13:50.542 so we'll just leave it as it is. 13:50.771 --> 13:53.971 We have my PVC here and it's going to be Mount2Data. 13:54.685 --> 13:57.685 Let's create that pod 14:01.685 --> 14:03.514 and let's check the pod status. 14:04.657 --> 14:08.000 You see that it's in a container-creating state. 14:08.171 --> 14:11.571 Let's give it a few seconds to be created. 14:14.400 --> 14:15.942 That's done. 14:22.857 --> 14:26.571 It's use PV so we're going to do a kubectl describe 14:29.142 --> 14:33.428 use pod-usePV. 14:34.742 --> 14:37.000 Okay, and here we see 14:39.857 --> 14:42.514 we have the mount data from My-PD 14:43.114 --> 14:46.542 and while your My-PD is from persistent volume claim, 14:47.057 --> 14:49.742 and it's using the My-PVC. 14:50.400 --> 14:51.057 All right. 14:51.742 --> 14:54.000 Okay, so that's about it for that question. 14:54.114 --> 14:55.142 Let's go to the next one. 14:56.420 --> 14:58.914 The next one is to create a new deployment called NGINX Deploy 14:58.971 --> 15:02.628 with image nginx:1.16 and one replica 15:02.742 --> 15:05.657 and then upgrade the deployment to version 1.17. 15:08.171 --> 15:12.657 Let's create a deployment, so kubm ectl create deployment. 15:13.257 --> 15:15.571 We'll call it nginx-deploy. 15:16.000 --> 15:17.828 Let's just copy and paste. 15:18.714 --> 15:24.628 It has to use the image nginx:1.16 15:25.171 --> 15:28.200 and replica is going to be one, 15:29.971 --> 15:32.342 replicas is going to be one. 15:32.828 --> 15:36.685 Okay, so let's do a kubectl get deploy. 15:40.857 --> 15:42.228 It's just getting ready. 15:45.171 --> 15:46.542 Yes, so it's ready. 15:47.710 --> 15:55.142 Let's do a kubectl describe deployment, nginx-deploy 15:55.771 --> 15:57.028 and we see that is created. 15:57.200 --> 16:02.457 It has the image 1.16 and it's created a replica set, 16:02.571 --> 16:04.171 and it's scaled the replica set to one. 16:04.400 --> 16:05.314 Okay, so that's all good. 16:05.714 --> 16:11.257 The next step is to upgrade the deployment to version 1.17. 16:11.428 --> 16:12.714 To upgrade a deployment, 16:13.571 --> 16:15.800 we could use the kubectl set image command. 16:16.085 --> 16:18.114 Let's do a help on that. 16:20.680 --> 16:24.371 Here we see kubectl set image deployment, the deployment name, 16:24.485 --> 16:27.142 and then you have the container and the container name. 16:27.485 --> 16:28.571 Let's use this. 16:33.771 --> 16:38.342 Okay, so the image, the deployment name is nginx-deploy, 16:38.542 --> 16:40.000 nginx-deploy 16:41.514 --> 16:45.000 and there's no container called busybox, 16:46.342 --> 16:49.742 and the image name here is 1.17. 16:50.085 --> 16:53.571 Now, remember that this right here is the image, 16:54.200 --> 16:55.342 this is the container name, 16:55.485 --> 16:58.400 so we want to make sure the container name is right. 16:58.571 --> 17:06.942 Let's do a kubectl describe, deploy nginx-deploy. 17:08.200 --> 17:09.971 What is the container name? 17:10.228 --> 17:12.342 The container name is nginx, so that is right. 17:12.542 --> 17:15.742 This should be this, these need to match. 17:16.200 --> 17:18.371 Okay, so let's run the same command. 17:19.885 --> 17:24.742 The version that we want to update to is 1.17. 17:25.714 --> 17:26.428 Okay. 17:28.910 --> 17:34.485 Let's do a describe deploy again and here we see that it's now indeed 1.17. 17:35.457 --> 17:39.342 It is now scaled up, the replica set. 17:41.000 --> 17:43.685 It's created a new replica set and scaled that up. 17:44.942 --> 17:47.885 If you look at this, the strategy is already set to rolling update 17:47.971 --> 17:52.657 so there's nothing that we have to do there. 17:53.771 --> 17:54.857 That's that question. 17:55.028 --> 17:57.257 Let's go to the next one. 17:58.657 --> 18:02.200 Here, we have to create a new user called John 18:02.542 --> 18:04.057 and grant him access to the cluster. 18:04.200 --> 18:06.285 John should have permissions to create list, 18:06.400 --> 18:09.314 get update and delete pods in the development namespace 18:09.600 --> 18:11.714 and the private key exists in this location. 18:11.828 --> 18:15.885 There's the private key and the CSR are available here. 18:16.028 --> 18:21.971 You have root CKA and the files are there. 18:22.171 --> 18:24.514 Let's go there, root CKA. 18:28.342 --> 18:29.742 As of Kubernetes, 1.19, 18:29.800 --> 18:33.142 the Certificate Signing Request object expects the signer name, yes. 18:33.514 --> 18:34.942 Please refer to the documentation. 18:35.542 --> 18:38.914 The CSR has to be John Developer, 18:39.314 --> 18:44.142 and the role name is developer and the resource is pods, 18:44.285 --> 18:47.085 and the namespace should be within the development namespace. 18:47.400 --> 18:49.828 Ultimately, we want to make sure that the user John 18:49.914 --> 18:51.257 has appropriate permissions. 18:51.685 --> 18:56.857 If you look at the John CSR, you have the Certificate Signing Request. 18:58.342 --> 19:03.428 Our approach here is to first create a Certificate Signing Request 19:04.314 --> 19:05.285 on Kubernetes 19:05.571 --> 19:10.028 and get that approved so we have the user in the system. 19:10.371 --> 19:14.600 Then we create a role with these privileges, 19:14.914 --> 19:18.200 the create list, and get update and delete pods privileges 19:18.314 --> 19:19.600 for the development namespace. 19:20.342 --> 19:23.542 It has to be named as the role name is developer 19:24.000 --> 19:26.171 and then just for pods, 19:26.342 --> 19:31.657 and then we have to create a role binding to bind this role to the user John. 19:34.285 --> 19:36.171 The username is John. 19:36.657 --> 19:38.171 That's what we have to do. 19:40.057 --> 19:43.800 The first thing is to-- Let's look at role binding, 19:45.342 --> 19:50.085 or using RBAC, so just search for RBAC. 19:51.057 --> 19:55.400 Here we have the Certificate Signing Requests. 19:55.571 --> 19:56.885 Actually, it's available here. 19:56.971 --> 19:57.885 That's the first step. 19:58.342 --> 20:00.742 We could have just searched for Certificates Signing Requests. 20:03.057 --> 20:09.657 If you come down there should be a template for creating, yes, 20:09.800 --> 20:10.485 it's right here. 20:11.257 --> 20:18.628 Let's copy this and let's create a file called CSR.Yaml. 20:18.628 --> 20:22.057 Maybe John.Yaml. 20:23.000 --> 20:24.171 Let's space that. 20:25.514 --> 20:31.371 The Certificate Signing Request has to be named John developer. 20:32.114 --> 20:32.971 Copy that. 20:35.714 --> 20:38.342 The signer name is already given, so that's good. 20:38.600 --> 20:41.657 We don't need to set an expiry because it's not mentioned here. 20:43.171 --> 20:45.514 Then now we have to specify the CSR here. 20:45.628 --> 20:46.914 Let's just save this 20:47.600 --> 20:50.685 and let's get this Certificate Signing Request 20:50.771 --> 20:52.400 in the base64 format. 20:52.800 --> 20:55.628 If you look here, there are instructions here 20:55.742 --> 20:58.285 to get the base64 code of format. 20:58.571 --> 21:01.371 You could actually just use this command, 21:02.114 --> 21:06.028 so let's just use that, and here we have it. 21:06.542 --> 21:10.971 Let's copy it all the way till here, right before root. 21:12.514 --> 21:15.057 Then let's edit the file 21:18.828 --> 21:19.914 John CSR. 21:21.914 --> 21:23.771 Let's just delete this line 21:26.028 --> 21:28.971 and add a new line or request. 21:29.542 --> 21:30.828 I'm going to paste that. 21:32.171 --> 21:35.257 We have John developer is the Certificate Signing Request. 21:35.457 --> 21:36.514 The signer name is there. 21:37.400 --> 21:41.571 Usages are there, that's fine and then the request. 21:42.457 --> 21:43.285 Let's do that. 21:43.771 --> 21:50.171 Let's create Certificate Signing Request, so it's created. 21:50.771 --> 21:52.571 Then so let's check. 21:55.085 --> 21:57.228 You look at the Certificate Signing Requests. 22:01.600 --> 22:03.057 If you look at the Certificate Signing Requests, 22:03.142 --> 22:06.428 you have John developer and it's in a pending state. 22:06.657 --> 22:07.942 Let's approve that request. 22:08.057 --> 22:18.000 Let's do a kubectl certificate approve John developer. 22:19.085 --> 22:20.371 It's approved. 22:21.828 --> 22:26.285 Let's check the status now and we see that it's in a approved state. 22:26.771 --> 22:27.542 That's good. 22:27.685 --> 22:30.085 We are through with the first step. 22:30.514 --> 22:34.885 The next step is to create the role with these privileges. 22:35.114 --> 22:37.857 We're going to do kubectl create a role. 22:38.257 --> 22:40.857 Let's just take a look at help real quick. 22:41.280 --> 22:44.171 We have something like this, 22:44.280 --> 22:48.514 so we could use create role and then the verbs and the resources 22:50.542 --> 22:53.942 that we should have access to, so maybe this one. 22:56.342 --> 23:01.600 The role name is given here, so it has to be developer 23:03.628 --> 23:10.057 and then the verbs are create list, 23:10.200 --> 23:11.485 get are already there. 23:11.771 --> 23:13.085 There is no watch. 23:13.485 --> 23:15.114 We're good to remove that, 23:15.514 --> 23:18.714 so it's create list get update, and delete. 23:19.028 --> 23:23.800 Create list, get update, and delete 23:24.342 --> 23:27.400 and the resource is pods. 23:30.371 --> 23:34.600 Remember, this is also in the development namespace 23:35.657 --> 23:37.257 so the namespace is development. 23:38.514 --> 23:39.628 Let's create that. 23:39.771 --> 23:45.000 Let's get roles in the development namespace. 23:45.600 --> 23:49.971 We had the developer role, let's just do a describe role 23:53.371 --> 23:59.257 and we see that it indeed has pods and create, get list, update, and delete. 23:59.685 --> 24:03.485 The next step is to create a role binding, which will bind this role to that user. 24:03.685 --> 24:11.200 Before that, we want to just check using the kubectl auth command. 24:13.800 --> 24:17.800 The auth command will help us check if a user can do something right. 24:18.142 --> 24:23.885 We're going to do a auth can I command so can I-- 24:24.571 --> 24:27.400 We're going to do kubectl auth can I create pods 24:28.142 --> 24:35.400 as a specific user in a specific namespace. 24:36.028 --> 24:44.571 We want to see if I can get pods 24:44.880 --> 24:53.057 in the namespace development as the user. 24:53.171 --> 24:55.400 We could use as, as John. 24:56.771 --> 24:57.714 It says, no. 24:58.800 --> 25:04.800 How about create or anything else. 25:05.000 --> 25:05.771 It's no. 25:05.971 --> 25:09.314 After we create the RoleBinding, this should change to yes. 25:09.457 --> 25:10.685 That's the goal here. 25:10.857 --> 25:19.200 Let's create the role binding, let's do a kubectl, create role binding. 25:22.400 --> 25:23.171 Look at the help, 25:24.142 --> 25:26.628 so create a RoleBinding, the name of the RoleBinding, 25:26.914 --> 25:28.485 and then the role and the user. 25:28.628 --> 25:29.828 That's what we have to do. 25:37.200 --> 25:41.628 RoleBinding, we're going to call it the same as the role. 25:45.400 --> 25:48.800 This is for John so let's just call it John developer 25:49.228 --> 25:57.000 and the role is developer 25:58.114 --> 26:01.600 and the user is John. 26:06.142 --> 26:12.000 We forgot to specify the namespace so let's just delete that 26:21.285 --> 26:27.885 just delete that and let's recreate it in the development namespace. 26:29.742 --> 26:33.971 Let's do a get role binding 26:35.342 --> 26:37.857 in the development namespace. 26:38.514 --> 26:40.314 We have a John developer there, 26:40.742 --> 26:47.000 let's do a describe role bindings in the development namespace. 26:47.657 --> 26:50.800 We see that the user John has this. 26:51.828 --> 26:57.114 Let's run the auth command again, so kubectl, auth can I get pods as John? 26:57.657 --> 26:59.571 In the development namespace, it says yes. 27:00.142 --> 27:02.942 How about create? 27:04.257 --> 27:04.914 Yes. 27:05.600 --> 27:07.971 How about something that we haven't given, let's say watch? 27:09.200 --> 27:09.742 No. 27:10.228 --> 27:13.885 That proves that that's working. 27:15.000 --> 27:16.714 All right, let's go to the next one. 27:20.228 --> 27:24.600 The next question says, create nginx pod called nginx-resolver 27:24.714 --> 27:25.914 using the image nginx. 27:26.400 --> 27:29.857 Expose it internally with a service called nginx resolver service. 27:30.228 --> 27:34.028 Then test that you are able to look up the service and pod names 27:34.171 --> 27:35.285 from within the cluster 27:35.400 --> 27:38.514 and for that we can use the image busybox:1.28 27:38.600 --> 27:41.114 to create a pod for the DNS lookup. 27:41.485 --> 27:43.857 Then record the results in the nginx servers 27:43.942 --> 27:45.485 as well as nginx.pod 27:45.714 --> 27:48.800 for the service and pod name resolution respectively. 27:49.228 --> 27:54.914 The first step is to create nginx pod so we do a kubectl run, 27:55.057 --> 28:00.085 nginx-resolver and the image is nginx. 28:00.857 --> 28:04.028 Expose it internally with a service called nginx resolve 28:04.257 --> 28:06.028 so let's create this first. 28:06.857 --> 28:11.457 We have the pod which is the nginx resolver 28:13.257 --> 28:14.657 and that's running. 28:15.028 --> 28:17.657 The next step is to expose it as a service 28:17.742 --> 28:22.971 so we do a kubectl expose pod nginx resolver. 28:26.057 --> 28:30.685 The type it says expose it internally so it's just a cluster IP type 28:31.000 --> 28:32.314 so we don't have to specify that. 28:32.400 --> 28:38.628 We do have to give our service a name which is the nginx resolver service. 28:40.114 --> 28:40.971 Let's do that, 28:41.457 --> 28:47.428 require support so the nginx pod is 80 so let's specify that. 28:49.914 --> 28:56.628 Then the next task is to do nslookup 28:56.885 --> 29:00.114 using the busybox:1.28 image by creating a pod. 29:01.171 --> 29:05.257 Before that, let's just verify the service that we have created 29:05.800 --> 29:10.485 and that is nginx resolver service. 29:11.228 --> 29:13.800 We see that it does have an endpoint 29:15.142 --> 29:17.342 and it's got the service selectors as well. 29:17.714 --> 29:21.914 The next task is to run a busybox image, 29:22.000 --> 29:27.085 so a kubectl run busybox. 29:27.170 --> 29:28.400 Let's just call it busybox 29:28.657 --> 29:33.114 and the image is going to be busybox 1.28. 29:35.971 --> 29:37.914 What we can do is we can just do a sleep 29:39.085 --> 29:42.285 so it keeps running and then after we can-- 29:42.657 --> 29:46.600 Let's just put a sleep for 4,000 so it keeps running in the background. 29:46.742 --> 29:51.400 Let's do a pod and we see that we do have the busybox pod running. 29:51.714 --> 29:58.657 We can now do an exec and do exec into the busybox 29:59.314 --> 30:01.428 and then we run the nslookup command. 30:01.542 --> 30:02.742 We do nslookup. 30:03.314 --> 30:07.000 The first thing that we want to do is resolve this service. 30:07.114 --> 30:10.057 Let's just resolve the service by its name. 30:10.714 --> 30:12.171 As you can see it's resolved the service 30:12.285 --> 30:14.800 so all you have to do since the busybox image, 30:14.971 --> 30:21.000 the pod, and the next resolver are in the same namespace, 30:21.142 --> 30:25.171 all you have to do is do a lookup to the service name. 30:25.971 --> 30:27.342 This just works. 30:28.257 --> 30:31.714 We're going to redirect that output to this next service. 30:33.685 --> 30:39.628 The next step is to resolve the pod name 30:39.800 --> 30:41.800 and direct it to here. 30:42.628 --> 30:46.600 If you're not sure about the pod name resolution 30:46.742 --> 30:47.885 just search for DNS, 30:48.057 --> 30:50.428 and here you have DNS for services and pods. 30:50.885 --> 30:52.171 If you look at pods here, 30:53.000 --> 30:57.942 the pod resolution is always the pod IP address 30:58.085 --> 31:02.485 and then the service, pod, and cluster local. 31:04.000 --> 31:10.942 The IP address has to be a dash delimited so let's do that. 31:11.910 --> 31:15.114 Let's first find out the IP address of the nginx pod. 31:15.200 --> 31:18.342 Let's do a kubectl get pods-o wide. 31:18.942 --> 31:23.514 We have the nginx resolver and we have the IP. 31:25.914 --> 31:31.314 Then we're going to do an nslookup 31:38.142 --> 31:43.257 to default.cluster.local. 31:46.228 --> 31:51.971 The IP address is going to be delimited by a dash instead of a dot. 31:52.142 --> 31:53.485 It's going to change that. 31:55.000 --> 31:57.257 This is the namespace, 31:57.542 --> 31:59.971 and this is cluster.local, that's the root domain. 32:01.600 --> 32:05.028 I'm going to remove this so I can first see. 32:10.514 --> 32:12.800 That didn't go through. 32:12.914 --> 32:14.000 Let's try. 32:16.370 --> 32:17.885 You have the IP address. 32:20.570 --> 32:27.742 It says it ended with exit code one.default.cluster.local. 32:30.942 --> 32:34.742 It's default. pod.cluster.local. I missed that. 32:36.714 --> 32:38.657 Pod.cluster.local. 32:39.400 --> 32:43.428 That seems to be resolving fine so let's move that to this file. 32:46.285 --> 32:48.171 That should be all for this. 32:48.342 --> 32:49.514 Let's go to the next one. 32:49.771 --> 32:50.742 The final question. 32:52.885 --> 32:56.400 This one is about creating a static pod on Node01 32:56.542 --> 32:58.600 called nginx critical with the image nginx 32:58.857 --> 33:01.942 and making sure that it's recreated, restarted automatically 33:02.028 --> 33:03.314 in case of a failure. 33:04.857 --> 33:08.000 There's also the path to the static pod given here. 33:08.171 --> 33:10.771 This needs to be done on Node01. 33:10.857 --> 33:12.457 That's important to note. 33:12.600 --> 33:14.342 We're going to SSH to Node01. 33:14.457 --> 33:19.285 If you don't know how to find Node01, let's do a get nodes-o wide. 33:20.114 --> 33:21.857 We can get the IP address here. 33:23.285 --> 33:26.228 That's SSH to this node. 33:33.514 --> 33:39.885 The static pods, as we know are in etc Kubernetes manifests. 33:40.028 --> 33:41.657 There's a directory there, 33:41.742 --> 33:43.542 but there are no static pods at the moment. 33:43.940 --> 33:47.657 All we need to do is create a pod definition file 33:47.742 --> 33:48.400 and put it there. 33:49.428 --> 33:51.942 Let's see if we have kubectl utility here. 33:52.057 --> 33:52.628 Yes, there is. 33:53.685 --> 33:58.200 Let's do kubectl run, 34:00.828 --> 34:04.942 the pod name is nginx-critical, and the image is nginx. 34:05.628 --> 34:08.600 Make sure that it's created restarted automatically. 34:09.171 --> 34:10.142 There is a restart. 34:10.600 --> 34:12.628 We are just referring to the restart policy. 34:13.257 --> 34:19.314 Let's just check about the restart policy option. 34:19.457 --> 34:20.657 We have the research policy. 34:20.971 --> 34:22.314 By default, it's said to always. 34:23.085 --> 34:26.085 There's really no reason of specifying that. 34:29.942 --> 34:32.571 We're going to create a pod definition file. 34:33.914 --> 34:35.285 For that, let's just go to the masters. 34:35.371 --> 34:37.742 I'm going to open a new terminal to the master. 34:38.057 --> 34:40.857 What we want to do is we want to create a pod definition file. 34:40.971 --> 34:49.085 We're going to do a kubectl run nginx-critical. 34:49.171 --> 34:54.342 That's the name of the pod, with the image nginx. 34:56.742 --> 34:59.171 If you want, we can specify the restart policy to always, 34:59.314 --> 35:05.057 but by default it's set to always so doesn't really matter. 35:06.600 --> 35:12.228 Then we're going to do a dry-run=client -o yaml. 35:12.600 --> 35:13.828 This is the file. 35:14.371 --> 35:15.457 I'm going to copy this. 35:16.628 --> 35:23.220 What we'll do is we'll create a file at etc/kubernetes/manifests in node01. 35:24.114 --> 35:28.514 We'll call it nginx-critical.yaml. 35:29.085 --> 35:31.028 Same name as the pod. 35:33.457 --> 35:35.542 We know that as soon as we create this file, 35:35.657 --> 35:38.171 if we do a kubectl get pods, 35:39.142 --> 35:42.314 we'll see that its already created the static pod 35:42.457 --> 35:44.200 with the node name at the end. 35:46.428 --> 35:52.971 If you look at describe pod nginx critical, 35:53.057 --> 35:54.885 we see that it gives us the nginx image. 35:59.400 --> 36:00.514 That should be it. 36:01.971 --> 36:06.057 That's the end of this mock exam. 36:06.171 --> 36:07.200 Let's check our work. 36:07.314 --> 36:08.742 Waiting the end exam button. 36:12.114 --> 36:19.942 We have 10%, 20%, 40%, 55%, 70%, 36:24.910 --> 36:26.857 85%, and 100%. 36:27.428 --> 36:32.171 That's the end of that mock exam.