Kubernetes Interview Questions and Answers (2026)

Kubernetes is a container orchestrator. You declare the desired state — "run three replicas of this image, expose it on port 80" — and controllers continuously reconcile the cluster toward that state: scheduling containers onto nodes, restarting failed ones, rolling out new versions and scaling. The key idea is declarative configuration plus a control loop, not a script that runs once.

Control plane: the API server (the only component everything talks to), etcd (the key-value store holding cluster state), the scheduler (assigns Pods to nodes) and the controller manager (runs the reconcile loops). Each node runs the kubelet (starts and monitors containers for Pods assigned to it), a container runtime such as containerd, and kube-proxy (or an equivalent) for Service networking.

A Pod is one or more containers that share a network namespace (one IP, shared localhost) and can share volumes. They are scheduled together and live and die together. Multi-container Pods are for tightly coupled helpers — a log shipper or a proxy sidecar — not for putting your whole application in one Pod.

A ReplicaSet keeps N identical Pods running; you rarely create one directly. A Deployment manages ReplicaSets to give you rolling updates and rollbacks for stateless apps. A StatefulSet gives Pods stable names, stable storage and ordered startup — for databases and clustered systems. A DaemonSet runs one Pod per node (log agents, node monitoring). A Job runs to completion; a CronJob runs Jobs on a schedule.

The Deployment creates a new ReplicaSet and gradually scales it up while scaling the old one down, bounded by maxSurge and maxUnavailable. If readiness probes fail, the rollout stalls rather than taking down healthy Pods. Roll back with kubectl rollout undo deployment/<name>; check progress with kubectl rollout status and history with kubectl rollout history.

ClusterIP (default) gives a stable virtual IP reachable only inside the cluster. NodePort additionally opens a port on every node. LoadBalancer provisions a cloud load balancer in front of it. ExternalName returns a DNS CNAME to an external host. A headless Service (clusterIP: None) skips the virtual IP and returns the Pod IPs directly — used with StatefulSets.

Through a label selector. The Service watches for Pods whose labels match and maintains an EndpointSlice of their ready IPs. Only Pods passing their readiness probe are included — which is why a wrong selector or failing readiness probe shows up as "Service has no endpoints".

A Service is L4 load balancing to a set of Pods. An Ingress is L7 routing — host and path rules, TLS termination — implemented by an ingress controller such as NGINX or a cloud-provided one; the Ingress resource alone does nothing without a controller installed. The newer Gateway API is the more expressive successor and is increasingly the recommended choice for new clusters.

Cluster DNS (CoreDNS). A Service payments in namespace shop resolves as payments.shop.svc.cluster.local, and just payments from within the same namespace.

By default every Pod can talk to every other Pod. A NetworkPolicy restricts ingress and/or egress for selected Pods. Once a Pod is selected by any policy, only traffic explicitly allowed is permitted. It requires a CNI plugin that enforces policies — Calico and Cilium do; some basic ones do not.

Both inject configuration as environment variables or mounted files. A Secret is intended for sensitive values, but by default it is only base64-encoded, not encrypted — enable encryption at rest for etcd, restrict access with RBAC, and consider an external secrets manager (Vault, AWS Secrets Manager via the External Secrets Operator) for anything serious.

Mounted files are eventually updated when the ConfigMap changes (unless mounted with subPath); environment variables are fixed at container start, so you need a Pod restart. Many teams add a config checksum annotation to the Pod template so a config change triggers a rollout.

A PV is a piece of storage in the cluster. A PVC is a Pod's request for storage of a given size and access mode. A StorageClass defines how storage is dynamically provisioned (for example an EBS gp3 volume), so a PVC creates its PV on demand. Remember ReadWriteOnce volumes attach to one node at a time, which affects how you schedule and scale.

Readiness decides whether the Pod receives traffic — failing removes it from Service endpoints. Liveness decides whether the container should be restarted — failing kills it. Startup holds off the other two for slow-starting apps. A classic mistake is a liveness probe that depends on a database: when the DB blips, every Pod restarts and turns a small outage into a big one.

A request is what the scheduler reserves for the container; a limit is the ceiling. Exceeding a memory limit gets the container OOM-killed; exceeding a CPU limit gets it throttled. Requests also determine QoS class — Guaranteed (requests = limits), Burstable, BestEffort — and BestEffort Pods are evicted first under node pressure.

The Horizontal Pod Autoscaler changes replica count based on metrics (CPU, memory, custom). The Vertical Pod Autoscaler adjusts requests. The Cluster Autoscaler (or Karpenter on AWS) adds and removes nodes when Pods can't be scheduled or nodes sit empty. HPA needs resource requests set, otherwise percentage-based CPU scaling has nothing to compare against.

A taint on a node repels Pods; a toleration on a Pod lets it ignore that taint. Node affinity attracts Pods to nodes with certain labels. Pod anti-affinity and topology spread constraints spread replicas across nodes or zones so one failure doesn't take out the whole service.

It limits how many Pods of an app can be voluntarily evicted at once (during node drains and upgrades), for example "keep at least 2 available". It does not protect against involuntary failures like a node crash.

Permissions are granted through Roles (namespaced) or ClusterRoles (cluster-wide) that list verbs on resources, attached to users, groups or ServiceAccounts through RoleBindings / ClusterRoleBindings. Follow least privilege, give each workload its own ServiceAccount, and avoid binding cluster-admin casually. kubectl auth can-i is the quick way to check.

Run as non-root, drop Linux capabilities, set a read-only root filesystem, disable privilege escalation, use the Pod Security Standards (restricted profile) via Pod Security Admission, pin image digests, and scan images in CI.

kubectl describe pod for events and the last state / exit code, then kubectl logs <pod> --previous to see why the *previous* container died. Common causes: application error or missing config, wrong command, failing liveness probe, or OOMKilled (exit code 137 with reason OOMKilled) from a too-low memory limit.

The scheduler can't place it. kubectl describe pod shows why: insufficient CPU or memory, unsatisfied node selector/affinity, untolerated taints, or an unbound PVC. Fix the constraint or add capacity.

Wrong image name or tag, a private registry without an imagePullSecret, or network/registry rate limiting. The event message in describe usually names which.

Check kubectl get endpoints <svc> — empty means the selector doesn't match Pod labels or Pods aren't Ready. Then verify targetPort matches the container port, test from inside the cluster with a temporary debug Pod (kubectl run -it --rm debug --image=busybox), then check NetworkPolicies and, for external traffic, the Ingress and controller logs.

After the grace period the control plane marks the node's Pods for eviction and controllers recreate them elsewhere (StatefulSet Pods more carefully, to avoid two copies running). You investigate the kubelet, disk and memory pressure, and connectivity on the node itself.

Be solid on Pods, Deployments, Services, Ingress, ConfigMaps/Secrets, probes, requests/limits and basic troubleshooting. For senior roles add RBAC, networking (CNI, NetworkPolicy), autoscaling, upgrades and a GitOps or Helm workflow.

They are respected and hands-on (practical exams, not multiple choice), so they signal real skill. CKA suits platform and DevOps roles; CKAD suits application developers. Hands-on experience still matters more in interviews than the certificate.

Often, yes. Know that Helm packages manifests as charts with templated values, supports releases and rollbacks, and be ready to explain values.yaml overrides — along with its trade-offs against Kustomize.

Yes — that is what online IT job support is for. You work through real issues in your own environment with an experienced engineer, with the aim of you understanding and owning the solution.