Similarly you check it\’s status:
To create a new kubecluster, we run (note this can take several minutes):
$ minikube start
If you open up the virtualbox gui, you should see a new vm called minikube running. If you check the status again, you should now see:
$ minikube status
Here it says that minikube has also configured kubectl, that\’s done by making changes to kubectl\’s config file. By default that file is located at ~/.kube/config. We\’ll cover more about this file later in the course. But for now we\’ll confirm that this config file is currently configured to point to minikube\’s kube cluster:
The ip address shown here is the Minikube VM\’s ip address, which should match:
To check the health of your kub cluster\’s control plane, you can run:
Also to see how many nodes are in our kubecluster, run:
This command lists out all VMs that has the kubelet component running on it, along with the kubelet\’s VERSION. If you built kubernetes the hardway then the masters won\’t get listed here, since the masters don\’t have the kubelet running on them. We can specify the \’wide\’ output setting to display a little some more info:
Now that we have a kubecluster in place, we can now run the kubectl version command but this time without the –client filter flag:
By design, to stay lightweight, our minikube based kubecluster is a single node cluster, which acts as both the master and worker node. That\’s fine in a development environment. But in production, you should have multiple node cluster for High Availability, better performance, more CPU+RAM capacity,..etc.
This is a really cool tool that let\’s you view and manage your Kubecluster visually. I encourage you to explore this tool as we progress through the course.