Top 60 Kubernetes Interview Questions (2026)

Kubernetes is an open-source system that automates deploying, scaling, and running containerized applications across a cluster of machines. You describe the state you want in YAML, and Kubernetes keeps the cluster matching it.

It solves the problem of running containers at scale: scheduling them onto machines, restarting the ones that die, scaling them up under load, rolling out new versions without downtime, and giving them stable networking. Doing all that by hand across many servers is what Kubernetes takes off your plate.

A Pod is the smallest deployable unit in Kubernetes. It wraps one or more containers that share the same network namespace (one IP, one localhost) and can share storage volumes. Containers in a Pod always run together on the same node.

Most Pods hold a single container. Multiple containers in one Pod is the sidecar pattern, where a helper (a log shipper, a proxy) runs alongside the main app and needs to share its network or files.

A container is a packaged app process. A Pod is the Kubernetes wrapper around one or more containers that share network and storage. A node is a worker machine (virtual or physical) that runs Pods.

So the nesting is: containers live inside Pods, Pods run on nodes, and nodes form a cluster. Kubernetes schedules Pods onto nodes; you rarely think about individual containers directly.

The control plane is the brain of the cluster: it makes global decisions like scheduling and responds to events. Worker nodes run the actual application Pods. Together they form a cluster.

Control plane components include the API server (the front door), etcd (the datastore), the scheduler (places Pods), and controllers (reconcile state). Each worker node runs the kubelet (starts Pods), a container runtime, and kube-proxy (networking).

A Deployment manages a set of identical Pods for you: it keeps the desired number running, replaces ones that die, and rolls out new versions gradually with the option to roll back. It does this by managing ReplicaSets under the hood.

A bare Pod is not self-healing: if it dies or its node fails, nothing recreates it. A Deployment is the object you use for almost every stateless app because it gives you self-healing and rolling updates for free.

A Service gives a group of Pods a single stable IP and DNS name, and load-balances traffic across them. Pods are ephemeral: they get new IPs when recreated, so you can't rely on a Pod IP. The Service is the stable address in front of them.

A Service finds its Pods with a label selector, so as Pods come and go the Service automatically tracks the current healthy set. Callers just talk to the Service name.

ClusterIP (the default) exposes the Service only inside the cluster. NodePort opens a fixed port on every node so traffic can reach the Service from outside. LoadBalancer provisions an external load balancer from the cloud provider and routes to the Service.

There's also ExternalName, which maps a Service to an external DNS name. In practice you use ClusterIP for internal traffic and a LoadBalancer or an Ingress for external traffic.

A namespace is a virtual partition inside a cluster that scopes names and lets you group resources. Two Pods can share a name if they're in different namespaces. It's how you separate teams, environments, or apps in one cluster.

Namespaces are also where you attach resource quotas and access control. Cluster-wide objects like nodes and PersistentVolumes are not namespaced; most everyday objects like Pods, Services, and Deployments are.

kubectl is the command-line client for Kubernetes. Every command it runs becomes an HTTP request to the cluster's API server, which is the single entry point for reading and changing cluster state.

Your connection details (server URL, credentials, current context) live in a kubeconfig file, usually at ~/.kube/config. That's why kubectl can switch between clusters: it just points at a different context.

Imperative commands tell Kubernetes to do a specific action now: kubectl create, kubectl run, kubectl delete. Declarative management describes the end state in YAML and lets kubectl apply figure out the changes needed to reach it.

Declarative is the production practice: the YAML lives in version control, apply is idempotent, and the files are the source of truth. Imperative commands are handy for quick experiments and debugging.

A ReplicaSet keeps a specified number of identical Pods running. If a Pod dies, the ReplicaSet creates a replacement; if there are too many, it deletes extras. It's the object that actually delivers self-healing for a fixed count.

You rarely create ReplicaSets directly. A Deployment creates and manages them, spinning up a new ReplicaSet during a rolling update while scaling down the old one.

