Now that we have familiarized ourselves with the default minikube start command, let's dive deeper into Minikube to understand some of its more advanced features.
The minikube start by default selects a driver isolation software, such as a hypervisor or a container runtime, if one (VitualBox) or multiple are installed on the host workstation. In addition it downloads the latest Kubernetes version components. With the selected driver software it provisions a single VM named minikube (with hardware profile of CPUs=2, Memory=6GB, Disk=20GB) or container (Docker) to host the default single-node all-in-one Kubernetes cluster. Once the node is provisioned, it bootstraps the Kubernetes control plane (with the default kubeadm tool), and it installs the latest version of the default container runtime, Docker, that will serve as a running environment for the containerized applications we will deploy to the Kubernetes cluster.
The minikube start command generates a default minikube cluster with the specifications described above and it will store these specs so that we can restart the default cluster whenever desired. The object that stores the specifications of our cluster is called a profile.
As Minikube matures, so do its features and capabilities. With the introduction of profiles, Minikube allows users to create custom reusable clusters that can all be managed from a single command line client.
The minikube profile command allows us to view the status of all our clusters in a table formatted output.
Now, we'll start the minikube indicating the driver, which is Docker in this case.
Wait for it to finish! You'll see a message like "Done! kubectl is now configured." Once you see that, then you can try another Kubernetes command.
Now, we'll run the minikube status. Once Minikube is "Running," you have a tiny one-node Kubernetes cluster alive on your machine.
If you see a node named minikube with a status of Ready, you officially have a Kubernetes cluster running on your laptop! We'll check by running the kubectl get nodes command:
minikube stop: With the this command, we can stop Minikube. This command stops all applications running in Minikube, safely stops the cluster and the VM, preserving our work until we decide to start the Minikube cluster once again, while preserving the Minikube VM.
minikube status
Assuming we have created only the default minikube cluster, we could list the properties that define the default profile with:
This table presents the columns associated with the default properties such as the profile name: minikube, the isolation driver: VirtualBox, the container runtime: Docker, the Kubernetes version: v1.28.3, the status of the cluster - running or stopped. The table also displays the number of nodes: 1 by default, the private IP address of the minikube cluster's control plane VirtualBox VM, and the secure port that exposes the API Server to cluster control plane components, agents and clients: 8443.
To create a brand-new cluster with 2 nodes named lab-cluster, you use the --nodes flag. However, since you already have a single-node cluster stopped (as seen in your screenshot), we need to start it back up with the multi-node configuration. We'll run the multi-node command.
Once the cluster starts, we'll use the next three commands to see the difference: kubectlgetnodes
minikube profile list: Using this command, you can check the Minikube Profiles and see both the original cluster and the new 2-node cluster side-by-side.
The minikube profile list command shows the two separate slots you have created on your machine:
lab-cluster: This is the active cluster. It is running on the docker driver with 2 nodes and currently has a status of OK. The asterisk (*) in the ACTIVE_PROFILE column indicates that any kubectl commands ran right now will target this cluster.
minikube: This is the original single-node cluster. It is currently Stopped, meaning it isn't consuming any RAM or CPU, but its configuration and any data it had is are safely saved.
kubectl get nodes -o wide: This gives a detailed View: you can see which node is the Control Plane (the brain) and which is the Worker (the muscle).
This command shows the details of the nodes inside your active lab-cluster profile:
lab-cluster(control-plane): This is the brain of your cluster. It manages the state, schedules applications, and handles the API.
lab-cluster-m02: This is your second node. In a multi-node setup, this acts as a Worker node where your actual application containers (Pods) will run.
Ready Status: Both nodes are Ready, meaning they are healthy and communicating with each other.
And the -o wide flag gives you deeper technical insights:
Internal-IP: Your nodes have unique internal addresses (192.168.58.2 and 192.168.58.3) to talk to each other.
OS-Image: They are running Debian GNU/Linux 12 inside their Docker containers.
Container-Runtime: They are using Docker v1.35.1 to actually spin up the containers.
The role of the second cluster is labeled as none because it wasn't specified during creation.
Now we'll stop the lab-cluster and start the minikube.
This is known as Switching Contexts and should be mastered.
If you want to go back to your first cluster, you don't need to delete anything. You just switch the Active pointer:
Stop current: minikube stop -p lab-cluster
Switch & Start: minikube start -p minikube
Advanced Minikube features
minikube profile list
In order to set the profile to lab-cluster, we' ll use the command: profile lab-cluster
Then start the minikube again using minikube start
When it is time to run the cluster again, simply run the minikube start command (driver option is not required), and it will restart the earlier bootstrapped Minikube cluster.
Now I want the terminal to look organized and show worker, I can manually assign the role using the label command. Run this in your VS Code terminal:
then change context to lab-cluster(to make the target cluster lab-cluster) and then run get nodes command.
is now worker!
Run minikube profile list command, the profile will now be set to the lab-cluster.
Run kubectl config view, it gives a detailed information about the cluster and its nodes.
The kubeconfig includes the API Server's endpoint server: https://127.0.0.1:49687 and the minikube user's client authentication key and certificate data.
With the kubectl is installed, we can display information about the Minikube Kubernetes cluster with the kubectl cluster-info command:
Run the cluster info command, this gives information about the IP address the cluster is running at.
Kubernetes master is running at https://127.0.0.1:49687
KubeDNS is running at https://127.0.0.1:49687/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
The Kubernetes Dashboard
The Kubernetes Dashboard provides a web-based user interface for Kubernetes cluster management. Minikube installs the Dashboard as an addon, but it is disabled by default. Prior to using the Dashboard we are required to enable the Dashboard addon, together with the metrics-server addon, a helper addon designed to collect usage metrics from the Kubernetes cluster. To access the dashboard from Minikube, we can use the minikube dashboard command, which opens a new tab in our web browser displaying the Kubernetes Dashboard, but only after we list, enable required addons, and verify their state:
$ minikube addons list
$ minikube addons enable metrics-server
$ minikube addons enable dashboard
$ minikube addons list
$ minikube dashboard
Run minikube addons list
In order to enable metrics-server addon, run minikube addons enable metrics-server
Verify that the metrics-server is now enabled.
Run minikube addons enable dashboard
Verify that dashboard enabled.
Run the minikube dashboard command, and a url is displayed which opens a new window when clicked.
Or you can simply run minikube dashboard --url
The dashboard is empty as expected.
So we'll create one pod using this command: kubectl run my-first-pod --image=nginx
Verify it's now displayed on the dashboard
Run the logs command for my-first-pod
log can also be performed on the dashboard.
APIs with kubectl proxy
Issuing the kubectl proxy command, kubectl authenticates with the API server on the control plane node and makes services available on the default proxy port 8001.
First, we issue the kubectl proxy command:
$ kubectl proxy
Starting to serve on 127.0.0.1:8001
It locks the terminal for as long as the proxy is running, unless we run it in the background (with kubectl proxy &).
When kubectl proxy is running, we can send requests to the API over the localhost on the default proxy port 8001 (from another terminal, since the proxy locks the first terminal when running in foreground):
$ curl http://localhost:8001/
But it worked on the browser:
So we'll use another terminal because the proxy is now locked in the first terminal.
This works!
I stopped the clusters from dashboard and verified using the command:
Conclusion
Mastering Minikube is about more than just starting a cluster, it’s about creating a reliable, reproducible environment that mirrors the complexities of the cloud. By moving beyond default settings and embracing multi-node profiles, you transition from a student of Kubernetes to an engineer capable of architecting resilient systems.
As you continue building, remember that a well-organized local environment is the foundation of a successful deployment pipeline. Whether you are assigning worker roles in the CLI or monitoring pod health on the dashboard, these skills ensure that your infrastructure is as robust as the code running on it.
Happy Kube-ing! Post by rahimah_dev
