Container Orchestration: KCNA practice questions

Container orchestration is everything Kubernetes does to keep many containers running across many machines: placing them on nodes, restarting them, giving them storage and network access, and controlling who can talk to whom.

At the bottom of the stack is the container runtime. The kubelet on each node does not run containers itself; it talks to a container runtime through the Container Runtime Interface, a gRPC protocol in which the kubelet is the client and the runtime is the server. Because the CRI is a plugin interface, runtimes can be swapped without recompiling cluster components.

Some workloads are about placement rather than replica count. A DaemonSet ensures that all, or some, nodes run a copy of a Pod: when a node joins the cluster a Pod is added to it, and when a node leaves the Pod is garbage collected, which is why DaemonSets are used for node-level agents such as log collectors, monitoring daemons and cluster storage daemons.

Health checking is what lets the orchestrator heal workloads. A Pod's restartPolicy is Always, OnFailure or Never, with Always as the default. A liveness probe that fails more often than its threshold makes the kubelet restart the container. A readiness probe that fails does not restart anything; instead the Pod's IP is removed from the EndpointSlices of every matching Service, so it stops receiving traffic. A startup probe holds back the liveness and readiness probes until the application has finished starting, and if it fails the container is killed and the restart policy applies. Probes can run a command (exec) or make an httpGet, tcpSocket or grpc check.

Storage separates what an application asks for from what the cluster provides. A PersistentVolume is a piece of storage in the cluster with a lifecycle independent of any Pod. A PersistentVolumeClaim is a user's request for storage of a certain size and access mode. When no existing volume matches, a StorageClass lets the cluster provision one dynamically. ReadWriteOnce means the volume can be mounted read-write by a single node, ReadOnlyMany and ReadWriteMany allow many nodes, and ReadWriteOncePod limits it to a single Pod. With the Retain reclaim policy, deleting the claim leaves the volume in the Released phase with its data intact until an administrator reclaims it by hand.

Network isolation is opt-in. By default a Pod accepts all inbound connections and may open any outbound one. A NetworkPolicy that selects a Pod and lists Ingress in its policyTypes isolates its incoming traffic, and Egress does the same for outgoing traffic; once isolated, only connections allowed by some policy get through, and for a connection between two Pods both the sender's egress and the receiver's ingress must allow it. NetworkPolicies are implemented by the network plugin, so creating one in a cluster whose plugin does not support them has no effect at all.