Production clusters have many nodes, but for learning you want one on your own machine. Common choices are minikube, kind, and the Kubernetes option built into Docker Desktop. This guide uses minikube with the Docker driver. The kubectl commands are identical on any of them, and on any real cluster.

Install a container tool, minikube, and kubectl

minikube needs either a container runtime or a virtual machine to host its node. Docker is the most common choice, so install Docker Desktop (or Docker Engine on Linux) first and make sure it’s running. Then install minikube and kubectl. On macOS with Homebrew:

brew install minikube kubectl

For other systems, follow the minikube install page and the kubectl install docs, which have current instructions for each OS. minikube needs roughly 2 CPUs, 2 GB of free memory, and 20 GB of disk.

Start the cluster

minikube start --driver=docker
minikube status

The first start is slow because minikube downloads the images it needs. The driver setting means the whole minikube node runs as a Docker container on your machine. Inside that node, Kubernetes runs your Pods with its own container runtime, so there are two layers of containers. That can look confusing at first, but it doesn’t affect how you use the cluster.

Confirm kubectl can reach it

kubectl cluster-info
kubectl get nodes

You should see one node with the control-plane role and a Ready status. That single node runs both the control plane and your workloads, which is exactly the local-development shortcut described in the architecture guide.

Understand kubeconfig and contexts

For kubectl to talk to a cluster it needs the cluster’s address and credentials. It reads them from a kubeconfig file, by default ~/.kube/config, and minikube start adds an entry for you. Each entry combines a cluster, a user, and optionally a default namespace into a context:

kubectl config get-contexts
kubectl config current-context
kubectl config use-context minikube

Check the current context before running anything destructive. If your kubeconfig also contains a staging or production cluster, the current context decides which one your commands hit.

Learn the everyday commands

kubectl get pods                # list Pods in the current namespace
kubectl get pods -A             # list Pods in all namespaces
kubectl describe pod NAME       # details and recent events for one Pod
kubectl logs NAME               # a container's output
kubectl delete pod NAME         # remove a Pod
kubectl api-resources           # every resource type the cluster knows
kubectl explain pod.spec        # built-in reference for any field
kubectl get --help              # help for any command

kubectl explain is worth remembering: it documents every field of every resource, straight from the cluster’s API, so you rarely need to leave the terminal to look up a field.

When you’re done for the day, minikube stop pauses the cluster and minikube delete removes it entirely.