{"id":"l-dk-4-1","courseId":"docker-kubernetes","lang":"en","kind":"lesson","summary":"Explain how Kubernetes turns declared desired state into running containers through its control loops, name the main cluster components, and create a local kind cluster to work in.","html":"

Compose runs your stack on one machine. When that machine dies, so does your service, and nothing brings it back until a person notices. Kubernetes exists for the other case: many machines, containers that must keep running when any one of them fails, and changes rolled out without downtime. To use it well, you need one idea more than any command.

\n

The control loop

\n

In Kubernetes you don’t say “start three containers”. You say “there should be three replicas of notes-api”, and store that as an object in the cluster. Then a controller runs a loop, continuously:

\n
    \n
  1. Observe the actual state: how many notes-api Pods exist and are running?
    2. \n
  2. Compare it with the desired state in the object.
    3. \n
  3. Act to close the gap: create a Pod, delete one, replace one.
    4. \n
\n

The loop never finishes. If a node dies and takes a Pod with it, the next pass sees two where three are wanted and creates one. If you change the desired count to five, it creates two more. If someone deletes a Pod by hand, it’s replaced within seconds. This is what people mean by declarative: you describe the destination, and the system keeps steering towards it.

\n

The thermostat comparison helps. You set 21°C; the thermostat doesn’t run a fixed “heat for 20 minutes” script. It measures, compares and switches the heater on or off for as long as it’s powered.

\n

The parts of a cluster

\n
\n kubectl sends objects to the API server, which stores them in etcd. The scheduler and controller manager watch the API server. On each worker node a kubelet watches for Pods assigned to it and starts containers through the container runtime.\n \n kubectl\n \n control plane\n \n API server\n \n etcd\n \n scheduler\n \n controller\n manager\n \n \n \n \n \n node 1\n kubelet → containerd\n pod pod\n \n node 2\n kubelet → containerd\n pod\n \n \n watch: Pods for my node\n
Every component talks to the API server; controllers and kubelets reconcile state
\n\n

Managed services like Amazon EKS run the control plane for you. You still need to understand it, because every error message you’ll read refers to one of these parts.

\n

A cluster on your laptop

\n

kind (“Kubernetes in Docker”) runs a whole cluster inside Docker containers. It’s quick to create and quick to throw away, which is exactly what you want for learning:

\n
Terminal
kind create cluster --name notes\nkubectl config current-context      # kind-notes\nkubectl get nodes\nkind load docker-image notes-api:1.0.0 --name notes
\n

The last command copies your local image into the kind node, so the cluster can run it without a registry. minikube and Docker Desktop’s built-in Kubernetes work too; the kubectl commands in this course are the same everywhere.

\n

In kind, the control plane itself runs as Pods on the control-plane node. Run kubectl get pods -n kube-system and you’ll see the API server, etcd, the scheduler and the controller manager listed like any other workload, along with the cluster DNS (CoreDNS) and kube-proxy. On a managed cluster you won’t see the control plane there, because the provider runs it out of sight.

\n

Watch the loop work

\n

Create a Deployment imperatively, once, to see reconciliation with your own eyes:

\n
Terminal
kubectl create deployment notes-api --image=notes-api:1.0.0 --replicas=3\nkubectl get pods\nkubectl delete pod <one-of-the-pod-names>\nkubectl get pods --watch
\n

Within seconds a new Pod with a new name appears. You didn’t ask for it; the controller did its job. Now look at what you created:

\n
Terminal
kubectl get deployment notes-api -o yaml\nkubectl explain deployment.spec.replicas\nkubectl delete deployment notes-api
\n

-o yaml shows the full object Kubernetes stored, including many defaults you didn’t set. kubectl explain documents any field from the cluster itself; it’s the fastest reference you have. From the next lesson on you’ll write these objects as files and apply them, which is how real teams work.

\n\n

Next: the objects you just glimpsed, written properly. Pods, ReplicaSets and Deployments.

\n","toc":[{"id":"sec-1","text":"The control loop","level":2},{"id":"sec-2","text":"The parts of a cluster","level":2},{"id":"sec-3","text":"A cluster on your laptop","level":2},{"id":"sec-4","text":"Watch the loop work","level":2}],"takeaways":["You tell Kubernetes the state you want; controllers keep comparing it with the actual state and act to close the gap, forever.","The API server is the front door and the only component that talks to etcd, where all cluster state is stored.","The scheduler picks a node for each new Pod; the kubelet on that node starts its containers through the container runtime.","Deleting a Pod that a controller manages doesn’t remove it for long, because the controller sees one missing and creates a replacement.","Always check which cluster kubectl is pointed at with kubectl config current-context before changing anything."],"further":[{"title":"Kubernetes components","url":"https://kubernetes.io/docs/concepts/overview/components/"},{"title":"Controllers","url":"https://kubernetes.io/docs/concepts/architecture/controller/"},{"title":"Install and set up kubectl","url":"https://kubernetes.io/docs/tasks/tools/"}],"quiz":[{"q":"

A Deployment wants 3 replicas. A node crashes and takes one Pod with it. What restores the third Pod?

","options":[{"text":"A controller notices that 2 Pods exist where 3 are desired and creates a new one, which the scheduler places on a healthy node.","why":"Correct. The ReplicaSet controller keeps reconciling actual against desired, so it replaces the lost Pod without anyone running a command."},{"text":"The kubelet on the crashed node restarts the Pod when the node comes back.","why":"If the node is gone, its kubelet is gone too. Recovery has to come from the control plane."},{"text":"Nothing; someone must re-run kubectl apply.","why":"Desired state is already stored. Re-applying the same file changes nothing that controllers aren’t already enforcing."},{"text":"etcd restarts the Pod from its backup.","why":"etcd stores state. It never starts or stops anything."}],"answer":0},{"q":"

Which component is the only one that reads and writes etcd directly?

","options":[{"text":"The scheduler","why":"The scheduler watches and updates Pods through the API server, like every other component."},{"text":"The kubelet","why":"Kubelets talk to the API server to learn which Pods to run and to report status."},{"text":"kubectl","why":"kubectl is a client of the API server. It never sees etcd."},{"text":"The API server","why":"Correct. Everything else goes through it, which is where validation, authentication and authorisation happen."}],"answer":3},{"q":"

You delete a Pod created by a Deployment with kubectl delete pod notes-api-7d9c-xk2lp. What do you see a few seconds later in kubectl get pods?

","options":[{"text":"One fewer Pod, until you scale the Deployment again.","why":"The Deployment’s desired count didn’t change, so the shortfall is corrected straight away."},{"text":"A new Pod with a different name, created to replace it.","why":"Correct. The ReplicaSet controller sees one missing and creates a replacement. To remove Pods for good, change the Deployment."},{"text":"The same Pod, restored with the same name and IP.","why":"Pods are never restored. The replacement is a new Pod with a new name and, usually, a new IP."},{"text":"An error, because Deployment Pods can’t be deleted.","why":"You can delete them. The controller just won’t let the count stay low."}],"answer":1},{"q":"

Before running kubectl delete deployment notes-api, what should you check?

","options":[{"text":"That the image still exists in the registry.","why":"Deleting a Deployment doesn’t depend on the image. Which cluster you’re talking to does matter."},{"text":"That etcd has a recent backup.","why":"Good practice for cluster operators, but the immediate risk here is acting on the wrong cluster."},{"text":"Which cluster and namespace kubectl is pointed at, with kubectl config current-context.","why":"Correct. kubectl acts on whatever context is current. The same command means very different things in kind and in production."},{"text":"That the Deployment has fewer than 10 replicas.","why":"Replica count doesn’t change whether a delete is safe."}],"answer":2}],"exercise":{"kind":"order","items":["send","store","rs","pods","schedule","start","report"],"title":"From kubectl apply to a running container","prompt":"

You run kubectl apply -f deployment.yaml for notes-api with 3 replicas on a fresh cluster. Put what happens next in order.

\n","hints":["Nothing happens anywhere until the object is stored.","A Deployment doesn’t create Pods itself; it manages something that does.","A Pod has to be assigned to a node before any kubelet will act on it."],"explanation":"

kubectl sends the object to the API server, which validates it and stores it in etcd. The Deployment controller sees a new Deployment and creates a ReplicaSet; the ReplicaSet controller creates three Pod objects. The scheduler assigns each unscheduled Pod to a node. The kubelet on each chosen node pulls the image and starts the containers, then reports the Pod’s status back through the API server. Each step is a separate component reacting to a change it watched for.

\n","checkLabels":{},"itemText":{"send":"kubectl sends the Deployment to the API server","store":"The API server validates it and stores it in etcd","rs":"The Deployment controller creates a ReplicaSet","pods":"The ReplicaSet controller creates three Pod objects","schedule":"The scheduler assigns each Pod to a node","start":"Each node’s kubelet pulls the image and starts the containers","report":"The kubelet reports Pod status back to the API server"}},"words":684,"readMinutes":3}