Kubernetes Core Concepts: Architecture, Pods, Deployments, and Services

A Kubernetes cluster is a set of machines, called nodes, that run containerized applications. Every node plays one of two roles. Control plane nodes host the components that make global decisions: they expose the API, store cluster state, decide where workloads run, and detect and respond to events such as a crashed container. Worker nodes do the actual running: each one hosts the agents that start containers, keep them healthy, and route traffic to them.

The split matters because it explains the answer to a whole family of exam questions. When you are asked which component schedules a Pod, stores state, or forwards Service traffic, the first filter is: does that job belong to the brain of the cluster or to the muscle? The table below is the map you should memorize.

Note that the kubelet and a container runtime also run on control plane nodes in most setups, which is how the control plane components themselves can run as Pods. In managed cloud offerings such as EKS, AKS, and GKE, the provider operates the control plane for you and you mostly interact with worker nodes and the API.

The kube-apiserver is the front end of the control plane and the only component every other part of the system talks to. All communication - from kubectl, from the kubelet on each node, from controllers, from dashboards - flows through its REST API. It authenticates each request, authorizes it, validates the object, and persists it. Nothing bypasses it: components never talk to each other directly about cluster state, and clients never talk to etcd directly.

etcd is a consistent, distributed key-value store that acts as the cluster's single source of truth. Every object you create - Pods, Deployments, Services, ConfigMaps, Secrets - is stored in etcd. Only the API server reads from and writes to etcd. If etcd loses its data and you have no backup, the cluster forgets everything it was supposed to be running, which is why an etcd snapshot is the canonical cluster backup: it captures every Deployment, Service, ConfigMap and Secret in one place.

Production control planes run etcd as a cluster of an odd number of members (three or five) because etcd only accepts writes while a quorum - a majority of members - is healthy. A three-member cluster tolerates one failed member; a five-member cluster tolerates two. If a three-member cluster loses two members, the survivor cannot form a majority, so the API server can no longer persist any change: creates, updates, scaling and deletes all fail. Workloads already running are not affected, because the kubelets on the nodes keep their containers running without consulting etcd. The cluster is frozen, not down.

The kube-scheduler watches for newly created Pods that have no node assigned and selects a node for each one. It filters out nodes that cannot fit the Pod (insufficient CPU or memory, unsatisfied constraints) and scores the remainder to pick the best. Crucially, the scheduler only makes the placement decision; it does not start containers.

The kube-controller-manager runs the built-in controllers as a single process: the ReplicaSet controller, the Deployment controller, the Job and CronJob controllers, the StatefulSet and DaemonSet controllers, the node controller, and many more. Each controller runs a watch loop that compares desired state with observed state and issues API requests to close the gap. The node controller is the one that watches node heartbeats: every kubelet regularly renews a Lease object and reports node status, and when those heartbeats stop for longer than a grace period, the node controller marks the node NotReady (its Ready condition becomes Unknown) and taints it, after which the Pods on it are evicted so their controllers can replace them elsewhere.

A separate cloud-controller-manager holds the controllers that must call a cloud provider's API, so that core Kubernetes stays provider-neutral. Its service controller is what provisions an external load balancer when you create a Service of type LoadBalancer; its node and route controllers label nodes with cloud metadata and program cloud network routes. The two are easy to confuse, so keep the split clear:

The kubelet is the node agent. It registers the node with the API server, watches for Pods scheduled to its node, and makes sure the containers described in each PodSpec are running and healthy. It instructs the container runtime to pull images and start containers, runs liveness and readiness probes, and reports Pod and node status back to the API server. Remember the boundary: the kubelet manages containers that belong to Kubernetes Pods, not arbitrary containers someone started by hand on the node.

The kubelet is also the source of the node's heartbeat. If the kubelet process stops while the container runtime keeps going, the containers already running on that node carry on serving - the runtime does not need the kubelet to keep them alive - but nothing is restarting failed containers or reporting status any more, so after the grace period the node controller sets the node's Ready condition to Unknown (which kubectl shows as NotReady) and its Pods are eventually evicted and replaced elsewhere.

