Kubernetes Interview Questions: Core Concepts to Advanced Orchestration

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 Deployment manages Pods indirectly through a ReplicaSet: the Deployment owns ReplicaSets, and each ReplicaSet owns the Pods. This indirection is what makes rolling updates work — a new ReplicaSet is created for the new template and scaled up while the old one scales down. kubectl get rs shows the ReplicaSets behind your Deployments.

Secret values are only base64-encoded, which is encoding, not encryption — anyone who can read the Secret (or etcd) can trivially decode them. Encryption at rest in etcd is opt-in (an EncryptionConfiguration on the API server). Hashing would be useless because Kubernetes must hand the real value to the Pod. Treating Secrets as 'encrypted by default' is a common and dangerous assumption.

Readiness controls traffic, not lifecycle: a failing readiness probe takes the Pod out of the Service's endpoint list so no new requests are routed to it, but the container is left running. Restarting on failure is the liveness probe's job. This split lets a Pod signal 'busy / warming up, don't send me traffic' without being killed — useful during cache warm-up or temporary overload.

StatefulSets give each replica a stable, ordinal identity (db-0, db-1), a matching stable DNS name, and a PersistentVolumeClaim that follows that identity across reschedules — exactly what clustered databases and quorum systems need. A stateless tier is a Deployment, one-Pod-per-node is a DaemonSet, and run-to-completion work is a Job. Reaching for a StatefulSet for a stateless app just adds ordering constraints you don't want.

Scheduling is driven by requests: the scheduler only places a Pod on a node whose unreserved allocatable capacity can cover the Pod's total requests, regardless of actual live usage. Limits cap runtime behaviour (CPU throttling, OOM kills) but are ignored at scheduling time. Setting requests too low overpacks nodes; setting them too high wastes capacity and can leave Pods Pending.

Environment variables are resolved once, when the container starts, so editing the ConfigMap has no effect on running Pods until they're recreated (e.g. kubectl rollout restart deployment). This trips people up because a ConfigMap mounted as a volume does get updated in place (eventually, via the kubelet sync) — but the env-var path never does. If config must change live, mount it as a file and watch it, or roll the Deployment.

etcd is the single source of truth: a consistent, distributed key-value store that holds all cluster state. The kube-apiserver is the only component that talks to etcd directly; everything else reads and writes through the API server. This is why an etcd backup is a cluster backup, and why losing etcd without a backup means losing the cluster's desired state.

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.

Guaranteed requires every container to specify CPU and memory requests and limits, with request equal to limit for each resource. Miss any of those and the Pod is Burstable (some requests/limits set) or BestEffort (none) — both evicted earlier under node pressure. Priority (d) is a separate mechanism: it influences preemption and eviction ordering too, but it does not determine the QoS class. Conflating QoS with PriorityClass is a classic senior-level trap.

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.

False — Namespaces are a logical scope (for names, RBAC, and quotas), not a network boundary. By default any Pod can reach any other Pod's IP across Namespaces; the flat cluster network is wide open. To actually restrict cross-Namespace traffic you apply NetworkPolicies (and your CNI must enforce them). Believing Namespaces isolate traffic is a common source of accidental exposure between teams or environments.

True. Each Deployment update creates a new ReplicaSet and keeps prior ones (up to revisionHistoryLimit, default 10) scaled to zero. rollout undo simply scales a previous ReplicaSet back up and the current one down — a fast rollback with no rebuild. If you set revisionHistoryLimit: 0, that history is discarded and undo has nothing to roll back to, which is a trap people hit when trimming clutter.

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.

port is the port the Service listens on; targetPort is the container port it forwards to. Here clients hit :80, which the Service forwards to :8080 on each Pod — but the app listens on :3000, so connections are refused/time out. Fix targetPort to 3000 (or name the container port and reference it). type defaults to ClusterIP, port: 80 is allowed, and targetPort defaults to port only when omitted. Endpoints existing but traffic failing is the tell that it's a port mapping, not a selector, problem.