Kubernetes Core & Architecture
Cluster architecture, control plane, etcd, the Pod as the schedulable unit, namespaces, and how kubectl apply flows through the control loop.
11 questions
JuniorTheoryVery commonWhat is a Pod, and why is it the smallest schedulable unit rather than a single container?
What is a Pod, and why is it the smallest schedulable unit rather than a single container?
A Pod is the smallest unit Kubernetes schedules: one or more tightly-coupled containers sharing a network namespace, IP and storage, always on one node. It schedules Pods, not bare containers, so a sidecar can share localhost and lifecycle with the main app.
Common mistakes
- ✗Equating a Pod with exactly one container instead of one or more sharing a namespace
- ✗Thinking a Pod's containers can land on different nodes rather than co-located on one
- ✗Believing each container in a Pod gets its own IP rather than sharing the Pod's
Follow-up questions
- →Why can two containers in the same Pod talk over
localhost? - →When would you put a second container in a Pod instead of its own Pod?
JuniorTheoryVery commonWhat is Kubernetes, and what problem does it solve over running containers by hand?
What is Kubernetes, and what problem does it solve over running containers by hand?
Kubernetes is a container orchestrator: you declare the desired state of your workloads and it schedules, restarts, scales and load-balances containers across a cluster to match. It automates the placement, self-healing and networking you would otherwise do by hand.
Common mistakes
- ✗Calling Kubernetes a container runtime like Docker rather than an orchestrator on top of one
- ✗Thinking it runs commands once instead of continuously reconciling to a desired state
- ✗Assuming it manages a single host rather than a cluster of machines
Follow-up questions
- →What does 'desired state' mean, and how does Kubernetes keep actual state matching it?
- →How is Kubernetes different from just running
docker runon several servers?
JuniorTheoryCommonWhat is a Kubernetes namespace, and what does it isolate versus what it does not?
What is a Kubernetes namespace, and what does it isolate versus what it does not?
A namespace is a logical scope partitioning objects, so a name is unique only within it; it anchors quotas and RBAC. It does NOT isolate network or kernel — Pods across namespaces still reach each other unless a NetworkPolicy stops them.
Common mistakes
- ✗Treating a namespace as a network or security boundary on its own
- ✗Thinking cross-namespace Pod traffic is blocked by default
- ✗Believing object names must be globally unique rather than per-namespace
Follow-up questions
- →How would you actually stop traffic between two namespaces?
- →Which kinds of objects are cluster-scoped and live outside any namespace?
JuniorTheoryCommonExplain Kubernetes' reconciliation model — desired state versus actual state.
Explain Kubernetes' reconciliation model — desired state versus actual state.
You declare desired state; controllers run continuous control loops that observe actual state, compare it to desired and act to close the gap. Being level-triggered, a crashed or deleted Pod is recreated automatically, with no imperative command.
Common mistakes
- ✗Describing Kubernetes as imperative one-shot commands rather than continuous reconciliation
- ✗Thinking control loops fire once (edge-triggered) instead of running continuously
- ✗Believing you must manually recreate a crashed Pod rather than a controller doing it
Follow-up questions
- →Why does deleting a Deployment's Pod get it recreated, but deleting a bare Pod does not?
- →What does 'level-triggered' mean compared with 'edge-triggered'?
MiddleTheoryCommonName the Kubernetes control-plane components and say what each one is responsible for.
Name the Kubernetes control-plane components and say what each one is responsible for.
The api-server is the single front door — all reads and writes flow through it into etcd, the state store. The scheduler assigns unscheduled Pods to nodes, and the controller-manager runs the reconciliation loops that drive actual state toward desired.
Common mistakes
- ✗Placing kubelet or kube-proxy in the control plane instead of on worker nodes
- ✗Swapping the roles of the scheduler (placement) and controller-manager (reconciliation)
- ✗Forgetting the api-server is the only component that talks to etcd
Follow-up questions
- →Why is it a design goal that only the api-server talks to etcd directly?
- →What still works on a running cluster if the control plane goes down briefly?
MiddleTheoryCommonWhat runs on a Kubernetes worker node, and what does the kubelet, kube-proxy and container runtime each do?
What runs on a Kubernetes worker node, and what does the kubelet, kube-proxy and container runtime each do?
The kubelet is the node agent: it watches the api-server for its node's Pods and tells the runtime to start and health-check them. The runtime (containerd, CRI-O) runs containers, and kube-proxy programs routing so Service IPs reach the right Pods.
Common mistakes
- ✗Thinking the kubelet schedules Pods rather than the control-plane scheduler
- ✗Confusing kube-proxy (Service routing) with the container runtime (running containers)
- ✗Believing worker nodes run etcd or the api-server locally
Follow-up questions
- →How does the kubelet learn which Pods it should be running?
- →What does kube-proxy do differently in iptables versus IPVS mode?
MiddleTheoryOccasionalTrace end-to-end what happens when you run kubectl apply -f deploy.yaml.
Trace end-to-end what happens when you run kubectl apply -f deploy.yaml.
kubectl sends the manifest to the api-server, which validates it and writes desired state to etcd. The Deployment controller creates a ReplicaSet, which creates Pods; the scheduler assigns each Pod a node, whose kubelet pulls images and starts the containers.
Common mistakes
- ✗Thinking kubectl talks to nodes or kubelets directly instead of only the api-server
- ✗Believing the scheduler or kubelet writes to etcd rather than only the api-server
- ✗Skipping the ReplicaSet — assuming a Deployment creates Pods directly
Follow-up questions
- →How is
applydifferent fromcreatewhen the object already exists? - →At which step does the desired/actual reconciliation loop actually run?
MiddleTheoryOccasionalWhat is etcd's role in Kubernetes, and why does it matter that it is the only stateful component?
What is etcd's role in Kubernetes, and why does it matter that it is the only stateful component?
etcd is the cluster's consistent key-value store holding all desired and observed state. As the only stateful control-plane component, it lets the rest stay stateless and restartable; lose etcd without a backup and the whole cluster's state is gone.
Common mistakes
- ✗Thinking cluster state lives on the nodes rather than in etcd
- ✗Believing etcd is a disposable cache that needs no backup
- ✗Assuming multiple control-plane components each hold their own state
Follow-up questions
- →Why does etcd run as an odd-numbered cluster of 3 or 5 members?
- →What is your recovery path if etcd data is corrupted?
MiddleTheoryOccasionalWhat is the pause (infra) container, and why does every Pod have one?
What is the pause (infra) container, and why does every Pod have one?
The pause container is a tiny container started first in every Pod; it only holds the Pod's shared namespaces (network, IPC) open. App containers join them, so they share one IP and localhost and can restart without the Pod losing its network identity.
Common mistakes
- ✗Thinking the pause container runs application code rather than just holding namespaces
- ✗Confusing the pause container with an init container that runs and then exits
- ✗Believing it throttles or pauses the app containers as its name suggests
Follow-up questions
- →Why can an app container crash and restart without the Pod's IP changing?
- →How is the pause container different from an init container?
SeniorTheoryOccasionalWhat are static Pods, how do they differ from API-managed Pods, and where are they defined?
What are static Pods, how do they differ from API-managed Pods, and where are they defined?
Static Pods are run by a node's kubelet from manifest files in a watched directory (/etc/kubernetes/manifests), not the api-server. The kubelet restarts them and shows a read-only mirror Pod, but kubectl cannot control them. This is how the control plane bootstraps itself.
Common mistakes
- ✗Thinking static Pods are defined in the api or etcd rather than local node manifest files
- ✗Believing kubectl can manage a static Pod rather than only view its mirror object
- ✗Confusing 'static' with a fixed IP rather than kubelet-local management
Follow-up questions
- →How does the kube-apiserver itself run before the api-server exists?
- →What happens to a static Pod's mirror object if you
kubectl deleteit?
SeniorTheoryRareHow does the api-server stay the single source of truth, and what breaks if etcd loses quorum?
How does the api-server stay the single source of truth, and what breaks if etcd loses quorum?
All components read and write state only through the api-server, the sole writer to etcd, so truth has one copy. etcd uses Raft and needs a majority quorum to commit writes; lose quorum and it goes read-only — running Pods survive but nothing new persists.
Common mistakes
- ✗Thinking components read state peer-to-peer rather than only through the api-server
- ✗Believing losing etcd quorum deletes running Pods rather than blocking new writes
- ✗Assuming a minority of etcd members can still commit writes
Follow-up questions
- →Why does a 3-member etcd survive one failure but a 2-member cluster survives none?
- →What is the practical recovery when a 3-node etcd loses two members?
