1 00:00:00,001 --> 00:00:06,901 [No Audio] 2 00:00:06,901 --> 00:00:09,501 Now let's start our single node Minikube 3 00:00:09,501 --> 00:00:12,901 Kubernetes cluster using minikube, start command 4 00:00:13,167 --> 00:00:16,466 and provide its virtualization driver, or VM 5 00:00:16,466 --> 00:00:21,434 driver as virtual box. If you remember, we have 6 00:00:21,434 --> 00:00:24,134 installed virtualbox while setting up Docker Swarm 7 00:00:24,134 --> 00:00:28,701 as well. So, our machine already has VMware set up, 8 00:00:28,701 --> 00:00:31,601 but in case you have removed it, you can go 9 00:00:31,601 --> 00:00:34,301 back to the Docker Swarm setup lecture, and check 10 00:00:34,301 --> 00:00:37,434 out the installation instructions for virtualbox. 11 00:00:38,834 --> 00:00:41,834 Let's hit enter. If you take a closer look at the 12 00:00:41,834 --> 00:00:44,867 processes, they're pretty much similar to how we 13 00:00:44,867 --> 00:00:48,167 bootstrap our regular Kubernetes cluster. It is 14 00:00:48,167 --> 00:00:52,167 getting IP addresses of VMs, it is moving file to 15 00:00:52,167 --> 00:00:55,434 an isolated virtual machine, it is setting up 16 00:00:55,434 --> 00:00:58,067 certificates, it is connecting our shell to 17 00:00:58,067 --> 00:01:01,401 cluster and it is also setting up kube-config 18 00:01:01,534 --> 00:01:04,467 which is used to set up Kubernetes configurations. 19 00:01:05,434 --> 00:01:08,467 Looks like the processes are done. Let's try and 20 00:01:08,467 --> 00:01:12,401 run a deployment. Without being too quirky. Let's 21 00:01:12,401 --> 00:01:16,101 simply run our vanilla nginx-server and expose it's 22 00:01:16,101 --> 00:01:19,334 port 80. As a NodePort service. We are using 23 00:01:19,334 --> 00:01:23,234 latest nginx image. So let's hit enter, we get our 24 00:01:23,234 --> 00:01:26,434 standard warning of kubectl run might get 25 00:01:26,434 --> 00:01:29,167 deprecated in future, but our deployment is 26 00:01:29,167 --> 00:01:33,401 created. When we run kubectl get pods, it looks 27 00:01:33,401 --> 00:01:36,134 like a single pod deployment has been created 28 00:01:36,134 --> 00:01:39,534 and our container is still under creation status. 29 00:01:40,034 --> 00:01:42,901 While it is being created, let's describe the pod 30 00:01:42,901 --> 00:01:46,901 using kubectl describe. And the description looks 31 00:01:46,901 --> 00:01:48,867 pretty similar to all the previous pods that we 32 00:01:48,867 --> 00:01:51,201 have created. Which means that whether you are 33 00:01:51,201 --> 00:01:53,901 running a standard bootstrap Kubernetes cluster on 34 00:01:53,901 --> 00:01:56,901 your premise, or you are running Kubernetes on 35 00:01:56,934 --> 00:02:00,534 cloud, or you're running Minikube, kubectl 36 00:02:00,534 --> 00:02:03,267 command line and its performance remains the same. 37 00:02:03,267 --> 00:02:04,967 And while we were taking a look at the 38 00:02:04,967 --> 00:02:07,701 description, it looks like our container has been 39 00:02:07,701 --> 00:02:12,533 created and started, which is good. Let's run kubectl get pods again. 40 00:02:12,533 --> 00:02:14,767 And there we go, our nginx pod 41 00:02:14,767 --> 00:02:18,267 is up and running. Same goes for our deployment 42 00:02:18,267 --> 00:02:21,101 and there is a gap of 6 seconds between the 43 00:02:21,101 --> 00:02:23,434 deployment being created and the pod being 44 00:02:23,434 --> 00:02:26,567 created, which is just fine. While we are added we 45 00:02:26,567 --> 00:02:29,801 can also take a look at the deployments description. 46 00:02:30,334 --> 00:02:32,501 Starting from labels, everything is 47 00:02:32,501 --> 00:02:35,167 similar to a regular Kubernetes cluster, including 48 00:02:35,167 --> 00:02:38,867 RollingUpdateStrategy and Events. Now let's 49 00:02:38,867 --> 00:02:42,434 expose our deployment nginx-server with service 50 00:02:42,434 --> 00:02:45,934 type NodePort and our service is exposed. 51 00:02:45,934 --> 00:02:49,334 Since we have used NodePort service, we need to know 52 00:02:49,334 --> 00:02:52,167 which of our public ports has been mapped to 53 00:02:52,167 --> 00:02:56,901 containers port 80. Let's run kubectl get svc or 54 00:02:56,901 --> 00:03:00,334 services. It seems like containers port 80 is 55 00:03:00,334 --> 00:03:04,201 mapped to host machines public port 30229. 56 00:03:04,201 --> 00:03:07,534 Fair enough, which means that a combination of host 57 00:03:07,534 --> 00:03:11,667 machines IP and the public port exposed should 58 00:03:11,667 --> 00:03:15,801 give us nginx welcome page. But mind well, here, 59 00:03:15,801 --> 00:03:19,434 host machine doesn't mean this machine, it means 60 00:03:19,434 --> 00:03:22,734 the VM on which Minikube is running. And to get 61 00:03:22,734 --> 00:03:27,267 its IP, let's run minikube ip, our IP is 62 00:03:27,267 --> 00:03:34,101 192.168.99.100. Let's use it, open your 63 00:03:34,101 --> 00:03:37,701 favorite web browser and enter the IP port 64 00:03:37,701 --> 00:03:41,501 combination. There we go, the VM running Minikube 65 00:03:41,501 --> 00:03:46,101 is hosting nginx on its 30229 port, great. 66 00:03:46,101 --> 00:03:49,067 Now let's go further and take a look at Kubernetes 67 00:03:49,067 --> 00:03:53,001 dashboard using minikube dashboard command. 68 00:03:53,001 --> 00:03:56,134 And our dashboard is opening on our web browser on 69 00:03:56,134 --> 00:04:01,134 localhost port 37339. Here we are, this is 70 00:04:01,134 --> 00:04:05,067 Kubernetes dashboard or Kubernetes GUI. It looks 71 00:04:05,067 --> 00:04:08,867 simple, intuitive and pleasant to work with. 72 00:04:08,867 --> 00:04:12,334 Starting from top left, we have Kubernetes logo, 73 00:04:12,567 --> 00:04:16,233 it is joined by a search bar which can be used to 74 00:04:16,233 --> 00:04:20,534 filter out objects like deployments, pods, etc. 75 00:04:20,666 --> 00:04:24,166 And on top right, we have CREATE button which is 76 00:04:24,166 --> 00:04:27,233 used to create Kubernetes objects, but we will get 77 00:04:27,233 --> 00:04:30,867 into that later. Take a look at Workloads. We have 78 00:04:30,867 --> 00:04:34,534 Deployments, Pods and Replica Sets running and it 79 00:04:34,534 --> 00:04:37,967 seems like all of them are up and running perfectly. 80 00:04:38,201 --> 00:04:40,767 Here the 100% means that all of the 81 00:04:40,767 --> 00:04:43,767 Deployments, all of the Pods and all of the 82 00:04:43,767 --> 00:04:46,834 Replica Sets are in that desired state. 83 00:04:47,001 --> 00:04:50,967 Below that, we have details for all of those starting 84 00:04:50,967 --> 00:04:54,534 with deployment. The details presented here are 85 00:04:54,534 --> 00:04:58,834 pretty similar to the output of kubectl get command, 86 00:04:58,834 --> 00:05:02,001 but here we have GUI representation of all. 87 00:05:02,001 --> 00:05:05,401 And instead of having a column of state 88 00:05:05,401 --> 00:05:08,834 running, we have a green tick mark, which 89 00:05:08,834 --> 00:05:12,101 indicates its running state. And what differs from 90 00:05:12,101 --> 00:05:16,101 the output of kubectl get, is that we also get a 91 00:05:16,101 --> 00:05:19,701 list of labels which are attached to these 92 00:05:19,701 --> 00:05:23,067 represented Kubernetes objects. Below workload 93 00:05:23,067 --> 00:05:26,534 section, we have discovery and load balancing, 94 00:05:26,534 --> 00:05:29,967 which essentially lists out all of the services, 95 00:05:29,967 --> 00:05:33,801 we have two services running, among which first is 96 00:05:33,801 --> 00:05:36,834 nginx-server, which is NodePort service, which we 97 00:05:36,834 --> 00:05:39,801 have just created a few minutes ago. We have all 98 00:05:39,801 --> 00:05:43,734 sorts of details like Internal endpoints, Cluster IP 99 00:05:43,734 --> 00:05:46,634 of the service, External endpoints, which are 100 00:05:46,634 --> 00:05:51,501 not available right now, Age of the service and Labels. 101 00:05:51,701 --> 00:05:54,401 And below we have Kubernetes, which is the 102 00:05:54,401 --> 00:05:57,967 default service. And at last, we have 103 00:05:57,967 --> 00:06:01,834 Configuration and Storage objects. Since we didn't 104 00:06:01,867 --> 00:06:05,034 provision any volume, or we didn't use any volume 105 00:06:05,034 --> 00:06:09,001 mounts, we just have one projected volume, which 106 00:06:09,001 --> 00:06:12,534 is default-token, which has been created while 107 00:06:12,534 --> 00:06:14,834 setting up the Minikube cluster. 108 00:06:15,201 --> 00:06:19,334 On the left pane, starting from the top, we have various 109 00:06:19,334 --> 00:06:23,067 constructs of the cluster such as Namespaces, 110 00:06:23,067 --> 00:06:29,034 Nodes, Persistent Volumes, Roles, Storage Classes, etc. 111 00:06:29,034 --> 00:06:31,801 Then, we have options to navigate to 112 00:06:31,801 --> 00:06:34,734 particular workloads, particular services, or 113 00:06:34,734 --> 00:06:38,501 Ingresses, or particular storage objects. And at the 114 00:06:38,501 --> 00:06:43,834 end, we have About and Setting s tabs. Let's start 115 00:06:43,834 --> 00:06:46,867 with Namespaces, just like a regular Kubernetes 116 00:06:46,867 --> 00:06:50,034 cluster, this Ninikube cluster also has three 117 00:06:50,034 --> 00:06:54,601 namespaces, which are kube-public kube-system and default. 118 00:06:54,601 --> 00:06:56,901 Since we did not create any user-defined 119 00:06:56,901 --> 00:07:01,267 namespace, these three are up and running since the cluster started. 120 00:07:01,867 --> 00:07:03,767 Then we have Nodes information, 121 00:07:04,367 --> 00:07:06,967 you might be wondering, if Minikube 122 00:07:06,967 --> 00:07:10,634 is just a single node Kubernetes cluster, why do 123 00:07:10,634 --> 00:07:13,567 we have node information in the first place? 124 00:07:13,734 --> 00:07:18,101 Well, Minikube and Kubernetes dashboard are different 125 00:07:18,101 --> 00:07:22,301 entities. Minikube dashboard command just enables 126 00:07:22,301 --> 00:07:25,467 us to use Kubernetes dashboard, which shows the 127 00:07:25,467 --> 00:07:28,167 current state of this single node cluster. 128 00:07:28,401 --> 00:07:33,767 But the same dashboard can be used with a bootstrap kubeadm 129 00:07:33,767 --> 00:07:36,867 cluster as well. In which case, you will have 130 00:07:36,867 --> 00:07:40,267 more than one nodes. Just like other workloads, 131 00:07:40,267 --> 00:07:44,301 the Node card also has details such as Labels, 132 00:07:44,301 --> 00:07:48,167 State, Resource requests and Resource limits. 133 00:07:48,867 --> 00:07:52,701 You can navigate to other tabs like Persistent Voliumes, 134 00:07:52,701 --> 00:07:55,934 Roles, Storage Classes, etc, as well. 135 00:07:55,934 --> 00:07:58,634 But we will jump straight to something which looks 136 00:07:58,634 --> 00:08:02,601 like a drop down menu, and it says Namespaces. 137 00:08:02,601 --> 00:08:06,534 It is a drop down menu and it is used to switch from 138 00:08:06,534 --> 00:08:10,101 one namespace to another. Currently, we are in 139 00:08:10,101 --> 00:08:13,601 default namespace. But if we switch our namespace, 140 00:08:13,623 --> 00:08:16,401 the available objects will also change. 141 00:08:16,401 --> 00:08:19,801 We can navigate to different workloads as well. Let's go 142 00:08:19,801 --> 00:08:22,767 to Deployments and we get the same output which 143 00:08:22,767 --> 00:08:26,267 we got on the homepage. But this time, this output 144 00:08:26,267 --> 00:08:29,301 is not accompanied by ReplicaSets and Pods. 145 00:08:29,301 --> 00:08:32,067 Let's click on the name of deployment to see what 146 00:08:32,067 --> 00:08:36,333 happens. Well, well, this does look pretty similar. 147 00:08:36,333 --> 00:08:39,433 In fact, this is a looks like the result 148 00:08:39,433 --> 00:08:42,900 of kubectl describe command when we describe a 149 00:08:42,900 --> 00:08:46,534 Deployment. We have all sorts of information like 150 00:08:46,900 --> 00:08:52,167 Name, Namespaces, Label, Annotation, Creation Time, etc. 151 00:08:52,234 --> 00:08:54,933 Then, we held a ReplicaSet which is 152 00:08:54,933 --> 00:08:58,234 governed by this deployment. And at the end, we 153 00:08:58,234 --> 00:09:01,467 have events just like the output of a describe command. 154 00:09:01,467 --> 00:09:03,601 Since we haven't initialized any 155 00:09:03,601 --> 00:09:07,634 Horizontal Pod Autoscalers, that field is empty. 156 00:09:07,967 --> 00:09:12,567 Similarly, when we go to Pods tab, all we get are pods. 157 00:09:12,734 --> 00:09:15,067 Clicking on the pod name will also give the 158 00:09:15,067 --> 00:09:17,801 output of kubectl described pod command. 159 00:09:17,801 --> 00:09:21,134 But let's not be repetitive. Let's see what are these 160 00:09:21,134 --> 00:09:25,834 four lines. It says Action and Logs. 161 00:09:25,834 --> 00:09:30,367 Let's click on them. And there we go, those four lines show 162 00:09:30,367 --> 00:09:34,934 the logs of our nginx-server pod ending with gnrdg. 163 00:09:34,934 --> 00:09:38,234 We can download the logs, we can change the 164 00:09:38,234 --> 00:09:42,201 size of text, text color, etc. 165 00:09:42,767 --> 00:09:47,534 And under the Action tab, we have two options to either just 166 00:09:47,534 --> 00:09:50,367 view or edit the YAML file or to delete the 167 00:09:50,367 --> 00:09:53,434 deployment altogether. Let's go back to the 168 00:09:53,434 --> 00:09:57,001 overview or homepage. Let's head back to our 169 00:09:57,001 --> 00:10:01,201 terminal and stop this cluster using minikube stop command. 170 00:10:01,201 --> 00:10:03,301 It is important to stop your cluster 171 00:10:03,301 --> 00:10:05,801 when you are not using it or your system might go 172 00:10:05,801 --> 00:10:08,701 into OOM or Out Of Memory state. 173 00:10:10,167 --> 00:10:14,101 And finally, let's delete the cluster using minikube delete. 174 00:10:15,501 --> 00:10:19,634 And the cluster is deleted. Simple commands, simple life.