Kubernetes Interview Questions: Architecture, Control Plane and Nodes

True statements about the Kubernetes API server are: it is the only control plane component that reads from and writes to etcd directly; it validates and persists the desired state of Kubernetes objects; and it exposes the Kubernetes API over HTTP/HTTPS for clients like kubectl. The API server does not schedule pods onto nodes — that is the kube-scheduler's job.

The Kubernetes API server processes a create request in this order: authenticate the client, then authorize against RBAC, then run mutating admission controllers, then run validating admission controllers, and finally persist the object to etcd. Mutating controllers run before validating controllers so that any changes they make are visible to the validators that follow.

True. In a standard Kubernetes control plane, kube-apiserver is the only component that talks to etcd directly. The scheduler, controller manager, and other components read and write cluster state through the API server, which enforces authentication, authorization, and validation before anything is persisted.

Kubernetes persists the authoritative state of every object in etcd, a consistent distributed key-value store. The kube-apiserver is the only component that reads from and writes to etcd directly; every other component goes through the API server. Consequently an etcd backup is effectively a full cluster backup, and losing etcd without one means losing the cluster's desired state.

The kubelet is the node agent that runs on every worker node. It registers the node with the control plane, watches the API server for Pods assigned to its node, and drives the container runtime (via the CRI) to start, stop, and health-check those Pods' containers. It also reports node and Pod status back. It does not schedule Pods — it only runs the ones the scheduler placed on it.

etcd is the cluster's backing store: a consistent, highly-available distributed key-value store that holds the entire cluster state (every object and its desired/observed status). The kube-apiserver is the only component that reads from and writes to etcd; everything else goes through the API server. Because it's the single source of truth, a regular etcd backup is effectively a full-cluster backup.

The Kubernetes API server (kube-apiserver) is the central management entity of the control plane. It validates and configures API objects such as pods, services, and controllers, and it is the only control-plane component that communicates directly with the cluster's backing data store, etcd. Every other component — the scheduler, controller-manager, and each kubelet — reads and writes cluster state exclusively through REST calls to the API server, which in turn persists that state into etcd.

kube-apiserver receives the request, authenticates and authorizes it, runs admission control, and persists the Deployment object in etcd, which is the only component that stores cluster state. The Deployment controller in kube-controller-manager sees the new object through a watch and creates a ReplicaSet, and the ReplicaSet controller then creates the three Pod objects through the API server. The kube-scheduler watches for Pods with no nodeName, selects a suitable node by filtering and scoring, and writes the binding back through the API server. The kubelet on that node then starts the containers. etcd persists the desired state; the kube-scheduler assigns the Pod to a node.

kube-proxy runs on every node and implements Service networking: it programs iptables or IPVS rules (or coordinates with the CNI) so that traffic sent to a Service's stable ClusterIP is load-balanced to one of its healthy backend Pods. It does not schedule Pods (the scheduler), pull images (the kubelet and runtime), or relay kubectl commands (those hit the API server directly).

I would create three separate webhook configurations, each scoped tightly to its resource type.

Resource requests (MutatingWebhookConfiguration): A mutating webhook scoped to pods with a namespaceSelector that excludes system namespaces. It defaults missing CPU/memory requests and limits to team-specific baseline values. Because it mutates the object, it must run in the mutating phase. I set its webhook name so it runs early in the mutating chain (before any other webhook that might read resource values).

TLS certificate validation (ValidatingWebhookConfiguration): A validating webhook scoped to ingresses that checks the referenced TLS secret or cert ARN against the ConfigMap of approved certificates. This is pure enforcement — no mutation — so it belongs in the validating phase. failurePolicy: Fail and timeoutSeconds: 3: if the webhook is unavailable, the Ingress creation is rejected rather than allowing an ingress with an unapproved certificate. The trade-off is that a webhook outage blocks all Ingress writes, which is acceptable because an unapproved TLS cert is a security violation.

Namespace labels (ValidatingWebhookConfiguration): A validating webhook scoped to namespaces that rejects Namespace creation or update if mandatory labels are missing. Again failurePolicy: Fail with a short timeout.

Ordering: MutatingWebhookConfiguration always runs before ValidatingWebhookConfiguration in the API server admission chain, so the resource-request defaults are applied before any validating webhook sees the Pod. Within the mutating phase, webhooks are ordered by name; I prefix names accordingly.

Scalability: Each webhook backend runs as a Deployment with HPA behind a ClusterIP Service. Because admission is synchronous — the API server blocks the original request until all webhooks return — webhook latency directly caps API throughput. I configure keep-alive connections between the API server and webhook backends, co-locate backends on nodes close to API servers, and set aggressive timeoutSeconds (2–3s) so a slow webhook degrades rather than hangs. I also instrument webhook latency histograms and alert if p99 exceeds 100ms.