Kubernetes
What orchestration problems exist, which abstractions answer them, and how to decide whether you need any of it — taught as one implementation, not as what production means.
Kubernetes is a distributed workload orchestration platform. The first question is not how to use it but whether the orchestration problem it solves is one you actually have.
Five operational problems appear the moment you have many containers on many machines. Every Kubernetes object is an answer to one of them, and is only worth learning as such.
One model to debug against: a cluster is a control plane holding desired state and nodes running the workloads, with controllers continuously closing the gap between them.
A pod is one or more containers that share a network namespace, a lifecycle and a set of volumes — and it is the smallest thing the scheduler can place.
A Deployment is desired state — this many replicas of this image, with this rollout policy — that a controller works toward continuously, including after failures nobody scripted.
A ReplicaSet keeps N pods matching a template alive. It exists so that a Deployment can roll out by scaling two of them in opposite directions — and that is the only reason you should ever look at one.
Pod IPs change every time a pod is replaced. A Service is a name and address that keeps meaning "the currently ready pods for this workload", updated continuously as that set changes.
Internal Services are unreachable from outside. Something at the edge must terminate TLS, match hostnames and paths, and route to the right Service — and which object expresses that is currently in transition.