Kubernetes Interview Questions — Real Practice Quiz

A Pod, not a container, is the unit Kubernetes schedules. Grasping that containers in a Pod share network and can share storage explains the sidecar pattern and why a Pod has a single IP.

ClusterIP is the default: the Service gets a stable virtual IP reachable only from inside the cluster. NodePort and LoadBalancer build on top of it to expose the Service externally, and ExternalName is a special DNS-alias type that points at an out-of-cluster host. If you forget type expecting external reach, your Service is silently internal-only.

A Pod is the smallest deployable unit and may hold multiple containers (the sidecar pattern). They share the Pod's network namespace and IP, so they communicate over localhost on different ports, and they can share volumes. They do not share a filesystem by default. This is why a logging or proxy sidecar can talk to the main container without any Service in between.

kubectl scale updates the replica count on a controller in place. It's the quick imperative path; the declarative equivalent is editing replicas in the manifest and re-applying, which also survives the next kubectl apply.

A label selector with multiple keys is a logical AND: a Pod must match every key/value to be selected. Only web-1 and web-3 have both app=web and env=prod; web-2 is excluded by env=dev. People often read it as OR (and expect 3) or assume one label per selector. This AND semantics is also why a Deployment whose selector doesn't fully match its template labels manages nothing.

The ReplicaSet continuously reconciles actual Pods toward the desired count. Manually deleting a Pod (a) or losing a Pod when its node is drained (b) both drop the count below 3, so the controller creates replacements. Scaling to 1 (c) changes the desired state — 1 Pod is now correct, nothing is recreated. An in-place container restart (d) never reduced the Pod count, so there's nothing to recreate. The distinction between 'desired state changed' and 'actual state drifted' is the core of how controllers behave.

A Deployment's selector must match the labels on its Pod template — that's how it claims the Pods it creates. Here the selector looks for app: web but the template stamps app: frontend, so the controller could never find its own Pods; the API server rejects this at admission. apps/v1 is the correct (and only served) API version, ports is optional, and replicas don't require resource requests. Selector/label drift is one of the most common Deployment authoring bugs.

This is the canonical control-plane flow: the API server is the front door and the only writer to etcd; the scheduler reacts to the unscheduled Pod and binds it to a node; the kubelet on that node reacts to the binding and drives the runtime to pull and start the container. Each component watches the API server and acts on what it sees — nobody calls anybody directly. Knowing this order is what lets you reason about where a stuck Pod is stuck (Pending = not yet scheduled; ContainerCreating = kubelet/runtime stage).

A strong answer treats 'highly available' as concrete mechanisms, not a buzzword: multiple replicas spread across failure domains (topology spread / anti-affinity), a PodDisruptionBudget for voluntary disruptions, readiness-gated rolling updates with graceful shutdown for deploys, and an HPA + Cluster Autoscaler for the traffic swing. The recurring interview signal is whether the candidate separates readiness from liveness and remembers that spreading replicas is what actually survives a node/AZ failure.

External metrics in HPA v2 use type: External with a metric.name and optional metric.selector. The MetricTarget.Type field accepts only Value or AverageValue for External metric sources. For Value, the HPA controller retrieves the raw aggregated (summed) metric value and computes desiredReplicas = ceil(currentReplicas * (rawMetricValue / targetValue)) — it multiplies the current replica count by the ratio of the raw metric to the target, scaling the replica count proportionally to how far off the metric is from the target. For AverageValue, the HPA divides the raw aggregated metric by the current replica count to get a per-replica average, then computes desiredReplicas = ceil(rawMetricValue / targetAverageValue). The key behavioral difference is that Value treats the metric as a cluster-wide total and applies a ratio against current replicas, while AverageValue normalizes the metric per replica before comparing. Utilization is exclusively valid for Resource metric sources (CPU/memory) because it expresses usage as a percentage of a pod's configured resource request — a concept that has no meaning for external time-series or queue metrics.