Architecture questions are the gateway to every Kubernetes interview. Before diving into specific workloads or security topics, interviewers want to know that you understand how the system works from the ground up.
A classic opening question is "Walk me through what happens when you run kubectl apply." The ideal answer traces the request from kubectl through the API server's authentication, authorization, and admission stages, into etcd for persistence, then through the scheduler for node assignment, and finally to the kubelet for container creation. Candidates who can narrate this flow confidently demonstrate they understand the platform rather than just its CLI.
Follow-up questions often target specific components: "What happens if etcd goes down?" "How does the scheduler decide which node to place a Pod on?" "What is the difference between a controller and an operator?" These questions test whether candidates can reason about failure modes and design decisions.
For senior roles, interviewers may ask about high availability configurations — multi-master setups, etcd cluster sizing, and leader election. Understanding the CRI, CNI, and CSI interfaces also signals that you appreciate Kubernetes as a pluggable platform rather than a monolithic system.
kube-proxy is a network component that runs on every node and implements Kubernetes Service abstraction by maintaining network rules that route traffic to the correct backend pods. It supports iptables and IPVS modes for packet forwarding and load balancing.
The kubelet is the primary node agent that runs on every node in the cluster. It registers the node with the API server, watches for pod assignments, manages container lifecycle through the container runtime, runs health probes, reports node and pod status, and manages static pods.
etcd is a distributed, strongly consistent key-value store that serves as the backing store for all Kubernetes cluster data. Every object, configuration, and piece of state in the cluster is persisted in etcd, making it the single source of truth.
The Kubernetes control plane is the set of components that manage the overall state of the cluster. It consists of the kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and optionally the cloud-controller-manager, all working together to maintain desired state.
The cloud-controller-manager is an optional control plane component that embeds cloud-specific control logic. It separates cloud provider integrations from core Kubernetes code, running controllers for node lifecycle, routes, and load balancers that interact with the underlying cloud provider's API.
CNI is a specification and set of libraries for configuring network interfaces in Linux containers. In Kubernetes, the kubelet invokes a CNI plugin when creating or destroying pods to assign IP addresses, set up routes, and connect pods to the cluster network. Popular CNI plugins include Calico, Cilium, Flannel, and Weave Net.
CRI is a plugin interface that allows the kubelet to communicate with different container runtimes without being tightly coupled to any one implementation. It defines a gRPC-based API for image management and container lifecycle operations, with containerd and CRI-O being the two primary implementations.
CSI is a standard interface that allows Kubernetes to work with any storage system without requiring storage-specific code in the Kubernetes codebase. CSI drivers run as pods in the cluster and handle volume provisioning, attaching, mounting, and snapshotting through a well-defined gRPC API.
The kube-scheduler watches for unscheduled pods and assigns them to nodes through a two-phase process: filtering (eliminating nodes that cannot run the pod) and scoring (ranking remaining nodes by preference). It considers resource requests, affinity rules, taints, tolerations, and topology constraints.
The kube-controller-manager is a single binary that runs multiple controller loops, each responsible for reconciling a specific aspect of cluster state. Controllers watch the API server for changes and take action to move actual state toward desired state, implementing the core declarative model of Kubernetes.
The kube-apiserver is the central management entity of the Kubernetes cluster. It exposes the Kubernetes API over HTTPS, handles authentication, authorization, admission control, and validation of all API requests, and is the only component that communicates directly with etcd.
etcd uses the Raft consensus algorithm to ensure strong consistency across all cluster members. Every write must be agreed upon by a majority (quorum) of members before it is committed. This guarantees that all reads return the most recent committed write, preventing split-brain scenarios and data divergence.
The Kubernetes API server supports multiple authentication methods including client certificates, bearer tokens, OIDC, and service account tokens. Requests pass through all configured authenticators until one succeeds. Once authenticated, the identity is passed to authorization (RBAC) and admission control before the request is processed.
A highly available Kubernetes cluster requires multiple control plane nodes (minimum 3) with a load balancer in front of the API servers, an etcd cluster with odd-numbered members for quorum, leader election for the scheduler and controller manager, and worker nodes spread across failure domains.
Running kubectl apply triggers a chain of events: kubectl validates and sends the manifest to the API server, which authenticates, authorizes, and runs admission controllers, then persists to etcd. Controllers detect the new object and create dependent resources, the scheduler assigns pods to nodes, and kubelets start containers via the container runtime.