Kubernetes manages clusters through a control plane that stores desired state, exposes the API, schedules workloads, and runs controllers that continually move the cluster toward the requested configuration. Understanding these components explains why Kubernetes behaves differently from a collection of scripts: users declare objects through the API, and independent control loops cooperate to make reality match those declarations.
The current KCNA curriculum places Kubernetes architecture at the center of foundational knowledge, while CKA expects deeper operational skill. Learners do not need to memorize every command before the architecture makes sense. Start with the responsibility of each control-plane component and follow a simple Deployment from API request to running Pod.
Think of the API server as the front door
The kube-apiserver exposes the Kubernetes API. Clients such as kubectl, controllers, schedulers, operators, and automation interact with cluster state through that API rather than editing the underlying datastore directly. The API server validates requests, performs authentication and authorization, runs admission controls, and persists accepted objects.
That central role makes API availability critical. A temporary API server outage may not immediately stop already running containers, but administrators and controllers cannot coordinate desired-state changes normally until access returns.
API design also explains why Kubernetes is extensible. Custom resources can add new declarative object types while controllers implement the behavior associated with them.
Use etcd as the source of cluster state
etcd is the consistent key-value store used for Kubernetes cluster data. The API server persists object state there, which makes etcd one of the most critical components to protect and back up. A cluster can recreate application Pods from Deployment definitions, but losing the authoritative cluster state is a much larger recovery event.
Operators should not treat etcd like a general application database. Access should be tightly restricted, backups tested, and latency monitored because control-plane performance depends on reliable state storage.
In managed Kubernetes services, the provider may operate etcd. The architectural responsibility still matters because it explains where cluster truth lives even when administrators do not manage the datastore directly.
Let the scheduler decide where unscheduled Pods should run
The kube-scheduler watches for Pods that do not yet have a node assignment. It evaluates available nodes against requirements and constraints, then binds the Pod to an appropriate node. Scheduling considers resource requests, node selectors, affinity, taints and tolerations, topology, and other policies.
The scheduler does not start the container itself. It chooses the node. The kubelet on that node later works with the container runtime to create the containers described by the Pod.
This distinction helps troubleshoot Pending Pods. A container error happens after scheduling; a Pod that never receives a node assignment usually points to scheduling constraints, insufficient resources, or policy.
Use controller managers to reconcile desired state
The kube-controller-manager runs multiple controllers that watch cluster objects and take action to move actual state toward desired state. If a Deployment declares three replicas and one Pod disappears, controllers create replacement work so the desired replica count can be restored.
Controllers implement the self-healing behavior associated with Kubernetes. They do not continuously run one giant orchestration script. Each controller focuses on particular resources and reconciliation logic, which makes the system modular.
The cloud-controller-manager can separate cloud-provider-specific control loops, such as integrations for nodes, routes, or load balancers, from the core Kubernetes components when the environment uses that architecture.
Follow a Deployment request through the control plane
When a user applies a Deployment manifest, kubectl sends the object to the API server. After validation, authorization, and admission, the object is stored. The Deployment controller notices the new desired state and creates or updates a ReplicaSet. The ReplicaSet controller ensures the required Pods exist.
New Pods initially have no node. The scheduler selects suitable nodes and records bindings. Kubelets on those nodes observe the assigned Pods and ask the container runtime to pull images and start containers. Status flows back through the API.
This sequence illustrates the Kubernetes model: the control plane coordinates desired state, while node components execute workloads.
Understand the boundary between control plane and worker nodes
Worker nodes run kubelet, a container runtime, networking components, and application Pods. The control plane decides and records what should happen; node agents make the assigned workloads happen locally.
The kubelet watches Pod specifications assigned to its node, prepares volumes and networking as required, and uses the Container Runtime Interface to manage containers. It reports status back to the API.
The container foundation described in Pods and containers becomes operational here: the Pod is the Kubernetes workload unit, while the runtime executes the containers inside it.
Protect control-plane communication with identity and authorization
Because the API server is the control-plane entry point, authentication, authorization, and admission are central security controls. Human users, service accounts, nodes, and controllers should receive only the permissions required for their responsibilities.
RBAC rules can restrict which API resources an identity may read or modify. Admission policy can reject or mutate requests based on organizational rules. Network and certificate security protect component communication.
Do not give automation cluster-admin permissions simply because configuration is easier. A compromised CI system or operator then has the same power as the most privileged administrator.
Design control-plane availability according to the environment
Production clusters typically need redundant control-plane components so that one machine failure does not remove management availability. Multiple API server instances can sit behind a load balancer, and etcd can run as a highly available cluster with quorum requirements.
High availability does not mean every component needs identical scaling. The architecture should account for API request volume, etcd performance, controller activity, and failure domains. Managed Kubernetes services may provide this resilience as part of the service.
Backup and disaster recovery remain distinct from high availability. A healthy redundant control plane cannot protect against corrupted or accidentally deleted state if there is no recoverable backup.
Observe the control plane as part of cluster operations
Control-plane telemetry can reveal API latency, error rates, scheduler behavior, etcd health, and controller reconciliation problems. Kubernetes observability should include those signals alongside node and application metrics.
A slow API server can delay controllers and administrative actions even when application Pods are still serving traffic. etcd latency can affect the whole control loop. Scheduler problems can leave new workloads Pending. Monitoring these components helps operators distinguish application failures from cluster-management failures.
The cloud native operating model described in Kubernetes application concepts becomes easier to troubleshoot when developers understand what the control plane is doing on their behalf.
Use the architecture to reason about failures
If an existing Pod keeps running while kubectl commands fail, investigate API availability and control-plane connectivity. If new Pods remain Pending, inspect scheduling events and resource constraints. If a Deployment does not replace a failed Pod, inspect controller behavior and API state. If many cluster actions become slow, consider etcd and API performance.
Architecture turns symptoms into a search path. Operators do not need to guess randomly across every component because each part of the control plane has a defined responsibility.
The API server supports watches that allow controllers and clients to react to changes without constantly polling full state. This event-driven model is central to efficient reconciliation. Controllers establish watches, observe relevant objects, and enqueue work when desired or actual state changes. Understanding watches explains why the API server is involved in so many control loops even when users are not running kubectl.
Leader election helps highly available controllers and schedulers avoid performing the same active responsibility simultaneously. Multiple replicas can exist for resilience, while one holds the leadership lease for a particular control loop. If the leader fails, another replica can acquire leadership. This pattern improves availability without duplicating every scheduling or reconciliation decision.
Scheduler behavior is extensible. Modern Kubernetes scheduling uses a framework with stages and plugins for filtering, scoring, reserving, and binding. Operators do not need to memorize the framework to understand the principle: scheduling is a policy decision based on resource availability and constraints, not a random node choice.
Controllers are intentionally level-based rather than step-based. They observe current and desired state and work toward convergence. If an intermediate action fails, the next reconciliation can try again from the current state. This design is one reason Kubernetes tolerates transient failures better than brittle orchestration scripts that assume every previous step completed exactly once.
etcd backup procedures should be tested, not merely documented. A backup that cannot be restored under pressure is not a recovery strategy. Record Kubernetes and etcd version compatibility, encryption requirements, certificate dependencies, and the procedure for restoring API access after state recovery.
Managed Kubernetes changes who operates the control plane but not the mental model. A cloud provider may hide API server replicas, etcd maintenance, or control-plane patching, while users still interact with the same Kubernetes API and controllers. Understanding the components helps teams decide which incidents belong to their workloads and which require provider escalation.
Admission happens after authentication and authorization but before an accepted object is persisted. Mutating admission can modify requests, while validating admission can reject objects that violate policy. This is where organizations can enforce requirements such as approved image registries, security settings, or resource limits before a workload enters the cluster.
Control-plane certificates and time synchronization are operational dependencies. Expired certificates can break component communication, and large clock differences can complicate TLS and event analysis. Self-managed clusters need documented certificate renewal and health checks; managed services may automate some of this responsibility.
Version skew matters during upgrades. Kubernetes supports defined compatibility ranges among API server, kubelet, controller, scheduler, and kubectl versions. Upgrade procedures should follow supported order and test critical admission webhooks and custom controllers, because cluster extensions can fail even when core components are healthy.
API deprecations can affect both users and controllers. Before upgrades, scan manifests and custom integrations for removed API versions, update clients, and confirm that admission webhooks support the target release. Control-plane modernization is safer when deprecated interfaces are removed deliberately rather than discovered during an outage.
Events are useful clues but are not a complete historical log. Retention is limited, so important operational evidence should also flow into centralized observability systems when teams need longer forensic history.
Control-plane troubleshooting should begin with component responsibility and recent change history. A clear mental model plus observability prevents teams from restarting components blindly and destroying evidence that could explain the failure.
Document component ownership, escalation paths, and recovery dependencies before an outage turns architecture knowledge into an emergency research task.
Practice recovery so architecture knowledge becomes operational muscle memory.
Run periodic control-plane recovery exercises so teams verify backups, certificates, escalation paths, and restoration procedures before a real outage.
For learners in the CNCF ecosystem, the core model is straightforward: the API server receives and validates desired state, etcd stores it, the scheduler assigns unscheduled Pods, controllers reconcile resources, and node components execute the resulting workload. That mental model is the foundation for deeper Kubernetes administration.