Why Kubernetes, and how a cluster works

Why do we need an orchestrator?

Running one container with docker run is easy. Now imagine a real company: 40 small services, each running 3 copies, spread over 10 servers. Questions appear at once. Which server has room for a new container? What happens when a server dies at 2 am? How do you update a service to a new version without stopping it? How do you go from 3 copies to 30 during a festival sale, and back again afterwards?

An orchestrator is software that answers these questions for you. You tell it what you want, and it decides where containers run, watches them, and fixes problems. Kubernetes (often written K8s, because there are 8 letters between the K and the s) is the most used orchestrator. Google started it in 2014, and it is now an open-source project of the Cloud Native Computing Foundation (CNCF).

• Self-healing: if a container crashes or a machine dies, Kubernetes starts a replacement somewhere else.
• Scaling: change a number from 3 to 30, and Kubernetes starts 27 more copies.
• Rollouts and rollbacks: update to a new image version a few copies at a time, and go back if it breaks.
• Service discovery and load balancing: give a group of copies one stable name and spread traffic across them.
• Bin packing: place containers on machines so that CPU and memory are used well.

The parts of a cluster

A cluster is a group of machines working together. Each machine is called a node; it can be a virtual machine in the cloud or a physical server. The control plane is the set of components that manage the cluster. Worker nodes are where your application containers actually run. In production the control plane runs on 3 or more machines, so one failure does not stop it.

Desired state and reconciliation

Kubernetes is declarative. Declarative means you write down the result you want ("3 copies of payments-api version 1.4"), not the steps to get there. The opposite, imperative, means giving step-by-step commands ("start a container here, then another there").

Every controller runs a reconciliation loop, also called a control loop: observe the actual state, compare it with the desired state, act to close the gap, and repeat forever. If a pod dies, the next loop notices only 2 copies are running and creates a third. Nobody has to wake up.

1. You run kubectl apply -f deployment.yaml. kubectl sends the YAML to the API server.
2. The API server checks it and stores it in etcd.
3. The Deployment controller sees a new Deployment and creates a ReplicaSet.
4. The ReplicaSet controller sees it needs 3 pods and creates 3 Pod objects.
5. The scheduler sees 3 pods with no node and assigns each one to a node.
6. The kubelet on each chosen node asks containerd to pull the image and start the container, then reports "Running".

kubectl: the everyday commands

kubectl get nodes                          # list the machines in the cluster
kubectl get pods                           # pods in the current namespace
kubectl get pods -n payments               # pods in the "payments" namespace
kubectl get pods -A                        # pods in all namespaces
kubectl describe pod payments-api-7d9c-x2k # details and recent events of one pod
kubectl apply -f deployment.yaml           # create or update objects from a file
kubectl delete -f deployment.yaml          # delete the objects in that file
kubectl logs payments-api-7d9c-x2k         # the container's output
kubectl exec -it payments-api-7d9c-x2k -- sh   # open a shell inside the container
kubectl get deployment payments-api -o yaml    # the full object as YAML
kubectl config current-context             # which cluster am I talking to?

Where to run a cluster

With a managed service you still manage your worker nodes (or pick a mode where the provider does that too) and your apps. You pay for the cluster and its nodes, so check the current pricing page before you leave a practice cluster running.