Two of the probes the kubelet runs are easy to confuse because they react to failure in completely different ways:

The container runtime is the software that actually runs containers. Kubernetes talks to it through the Container Runtime Interface (CRI), a standard API that lets any conformant runtime plug in. The common choices are containerd and CRI-O. Docker Engine is not a CRI runtime by itself; Kubernetes removed its special-case Docker integration (dockershim) in version 1.24, and Docker-built images continue to run fine because they follow the OCI image standard.

kube-proxy runs on each node and implements the Service abstraction at the network level. It watches Services and their backing endpoints through the API server and programs forwarding rules on the node - typically iptables or IPVS rules - so that traffic sent to a Service's virtual IP is routed to one of the healthy Pods behind it. Despite the name, it usually does not proxy packets through itself; it programs the kernel to do the forwarding. Because those rules are per node, a kube-proxy problem is confined to its own node and to Service traffic: direct Pod-to-Pod traffic by Pod IP does not depend on kube-proxy, so it keeps working, while Service virtual IPs on that node stop being routed correctly. If kube-proxy merely stops, the rules it already programmed remain but go stale - new Services and endpoint changes are not picked up - so Service traffic from that node fails or reaches outdated endpoints, while other nodes are unaffected.

A useful exam heuristic: if a question is about deciding or recording, the answer is a control plane component; if it is about running containers or moving packets on a node, the answer is the kubelet, the runtime, or kube-proxy.

A Pod is the smallest deployable unit in Kubernetes. You never deploy a bare container; you deploy a Pod that wraps one or more containers. The containers in a Pod are always scheduled together onto the same node, and they share two things: a network namespace - one IP address, one port space, so they can reach each other on localhost - and optionally volumes, shared storage directories that any container in the Pod can mount.

Most Pods hold a single application container. Multi-container Pods exist for tightly coupled helpers: a log-shipping sidecar, a proxy that terminates TLS in front of the app, or an init container that runs setup work to completion before the main container starts. If two processes scale independently or do not need to share an IP and volumes, they belong in separate Pods: a Pod is the unit of scaling, so every replica of a Pod carries a copy of every container in it. Putting an API server and its session store in one Pod means scaling the API to six replicas also creates six separate, unshared session stores.

Sharing files between containers in a Pod is done with a Pod-level volume. The classic example is an emptyDir volume: it is created empty when the Pod starts, lives as long as the Pod, and can be mounted by several containers - often at different paths. An application writes its log files into the emptyDir and a log-shipping sidecar mounts the same volume and reads them, with no change to the application. Not every volume type is writable: configMap and secret volumes are mounted read-only, so they can deliver configuration into a container but cannot be used to pass data between containers. Kubernetes also supports native sidecar containers - init containers with restartPolicy: Always - which start before the main container and keep running alongside it.

A minimal Pod manifest looks like this:

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
  - name: web
    image: nginx:1.27
    ports:
    - containerPort: 80

Pods are ephemeral. They are not resurrected when they die: if a node fails, the Pods on it are lost, and a replacement Pod is a new object with a new name and a new IP. A Pod created directly from a Pod manifest, with no controller owning it, is simply gone when its node fails: nothing exists whose job is to recreate it. That is why you almost never create Pods directly in production. Instead you create a controller object such as a Deployment, which creates and replaces Pods for you, and a Service, which gives clients a stable address in front of the churn. Both patterns follow in the next sections.

A ReplicaSet has one job: keep a specified number of identical Pod replicas running. It uses a label selector to count the Pods it owns; if there are too few it creates more from its Pod template, and if there are too many it deletes the extras. This gives you self-healing and horizontal scale, but nothing else - a ReplicaSet has no concept of versions or updates.

Because a ReplicaSet counts Pods by selector rather than by remembering which Pods it created, it can acquire Pods it never made. If you create a standalone Pod (one with no controller owning it) whose labels match a running ReplicaSet's selector, the ReplicaSet adopts it - sets itself as the Pod's owner - and now counts one Pod too many, so it deletes a Pod to return to the desired count. This is why labels used by controller selectors should not be reused on unrelated Pods.