Labels are key-value tags you attach to objects, like app: web or env: prod. Selectors are queries that match objects by their labels. This is the loose coupling glue of Kubernetes: Services, Deployments, and network policies find their targets by selector, not by name.

Because matching is by label, you can add or remove Pods from a Service just by changing labels, with no reference to individual Pod names or IPs.

Both inject configuration into Pods so you don't bake config into images. A ConfigMap holds non-sensitive data like URLs and feature flags. A Secret holds sensitive data like passwords and tokens, and its values are base64 encoded.

Base64 is encoding, not encryption, so Secrets aren't secure by default. In production you enable encryption at rest for etcd and control access with RBAC. Both can be mounted as files or exposed as environment variables.

A VM virtualizes hardware and runs a full guest operating system, so it's heavier and slower to start. A container shares the host kernel and isolates just the process, so it's lightweight, starts in seconds, and packs more densely.

Kubernetes orchestrates containers, not VMs. This matters in interviews because it explains why containers are the unit: they're cheap to create and destroy, which is exactly what self-healing and autoscaling need.

The kubelet is the agent that runs on every worker node. It watches the API server for Pods assigned to its node, tells the container runtime to start them, and reports their status back. It also runs the liveness and readiness probes.

Think of it as the node's hands: the scheduler decides where a Pod goes, but the kubelet is what actually makes the containers run on that machine and keeps them alive.

The scheduler watches for Pods with no assigned node. For each one it filters nodes that can run the Pod (enough CPU and memory, matching node selectors, tolerating taints), then scores the survivors and picks the best. It writes the chosen node onto the Pod, and the kubelet there takes over.

You influence placement with resource requests, nodeSelector, affinity rules, and taints and tolerations. Without any hints, the scheduler spreads Pods to balance the cluster.

