TopolearnYou learn Kubernetes by doing; a local cluster you can delete costs nothing and breaks nothing.
You don't need a cloud account to practise. Two popular options:
- kind (Kubernetes in Docker): each node is a Docker container. Fast to create, easy to make multi-node, and used heavily in CI.
- minikube: a single-node cluster in a VM or container, with handy add-ons (ingress, metrics-server, dashboard).
Docker Desktop and Rancher Desktop can also enable a built-in cluster.
You also need kubectl, the command-line client. Keep its version within one minor version of the cluster's.
With kind, a cluster is one command, and a config file lets you add worker nodes or map ports. Because nodes are containers, an image you built locally isn't automatically visible inside the cluster: load it with kind load docker-image myapp:dev, or push it to a registry the nodes can reach.
When you are done, delete the cluster; creating a fresh one takes under a minute. Treat local clusters as cattle: if something is odd, recreate rather than repair.
Local clusters differ from production in a few ways: no cloud load balancer (Services of type LoadBalancer stay pending unless you add something like MetalLB or cloud-provider-kind), simple storage, and a single control-plane node.
Example
# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
# then, in a shell:
# kind create cluster --name dev --config kind-config.yaml
# kubectl get nodes # 3 nodes, Ready
# kind load docker-image myapp:dev --name dev
# kind delete cluster --name devRemember
- kind runs nodes as Docker containers; minikube offers add-ons
- Load local images into kind, or push them to a registry
- Delete and recreate local clusters freely
Watch out for
- Expecting a locally built image to be pullable inside kind without kind load or a registry.