A Deployment sits one level above. It manages ReplicaSets and provides declarative rolling updates and rollbacks. When you change a Deployment's Pod template - for example, a new image tag - the Deployment creates a new ReplicaSet and gradually scales it up while scaling the old one down, keeping the app available throughout. Because old ReplicaSets are retained as revision history, kubectl rollout undo deployment/web can roll back to the previous version. In everyday work you create Deployments and let them own the ReplicaSets; you rarely create a ReplicaSet directly.

Other workload controllers cover other shapes at the same conceptual level, and matching the shape to the controller is a core skill:

A StatefulSet gives each replica a stable ordinal name - db-0, db-1, db-2 - and, through its volumeClaimTemplates, its own PersistentVolumeClaim per replica. When db-1 is rescheduled to another node it comes back with the same name and reattaches to the same claim, so its data follows it. A Deployment cannot do this: its Pods get random names and share whatever volumes the template names.

A Deployment rollout replaces old Pods with new ones in controlled steps, governed by two settings of the default RollingUpdate strategy. maxUnavailable caps how many of the desired Pods may be unavailable during the update, and maxSurge caps how many extra Pods may exist above the desired count; both default to 25% (maxUnavailable rounds down, maxSurge rounds up). With replicas: 10, 25% is 2.5, so at most two Pods may be unavailable (rounded down) and at most three extra Pods may exist (rounded up) at any moment.

Those limits are what protect you from a bad release. If the new Pods never become ready - because the image cannot be pulled, the container crashes on start, or the readiness probe never passes - the Deployment cannot remove more old Pods than maxUnavailable allows, so most of the old Pods keep serving and the rollout simply stalls. After progressDeadlineSeconds (600 seconds by default) the Deployment reports a Progressing condition of False with reason ProgressDeadlineExceeded. That is a signal only: Kubernetes does not roll back automatically. A person or a tool must fix the template or undo the rollout.

To go back, use kubectl rollout undo deployment/web (optionally --to-revision=N; kubectl rollout history lists the revisions). It restores the previous Pod template, and the Deployment scales the old ReplicaSet back up. Deleting a ReplicaSet is not a rollback.

Underneath all of this is ownership. Each Pod carries an owner reference to its ReplicaSet, and each ReplicaSet to its Deployment. Two consequences follow:

• The owner's spec wins. If you run kubectl scale on a ReplicaSet that a Deployment owns - say from 2 to 5 - the Deployment controller notices the ReplicaSet no longer matches the Deployment's own replicas: 2 and scales it straight back. Change the Deployment, not the objects it manages.
• Deletion cascades. Deleting an owner deletes its dependents by default (background cascading deletion), so kubectl delete replicaset on a Deployment's current ReplicaSet deletes its Pods too. The Deployment then sees it has no ReplicaSet for its current template and creates a new one, which creates new Pods - from the current template, not an older one. Passing --cascade=orphan deletes only the owner and leaves the dependents running without an owner.

Pods come and go, and every new Pod gets a new IP address. Clients cannot chase that churn, so Kubernetes provides the Service: an object that defines a stable virtual IP (the ClusterIP) and a stable DNS name in front of a dynamic set of Pods. The Service selects its backend Pods with a label selector; whichever Pods currently match the selector and pass their readiness checks receive the traffic. The set of matching Pod addresses is tracked in EndpointSlice objects, and kube-proxy on every node programs the rules that spread connections across them. A Pod that is running but failing its readiness probe is kept out of the ready endpoints, so it gets no Service traffic until the probe passes again.

A Service is not attached to a Deployment or any other controller - it is attached only to labels. The Service's selector and the Deployment's selector are independent, and each just matches Pod labels. That makes a classic mistake easy: if a rollout changes the Pod template's labels (for example track: stable to track: canary) while the Service still selects track=stable, the rollout completes happily, the old Pods are removed, and the Service is left with no endpoints. Clients get connection failures even though every Pod is healthy. Keep Service selectors on the stable labels (such as app) that all versions share.

Service types build on each other, and the exam expects you to match type to scenario:

