kubectl and Working with a Real Cluster

Everything so far has been YAML in the abstract. This lesson is the hands-on toolkit: kubectl, the command-line tool for talking to a cluster, and how to get a real (if small) cluster running on your own machine.

Getting a local cluster

You don't need a cloud account to learn Kubernetes. Tools like minikube and kind (Kubernetes IN Docker) run a real, small cluster locally:

# minikube
minikube start

# or kind
kind create cluster

Both give you a fully functional kubectl context pointed at a local cluster in a couple of minutes.

Core kubectl commands

kubectl apply -f deployment.yaml   # create or update a resource from a YAML file
kubectl get pods                    # list resources
kubectl get pods -o wide            # list with extra detail (node, IP)
kubectl describe pod web-7d9f8      # detailed info + recent events, great for debugging
kubectl logs web-7d9f8              # see a container's stdout/stderr
kubectl logs web-7d9f8 -f            # follow logs live
kubectl exec -it web-7d9f8 -- sh    # get an interactive shell inside a running container
kubectl delete -f deployment.yaml   # tear down what that file created

kubectl describe is usually the first thing to reach for when something isn't working, its Events section at the bottom often tells you exactly why a Pod won't schedule or start (out of resources, image pull failure, failed health check, etc).

Namespaces: dividing a cluster

A namespace is a way to partition a single cluster into logical groups, commonly one per environment or team:

kubectl create namespace staging
kubectl apply -f deployment.yaml -n staging
kubectl get pods -n staging
kubectl get pods --all-namespaces

Resource names only need to be unique within a namespace, so staging and production can each have their own web Deployment without colliding.