[No Audio]
Now let's start our single node Minikube
Kubernetes cluster using minikube, start command
and provide its virtualization driver, or VM
driver as virtual box. If you remember, we have
installed virtualbox while setting up Docker Swarm
as well. So, our machine already has VMware set up,
but in case you have removed it, you can go
back to the Docker Swarm setup lecture, and check
out the installation instructions for virtualbox.
Let's hit enter. If you take a closer look at the
processes, they're pretty much similar to how we
bootstrap our regular Kubernetes cluster. It is
getting IP addresses of VMs, it is moving file to
an isolated virtual machine, it is setting up
certificates, it is connecting our shell to
cluster and it is also setting up kube-config
which is used to set up Kubernetes configurations.
Looks like the processes are done. Let's try and
run a deployment. Without being too quirky. Let's
simply run our vanilla nginx-server and expose it's
port 80. As a NodePort service. We are using
latest nginx image. So let's hit enter, we get our
standard warning of kubectl run might get
deprecated in future, but our deployment is
created. When we run kubectl get pods, it looks
like a single pod deployment has been created
and our container is still under creation status.
While it is being created, let's describe the pod
using kubectl describe. And the description looks
pretty similar to all the previous pods that we
have created. Which means that whether you are
running a standard bootstrap Kubernetes cluster on
your premise, or you are running Kubernetes on
cloud, or you're running Minikube, kubectl
command line and its performance remains the same.
And while we were taking a look at the
description, it looks like our container has been
created and started, which is good. Let's run kubectl get pods again.
And there we go, our nginx pod
is up and running. Same goes for our deployment
and there is a gap of 6 seconds between the
deployment being created and the pod being
created, which is just fine. While we are added we
can also take a look at the deployments description.
Starting from labels, everything is
similar to a regular Kubernetes cluster, including
RollingUpdateStrategy and Events. Now let's
expose our deployment nginx-server with service
type NodePort and our service is exposed.
Since we have used NodePort service, we need to know
which of our public ports has been mapped to
containers port 80. Let's run kubectl get svc or
services. It seems like containers port 80 is
mapped to host machines public port 30229.
Fair enough, which means that a combination of host
machines IP and the public port exposed should
give us nginx welcome page. But mind well, here,
host machine doesn't mean this machine, it means
the VM on which Minikube is running. And to get
its IP, let's run minikube ip, our IP is
192.168.99.100. Let's use it, open your
favorite web browser and enter the IP port
combination. There we go, the VM running Minikube
is hosting nginx on its 30229 port, great.
Now let's go further and take a look at Kubernetes
dashboard using minikube dashboard command.
And our dashboard is opening on our web browser on
localhost port 37339. Here we are, this is
Kubernetes dashboard or Kubernetes GUI. It looks
simple, intuitive and pleasant to work with.
Starting from top left, we have Kubernetes logo,
it is joined by a search bar which can be used to
filter out objects like deployments, pods, etc.
And on top right, we have CREATE button which is
used to create Kubernetes objects, but we will get
into that later. Take a look at Workloads. We have
Deployments, Pods and Replica Sets running and it
seems like all of them are up and running perfectly.
Here the 100% means that all of the
Deployments, all of the Pods and all of the
Replica Sets are in that desired state.
Below that, we have details for all of those starting
with deployment. The details presented here are
pretty similar to the output of kubectl get command,
but here we have GUI representation of all.
And instead of having a column of state
running, we have a green tick mark, which
indicates its running state. And what differs from
the output of kubectl get, is that we also get a
list of labels which are attached to these
represented Kubernetes objects. Below workload
section, we have discovery and load balancing,
which essentially lists out all of the services,
we have two services running, among which first is
nginx-server, which is NodePort service, which we
have just created a few minutes ago. We have all
sorts of details like Internal endpoints, Cluster IP
of the service, External endpoints, which are
not available right now, Age of the service and Labels.
And below we have Kubernetes, which is the
default service. And at last, we have
Configuration and Storage objects. Since we didn't
provision any volume, or we didn't use any volume
mounts, we just have one projected volume, which
is default-token, which has been created while
setting up the Minikube cluster.
On the left pane, starting from the top, we have various
constructs of the cluster such as Namespaces,
Nodes, Persistent Volumes, Roles, Storage Classes, etc.
Then, we have options to navigate to
particular workloads, particular services, or
Ingresses, or particular storage objects. And at the
end, we have About and Setting s tabs. Let's start
with Namespaces, just like a regular Kubernetes
cluster, this Ninikube cluster also has three
namespaces, which are kube-public kube-system and default.
Since we did not create any user-defined
namespace, these three are up and running since the cluster started.
Then we have Nodes information,
you might be wondering, if Minikube
is just a single node Kubernetes cluster, why do
we have node information in the first place?
Well, Minikube and Kubernetes dashboard are different
entities. Minikube dashboard command just enables
us to use Kubernetes dashboard, which shows the
current state of this single node cluster.
But the same dashboard can be used with a bootstrap kubeadm
cluster as well. In which case, you will have
more than one nodes. Just like other workloads,
the Node card also has details such as Labels,
State, Resource requests and Resource limits.
You can navigate to other tabs like Persistent Voliumes,
Roles, Storage Classes, etc, as well.
But we will jump straight to something which looks
like a drop down menu, and it says Namespaces.
It is a drop down menu and it is used to switch from
one namespace to another. Currently, we are in
default namespace. But if we switch our namespace,
the available objects will also change.
We can navigate to different workloads as well. Let's go
to Deployments and we get the same output which
we got on the homepage. But this time, this output
is not accompanied by ReplicaSets and Pods.
Let's click on the name of deployment to see what
happens. Well, well, this does look pretty similar.
In fact, this is a looks like the result
of kubectl describe command when we describe a
Deployment. We have all sorts of information like
Name, Namespaces, Label, Annotation, Creation Time, etc.
Then, we held a ReplicaSet which is
governed by this deployment. And at the end, we
have events just like the output of a describe command.
Since we haven't initialized any
Horizontal Pod Autoscalers, that field is empty.
Similarly, when we go to Pods tab, all we get are pods.
Clicking on the pod name will also give the
output of kubectl described pod command.
But let's not be repetitive. Let's see what are these
four lines. It says Action and Logs.
Let's click on them. And there we go, those four lines show
the logs of our nginx-server pod ending with gnrdg.
We can download the logs, we can change the
size of text, text color, etc.
And under the Action tab, we have two options to either just
view or edit the YAML file or to delete the
deployment altogether. Let's go back to the
overview or homepage. Let's head back to our
terminal and stop this cluster using minikube stop command.
It is important to stop your cluster
when you are not using it or your system might go
into OOM or Out Of Memory state.
And finally, let's delete the cluster using minikube delete.
And the cluster is deleted. Simple commands, simple life.