• ClusterIP (the default): a virtual IP reachable only inside the cluster. Use it for internal service-to-service traffic.
• NodePort: additionally opens the same port on every node, so external clients can reach the Service at any node's IP on that port.
• LoadBalancer: additionally asks the cloud provider to provision an external load balancer that forwards to the Service. The standard way to expose an app publicly on a managed cloud cluster.
• ExternalName: no proxying at all; it returns a DNS CNAME pointing at an external hostname.

In-cluster DNS makes discovery simple: a Service named db in namespace prod resolves as db from inside that namespace, or as db.prod.svc.cluster.local from anywhere in the cluster. For HTTP routing concerns such as virtual hosts and paths, an Ingress (or the newer Gateway API) sits in front of Services, but the Service remains the stable target underneath.

Namespaces divide one physical cluster into virtual slices. Object names must be unique only within a namespace, so team A and team B can each have a Deployment called api without colliding. Namespaces are also the scope for access control and resource limits, which makes them the standard boundary between teams, environments, or applications sharing a cluster. Every cluster starts with a few: default (where objects land when you specify nothing), kube-system (Kubernetes' own components), kube-public, and kube-node-lease. Not everything is namespaced - nodes and PersistentVolumes, for example, are cluster-scoped.

When you create a namespaced object with kubectl, its namespace is resolved in this order: the metadata.namespace in the manifest or the -n/--namespace flag (if both are given and they disagree, kubectl refuses with an error); otherwise the namespace set on the current kubeconfig context; otherwise default.

Labels are key-value pairs attached to objects, such as app: web or tier: frontend. They carry no meaning to Kubernetes by themselves; their power is that other objects select on them. A selector is a query over labels, and it is the glue of the whole object model: a ReplicaSet's selector.matchLabels decides which Pods it counts as its replicas, and a Service's selector decides which Pods receive its traffic. You can use the same mechanism interactively: kubectl get pods -l app=web lists only the matching Pods.

Two distinctions are worth locking in for the exam. First, labels are for selection; annotations are also key-value metadata but are for non-identifying information (build numbers, tool configuration) and cannot be used in selectors. Second, namespaces isolate names and policy, not the network: by default, Pods in different namespaces can still reach each other, and restricting that traffic is the job of NetworkPolicies.

Kubernetes is a declarative system. You do not send it a sequence of commands to execute; you send it a manifest - typically YAML - that describes the desired state, and you apply it with kubectl apply -f deployment.yaml. The API server validates the object and stores it in etcd. From that moment, a set of controllers works continuously to make the observed state of the cluster match what you declared. This watch-compare-act cycle is the reconciliation loop, and it never stops: it is not a one-time deployment script but a standing promise.

Walk through a concrete scenario. You apply a Deployment named web with replicas: 3. The Deployment controller sees it and creates a ReplicaSet; the ReplicaSet controller sees it needs three Pods and creates three Pod objects; the scheduler assigns each Pod to a node; the kubelet on each chosen node sees a Pod bound to it and tells the container runtime to pull the image and start the containers; kube-proxy updates its rules so the web Service can reach them. Now a worker node dies. The node controller marks it unhealthy, its Pods are eventually removed, the ReplicaSet controller observes two replicas where three are desired, and it creates a replacement Pod, which is scheduled onto a surviving node and started. Nobody paged an operator; the loop healed the gap.

This is why declared state beats imperative commands: the same manifest can be applied repeatedly with the same result, stored in version control, and reviewed like code - the foundation of GitOps. It is also the definition of self-healing that KCNA questions probe: Kubernetes does not prevent failures, it detects divergence from desired state and corrects it.

Every component failure has a predictable blast radius, and it always follows from the division of labour: running containers depend only on the kubelet and runtime of their own node, while every change needs the API server, etcd, and whichever controller or scheduler acts on it. So a control plane outage almost never stops running applications - it stops the cluster from changing or healing.

Once the failed component returns, the reconciliation loop catches up: the scheduler binds the Pending Pods, the controller manager notices missing replicas and creates them. Nothing has to be replayed, because desired state was never lost - it is still in etcd.