Kubernetes groups containers into logical units called pods, the basic deployable unit of computing within a cluster. Each pod receives a unique IP address, allowing applications to use ports without conflict. The control plane manages this workload via components like etcd, which stores configuration data and represents the overall state of the cluster at any given point in time. The API server processes REST requests and updates the state of objects in etcd, while the scheduler selects nodes for unscheduled pods based on resource availability. This architecture supports high-availability clusters where components run as separate processes, ensuring that if a node fails, higher-level controllers launch replacement pods on healthy machines.
Control Plane Mechanics
I find the separation between the control plane and worker nodes to be clearly the best part of the design. The control plane directs communication across the system using TLS encryption, role-based access control, and strong authentication methods. Etcd favors consistency over availability during network partitions, a choice that is crucial for correctly scheduling services. If a human operator specifies three instances of a particular pod need to be running, etcd stores this fact. The Deployment controller then checks the actual state; if only two instances are running, it schedules the creation of an additional instance to match the declaration.
The kubelet agent runs on every worker node, ensuring all containers remain healthy by starting, stopping, and maintaining them as directed by the control plane. It relays node status via heartbeat messages every few seconds to the API server. Once the control plane detects a failure, a controller observes the change and launches new pods elsewhere. This self-healing capability means you do not need manual intervention to replace failed workloads. However, the removal of the dockershim in version 1.24 dropped official support for Docker as a container runtime, forcing a shift to CRI-compliant options like containerd or CRI-O.
Runtime Constraints and Support Policies
You already know how to schedule pods, so focus on the lifecycle rules that govern their survival. Until version 1.18, Kubernetes followed an N-2 support policy, meaning the three most recent minor versions received security updates and bug fixes. Starting with version 1.19, the project shifted to an N-3 support policy, extending that window to four versions. This change gives teams more time to upgrade without losing security patches immediately. The platform exerts control over compute and storage resources by defining them as objects managed through the API.
A common myth is that Kubernetes mandates specific logging or monitoring solutions, but it does not dictate these tools. It provides integrations as proof of concept and mechanisms to collect metrics, leaving the choice of logging, monitoring, and alerting systems to the user. Similarly, Kubernetes does not deploy source code or build your application; CI/CD workflows depend on organizational preferences. The system also does not provide application-level services like databases or message buses as built-in features. These components can run on Kubernetes or be accessed via portable mechanisms, but they are not included in the core distribution.
The scheduler matches resource supply to workload demand by tracking allocation on each node. It considers CPU, memory, quality-of-service requirements, and affinity directives to ensure no workload exceeds available resources. Multiple schedulers can run within a single cluster, allowing administrators to extend default behavior with custom plug-ins. Does your current cluster strategy account for the specific constraints of the N-3 support policy when planning upgrades?
