Ace Your Kubernetes Interview

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.

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 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 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.

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.

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.

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.

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 HPA automatically scales the number of Pod replicas based on observed CPU, memory, or custom metrics. It periodically queries the Metrics API, computes the desired replica count using a target utilization formula, and updates the Deployment or StatefulSet accordingly.

Blue-green deployments run two identical environments (blue and green) side by side. Traffic is routed entirely to one version, and you switch instantly by updating the Service selector. This eliminates the risk of partial rollouts.

A canary deployment gradually shifts a small percentage of traffic to a new version while the majority continues hitting the stable version. If metrics look good, traffic is increased until the canary becomes the new production release.

Liveness probes restart unhealthy containers, readiness probes control whether Pods receive traffic, and startup probes protect slow-starting containers. In the context of Deployments, readiness probes are critical because they gate rolling updates and prevent broken versions from receiving traffic.

Every change to a Deployment's Pod template creates a new revision backed by a ReplicaSet. Kubernetes retains old ReplicaSets (controlled by revisionHistoryLimit) so you can inspect previous versions and roll back to them.