A fresh cluster ships with default (where your objects land if you don't pick one), kube-system (control plane and system components), kube-public (world-readable cluster info), and kube-node-lease (node heartbeat objects for faster failure detection).

You put your workloads in default only for quick tests. Real setups create their own namespaces per team or environment and leave kube-system alone.

Self-healing is Kubernetes automatically recovering from failures without a human. If a container crashes, the kubelet restarts it. If a Pod dies, its controller recreates it. If a node fails, its Pods get rescheduled elsewhere. If a probe says a container is unhealthy, Kubernetes acts on it.

This falls out of the control loop: controllers constantly compare desired state to actual state and fix the difference. Self-healing isn't a feature you turn on, it's how the system works.

Every object needs four top-level fields: apiVersion (which API group and version), kind (the object type like Pod or Service), metadata (at least a name), and spec (the desired state, whose shape depends on the kind).

Kubernetes reads spec as what you want and reports the current status back on the object. You write spec; the system fills in status.

Use a Deployment for stateless apps where Pods are interchangeable. Use a StatefulSet when each Pod needs a stable identity: a fixed name, stable network hostname, and its own persistent volume that follows it across restarts.

Databases, message brokers, and clustered systems that care which replica is which are StatefulSet territory. A StatefulSet also rolls out and scales Pods in order (0, 1, 2), which ordered systems rely on.

A DaemonSet runs one copy of a Pod on every node (or every node matching a selector). When nodes join the cluster, they automatically get the Pod; when they leave, the Pod goes with them.

It's the tool for per-node agents: log collectors, monitoring agents, and network plugins. You use a DaemonSet whenever the workload's job is tied to the node itself rather than to a replica count.

A Job runs a Pod to completion: it starts, does work, and succeeds when the work finishes, retrying on failure up to a limit. It's for batch tasks like a migration or a one-off computation.

A CronJob creates Jobs on a schedule, using cron syntax. It's for recurring work like nightly backups or hourly reports. So a CronJob is a Job with a timer.

A liveness probe checks if the container is still healthy; on failure Kubernetes restarts it. A readiness probe checks if the container can serve traffic; on failure the Pod is removed from Service endpoints but not restarted. A startup probe protects slow-starting apps by delaying the other two probes until the app has booted.

The classic mistake is using a liveness probe where you need a readiness probe, which causes needless restarts of a Pod that's just temporarily busy. Get this distinction right and you've answered a common gotcha.

A request is what a container is guaranteed and what the scheduler uses to place the Pod: a Pod only lands on a node with enough unrequested capacity. A limit is the ceiling the container can't exceed at runtime.

Exceeding a memory limit gets the container OOM-killed. Exceeding a CPU limit throttles it, it doesn't die. Setting requests too low overcommits nodes; setting limits too tight causes throttling and kills. Getting these right is core production tuning.

A rolling update replaces old Pods with new ones gradually so the app stays available. The Deployment brings up new Pods, waits for them to pass readiness, then removes old ones, repeating until the whole set is updated.

You tune it with maxUnavailable (how many Pods can be down during the rollout) and maxSurge (how many extra Pods can exist above the desired count). Readiness probes are what make it safe: without them, traffic hits Pods that aren't ready.

Use kubectl rollout undo, which returns the Deployment to its previous ReplicaSet. Because Kubernetes keeps the old ReplicaSet around (limited by revisionHistoryLimit), rollback is just scaling the old set back up and the new one down.

You can inspect history with kubectl rollout history and roll back to a specific revision. Pausing a rollout mid-flight with kubectl rollout pause is the other useful control when you spot trouble.

A Service exposes Pods at the network layer (L4): a stable IP and port. An Ingress works at the HTTP layer (L7): it routes external HTTP and HTTPS traffic to different Services based on hostname and path, and handles TLS termination.

An Ingress needs an Ingress controller (like NGINX or Traefik) actually running in the cluster to enforce the rules. Without a controller, an Ingress object does nothing. It lets many services share one external entry point instead of one LoadBalancer each.

A PersistentVolume (PV) is a piece of storage in the cluster. A PersistentVolumeClaim (PVC) is a Pod's request for storage of a given size and access mode. Kubernetes binds a claim to a matching volume, and the Pod mounts the claim.

A StorageClass automates the PV side: instead of an admin pre-creating volumes, the class provisions one dynamically when a claim asks for it. So the everyday flow is Pod to PVC to StorageClass to a freshly provisioned PV.

Kubernetes runs a DNS service (CoreDNS) that gives every Service a DNS name. A Service named web in namespace shop resolves at web.shop.svc.cluster.local, and from within the same namespace just web works.

This is why apps address each other by Service name instead of IP. Pods are configured to use CoreDNS automatically, so service discovery is built in with no extra tooling.

The Service controller keeps an Endpoints (or EndpointSlice) list of the IPs of Pods matching the selector and passing readiness. On each node, kube-proxy programs the kernel (iptables or IPVS rules) so that traffic to the Service's ClusterIP is redirected to one of those Pod IPs.

So there's no single proxy process the packets flow through by default; kube-proxy sets up rules and the kernel does the load-balancing. When a Pod becomes unready, it drops out of the endpoint list and stops receiving traffic.

A NetworkPolicy controls which Pods can talk to which, at the IP and port level. By default all Pods can reach all other Pods; a NetworkPolicy lets you restrict that, for example only letting the frontend reach the backend.

Policies select Pods by label and define allowed ingress and egress. One catch: they only take effect if your CNI network plugin supports them (Calico, Cilium do; some don't), so a policy on an unsupporting plugin silently does nothing.

Two main ways: as environment variables or as mounted files. You pull values from a ConfigMap or Secret using valueFrom for individual env vars, envFrom to load a whole ConfigMap, or a volume mount to expose the data as files.

Mounting as files has an edge: file-mounted ConfigMap changes propagate to the Pod without a restart, while env vars are fixed at container start. For secrets, file mounts are also generally safer than env vars.

Init containers run to completion before the app containers in a Pod start, one after another in order. If an init container fails, the Pod restarts it until it succeeds, so the main app never runs until preconditions are met.

Use them for setup work: waiting for a database to be reachable, running a schema migration, or fetching config into a shared volume. They keep that logic out of your app image.

The Horizontal Pod Autoscaler (HPA) automatically changes the number of Pod replicas based on observed metrics, most commonly CPU or memory usage, or custom metrics. When load rises past a target, it adds Pods; when load drops, it removes them.

It needs resource requests set (so it has a baseline to measure against) and a metrics source like the metrics-server. HPA scales Pod count; the Vertical Pod Autoscaler changes per-Pod resources instead.

A taint on a node repels Pods: by default no Pod will schedule there. A toleration on a Pod lets it ignore a matching taint and schedule anyway. Together they reserve nodes for specific workloads.

The classic use is dedicated hardware: taint the GPU nodes so only Pods that tolerate the taint (the ones that actually need GPUs) land there. Taints and tolerations repel; node affinity attracts. You often use them together.

Node affinity attracts Pods to nodes with certain labels, like scheduling only on nodes in a specific zone or with SSDs. Pod affinity and anti-affinity place Pods relative to other Pods: affinity co-locates them, anti-affinity spreads them apart.

Anti-affinity is how you keep replicas of a Deployment on different nodes so a single node failure doesn't take them all down. Rules come in two strengths: required (hard) and preferred (soft, best effort).

kubectl get pods to read the status, then kubectl describe pod for events (scheduling failures, image pull errors, probe failures show up here), then kubectl logs for what the app printed comes first. For a shell inside a running container, kubectl exec.

The status tells you which direction to look: Pending means a scheduling problem, ImagePullBackOff means a bad image or registry auth, CrashLoopBackOff means the app keeps exiting, so read the logs. A methodical get, describe, logs, exec loop solves most issues.

CrashLoopBackOff means a container starts, then exits or fails, and the kubelet keeps restarting it with a growing back-off delay. It's a symptom, not a root cause. Common causes: the app crashes on a config or dependency error, a failing liveness probe kills a healthy-but-slow app, a bad command, or a missing environment variable.

Diagnose with kubectl logs --previous to see the last crash, and kubectl describe pod for probe and exit-code details. Exit code 137 points at an OOM kill; a stack trace points at an app bug; a connection error points at a missing dependency.

Helm is a package manager for Kubernetes. A Helm chart bundles the templated YAML for an app, and you install it with one command, passing values to customize each environment. It turns dozens of manifests into a single versioned, parameterized package.

It solves two real problems: reuse (install the same charted app across environments with different values) and lifecycle (upgrade and roll back releases as units). The trade-off is another templating layer to learn and debug.

A ResourceQuota caps the total resources (CPU, memory, object counts) a namespace can consume, so one team can't starve the cluster. A LimitRange sets default and maximum requests and limits per Pod or container in a namespace.

Used together, a LimitRange gives every Pod sane defaults while the ResourceQuota enforces a hard ceiling on the namespace as a whole. This is standard multi-tenant hygiene.

Every controller runs the same loop: watch the API server for a resource's desired state, compare it to observed state, and take actions to close the gap, then repeat forever. The Deployment controller, the scheduler, the kubelet, and custom operators all follow this pattern.

This is why Kubernetes is level-triggered, not edge-triggered: it reacts to the current state, not to a one-time event, so a missed event or a controller restart doesn't break anything. The controller just re-reads state and reconciles again. That property is what makes the system self-correcting.

etcd is the cluster's datastore: a distributed key-value store holding all cluster state (every object, spec, and status). The API server is the only component that talks to it directly. If etcd is lost, the cluster's state is lost.

Operational concerns: run an odd number of members (3 or 5) for quorum, back it up regularly because it's the single source of truth, watch its disk latency because slow etcd slows the whole API, and encrypt Secrets at rest since etcd stores them.

kubectl sends the manifest to the API server. The request passes through authentication (who are you), authorization (RBAC: are you allowed), and admission control (mutating webhooks that alter the object, then validating webhooks and quota checks). If it passes, the API server persists the object to etcd and returns success.

From there it's asynchronous: controllers watching that resource notice the change and reconcile. For a Deployment, the Deployment controller makes a ReplicaSet, which makes Pods, the scheduler assigns nodes, and kubelets start containers. apply returns before any of that finishes.

RBAC grants permissions through roles and bindings. A Role (namespaced) or ClusterRole (cluster-wide) lists allowed verbs (get, list, create) on resources. A RoleBinding or ClusterRoleBinding attaches that role to a subject: a user, group, or ServiceAccount.

Permissions are additive and default-deny: if no rule allows an action, it's denied. The everyday production use is giving each app a ServiceAccount with the least privilege it needs, rather than running Pods with broad cluster access.

A CustomResourceDefinition (CRD) extends the Kubernetes API with your own object type, so kubectl get postgres works just like kubectl get pods. An operator is a custom controller that watches those custom resources and runs the same reconciliation loop to manage a real system.

The operator pattern encodes operational knowledge as code: an operator for a database can handle provisioning, backups, failover, and upgrades by reacting to the custom resource's desired state. It's how you teach Kubernetes to run complex stateful software.

Set a securityContext: run as a non-root user, drop all Linux capabilities and add back only what's needed, make the root filesystem read-only, and disallow privilege escalation. At the namespace level, Pod Security Admission enforces baseline or restricted profiles to reject unsafe Pods.

PodSecurityPolicy is gone (removed in 1.25); the current answer is Pod Security Admission plus, for finer control, a policy engine like OPA Gatekeeper or Kyverno. Naming that the old PSP is deprecated shows current knowledge.

Every Pod runs as a ServiceAccount (the default one unless you specify another). Kubernetes mounts a short-lived, automatically rotated token into the Pod, and the app or a client library uses it to call the API server, where RBAC decides what it can do.

Two hardening points: give each workload its own ServiceAccount with least-privilege RBAC rather than the default, and set automountServiceAccountToken: false on Pods that never call the API, so they don't carry a credential they don't need.

The HPA scales the number of Pods based on load. The Cluster Autoscaler scales the number of nodes: when Pods can't be scheduled because the cluster is out of capacity, it adds nodes; when nodes sit underused, it drains and removes them.

They work together: HPA adds Pods, those Pods go Pending because there's no room, and the Cluster Autoscaler notices and adds a node. Knowing they operate at different layers (Pods vs nodes) is the point of the question.

Blue-green runs two full environments (old and new) and flips a Service selector or Ingress from blue to new all at once, with instant rollback by flipping back. Canary sends a small slice of traffic to the new version first, watches metrics, then ramps up if healthy.

Plain Kubernetes can approximate both by juggling labels, Services, and replica counts, but the honest coverage names the real tools: a service mesh (Istio, Linkerd) for percentage-based traffic splitting, or a progressive-delivery controller like Argo Rollouts or Flagger that automates the canary and its rollback.

Reasons to split: hard isolation between environments or tenants, blast-radius reduction (a bad change can't take everything down), regulatory or data-residency boundaries, and staying under a single cluster's scaling limits. Reasons to stay single: lower operational overhead and simpler networking and cost.

The trade-off is complexity: multiple clusters mean multi-cluster deployment tooling, cross-cluster networking, and consistent policy everywhere. The production-ready answer weighs isolation and blast radius against that operational cost, rather than reflexively picking one.

When a node stops reporting, it's marked NotReady. After a grace period, the node controller evicts its Pods, and controllers reschedule the ones they own onto healthy nodes. Pods that belong to no controller (bare Pods) are just lost.

Response: check whether it's the kubelet, the network, or the machine itself (kubectl describe node, then the node's own logs). If the node won't recover, cordon it so nothing new schedules there, drain it to move workloads off gracefully, and replace it. This is where PodDisruptionBudgets matter, so draining doesn't take too many replicas down at once.

A PodDisruptionBudget (PDB) limits how many Pods of an app can be voluntarily disrupted at once, for example during a node drain or cluster upgrade. You set minAvailable or maxUnavailable, and voluntary evictions respect it.

It matters for availability during maintenance: without a PDB, draining several nodes could evict every replica of a service simultaneously. A PDB tells Kubernetes to keep enough replicas running so the drain proceeds gradually. It only guards voluntary disruptions, not a node crashing.

Base64 in a Secret object is not enough. Enable encryption at rest so etcd doesn't store plaintext, lock down access with RBAC, and prefer mounting secrets as files over environment variables. Never commit secrets to Git; if you use GitOps, encrypt them first with a tool like Sealed Secrets or SOPS.

For stronger setups, pull secrets from an external manager (Vault, a cloud secret store) via the External Secrets Operator or CSI driver, so the source of truth lives outside the cluster and rotation is centralized.

Three pillars: metrics (Prometheus scraping cluster and app metrics, Grafana for dashboards), logs (a collector like Fluent Bit shipping container logs to a backend), and traces (OpenTelemetry into a tracing backend). The metrics-server is a lighter piece that just feeds the HPA and kubectl top.

What to actually watch: Pod restart counts and CrashLoopBackOff, node resource pressure, pending Pods (a scheduling or capacity signal), and per-service latency and error rates. Alerting on those catches most problems before users do.

GitOps makes a Git repository the source of truth for cluster state. A controller in the cluster (Argo CD or Flux) continuously compares the live cluster to the manifests in Git and reconciles any drift, so deployments happen by merging a pull request, not by running kubectl.

The wins: every change is reviewed and audited in Git, rollback is a git revert, and the cluster self-heals back to the declared state if someone changes it manually. It's the reconciliation model extended from inside the cluster out to your source control.

An OOMKill means a container hit its memory limit and the kernel killed it; you'll see exit code 137 and OOMKilled in the Pod's last state. First confirm it's the limit and not the whole node running out of memory, which evicts Pods differently.

Fix by measuring real usage (kubectl top pod, or historical metrics) and setting the memory limit above the true working set with headroom, or fixing an actual leak in the app. Setting limits from guesses is the usual root cause: too low and you OOMKill healthy apps, too high and you overcommit the node.

Upgrade the control plane first, then nodes, one minor version at a time (you can't skip minors). Check the release notes for deprecated and removed APIs, and scan your manifests for anything that will break before upgrading. Back up etcd first.

For nodes, roll through them: cordon and drain one, upgrade the kubelet, uncordon, and move on, respecting PodDisruptionBudgets so services stay available. Managed offerings (GKE, EKS, AKS) automate much of this but the same order and the API-deprecation check still apply.

The model has flat rules: every Pod gets its own IP, every Pod can reach every other Pod without NAT, and nodes can reach all Pods. Kubernetes itself doesn't implement this; it delegates to a CNI plugin (Calico, Cilium, Flannel) that wires up Pod networking on each node.

The CNI choice affects real features: some plugins enforce NetworkPolicies and some don't, and options like Cilium use eBPF for performance and observability. So 'which CNI' is an architecture decision, not a detail, because it decides what network security you can even enforce.

The hard parts are storage and identity: data must survive Pod rescheduling (persistent volumes bound correctly), each replica needs a stable identity (StatefulSets), and failover and backups must be orchestrated. Storage performance and the fact that a volume is usually tied to one zone add scheduling constraints.

The practical answer: use a purpose-built operator that encodes the database's operational knowledge (failover, backup, restore) rather than hand-rolling StatefulSets, and honestly weigh whether a managed database outside the cluster is the better call. Senior candidates name that trade-off instead of assuming everything belongs in Kubernetes.

Clarify the isolation requirement first (soft multi-tenancy between trusted internal teams vs hard isolation for untrusted tenants), because that decides whether one cluster is even acceptable. For internal teams, a namespace per team is the backbone.

Then layer the controls: ResourceQuotas and LimitRanges so no team starves the cluster, RBAC scoped per namespace, NetworkPolicies to stop cross-team traffic by default, Pod Security Admission for a safe baseline, and separate node pools with taints for noisy or sensitive workloads. If isolation must be hard, the honest answer is separate clusters, because namespaces share a kernel and a control plane.