Minikube profiles let you run multiple isolated Kubernetes clusters on your local machine, each with its own set of configurations and resources.
Let’s see it in action. Imagine you’re working on two different projects, "project-a" and "project-b," and you need separate Kubernetes environments for testing.
First, create a profile for "project-a":
minikube start --profile project-a
This command spins up a new Minikube cluster specifically for "project-a." You’ll see output indicating the cluster is starting, downloading images, and configuring Kubernetes components.
Now, create a second profile for "project-b":
minikube start --profile project-b
Minikube will create another entirely separate cluster. You can switch between these clusters using the minikube profile command.
To switch to the "project-a" cluster:
minikube profile project-a
And to switch to "project-b":
minikube profile project-b
When you run kubectl commands after switching profiles, they will operate on the active Minikube cluster. For example, kubectl get pods will show pods running in the currently selected Minikube environment.
You can list all your Minikube profiles with:
minikube profiles
This will show you project-a and project-b (and potentially default if you’ve used Minikube without specifying a profile before).
Each profile can have its own specific configurations. For instance, you might want to allocate more CPU and memory to one cluster than another. When starting a new profile, you can specify these resources:
minikube start --profile heavy-workload --cpus 4 --memory 8192
This creates a cluster named heavy-workload with 4 CPUs and 8192 MB of RAM, independent of any other profiles.
To see the configuration of a specific profile, you can inspect its associated Minikube settings. Minikube stores these configurations in your user’s home directory, typically under .minikube/profiles/<profile_name>/. Inside this directory, you’ll find files like config.json which holds the runtime parameters for that specific cluster.
When you delete a profile, you’re not just removing a Kubernetes cluster; you’re also discarding all the deployed applications, configurations, and persistent volumes associated with that specific Minikube instance. This is a crucial distinction: profiles offer complete isolation.
minikube delete --profile project-a
This command will remove the "project-a" cluster and all its associated data without affecting "project-b."
The underlying mechanism for this isolation relies on Minikube’s ability to manage multiple virtual machine or container instances. When you create a profile, Minikube essentially provisions a new, distinct instance (e.g., a VirtualBox VM, a Docker container) and installs a Kubernetes control plane and worker nodes within it. Network configurations, storage volumes, and API server endpoints are all unique to each profile’s instance, ensuring that operations on one cluster do not interfere with another. This allows for scenarios like testing different Kubernetes versions or addon configurations simultaneously.
The most surprising aspect for many is how seamlessly kubectl integrates with this. Once you minikube profile <name>, your kubectl context is automatically updated to point to that specific Minikube cluster’s API server. You don’t need to manually edit kubeconfig files or switch contexts; Minikube handles that for you behind the scenes, making the transition between isolated environments feel almost instantaneous.
The next step is understanding how to share these Minikube environments or configure advanced networking between them.