Top 20 Kubernetes Interview Questions and Answers (2026 Guide)

Container orchestration with Kubernetes (K8s) is the industry-standard foundation for running scalable, distributed applications across cloud and on-premise environments. In technical screens for DevOps engineers, site reliability engineers (SREs), and platform architects, hiring panels evaluate both conceptual architectural mastery and hands-on triage instincts.

In this guide, building on our Docker interview questions and FastAPI interview questions, we review the top 20 Kubernetes interview questions, dissecting control plane components, workload controllers, networking primitives, and real-world troubleshooting workflows with executable kubectl commands.

Mastering Kubernetes Interview Questions: What Hiring Teams Look For

Hiring teams assess three primary competencies:

1. System Architecture Intuition: Understanding how declarative configuration reconciles current state against desired state via control loops.
2. Networking & Ingress Mechanics: Knowing how packets flow from an external user request down to a container port.
3. Production Triage Experience: Quickly resolving production incidents like node evictions, resource limits, and probe failures.

Pillar 1: Kubernetes Architecture Interview Questions

Question 1: What are the primary components of the Kubernetes Control Plane?

Answer: The control plane makes global decisions about the cluster (such as scheduling) and detects/responds to cluster events:

• kube-apiserver: The central REST gateway and front end for the control plane; validates and configures data for pods, services, and replication controllers.
• etcd: Consistent and highly-available distributed key-value store used as Kubernetes' backing store for all cluster state data.
• kube-scheduler: Watches for newly created Pods with no assigned node, and selects a worker node for them based on resource requests, hardware constraints, and affinity/anti-affinity specifications.
• kube-controller-manager: Runs daemon controller loops that regulate the state of the cluster (Node Controller, Job Controller, EndpointSlice Controller, ServiceAccount Controller).
• cloud-controller-manager: Integrates cluster logic with underlying cloud provider APIs (load balancers, storage volumes).

Question 2: What are the components running on each Worker Node?

Answer: Each worker node maintains runtime environments for pods:

• kubelet: An agent that registers nodes with the API server, ensures containers described in PodSpecs are running and healthy, and reports node status.
• kube-proxy: Network proxy that maintains network rules on nodes using iptables or IPVS to enable network communication to Pods from inside or outside the cluster.
• Container Runtime: Software responsible for running containers (e.g., containerd, CRI-O).

Question 3: How does etcd maintain data consistency across distributed control nodes?

Answer: etcd implements the Raft consensus algorithm to achieve distributed consensus. Raft ensures that a cluster of $2N+1$ nodes can tolerate up to $N$ node failures while maintaining strong consistency (linearizable reads and writes). A write is committed only after a quorum of nodes ($> 50%$) has acknowledged appending the entry to their write-ahead log.

Pillar 2: Pods, Workloads & Controllers

Question 4: Deployment vs StatefulSet vs DaemonSet: When do you use each?

Question 5: What is the difference between Liveness, Readiness, and Startup Probes?

Answer:

• Liveness Probe: Determines if a container needs to be restarted. If it fails, kubelet terminates the container and initiates a restart based on the restartPolicy.
• Readiness Probe: Determines if a container is ready to accept incoming network traffic. If it fails, the endpoints controller removes the Pod's IP from all matching Service endpoints so traffic bypasses it.
• Startup Probe: Protects slow-starting legacy applications. It disables liveness and readiness checks until the container has finished its initial startup sequence.

# Pod Spec with probes
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Pillar 3: Networking & Services Kubernetes Interview Questions

Question 6: Explain the difference between ClusterIP, NodePort, LoadBalancer, and Ingress.

Question 7: What is the CNI (Container Network Interface)?

Answer: The CNI is a standardized specification and set of plugins that configures network interfaces for Linux containers. Popular CNI providers (Calico, Cilium, Flannel, Weave Net) assign unique cluster-routable IP addresses to each Pod, enforce NetworkPolicies (firewalls), and implement overlay networks (VXLAN/Geneve) or BGP direct routing.

Pillar 4: Production Troubleshooting & Operations

Question 8: How do you diagnose and resolve a Pod stuck in CrashLoopBackOff?

Answer: Execute the standard 4-step debugging sequence:

1. Inspect Pod Status and Exit Code:

   bash

   Copy code

   kubectl describe pod <pod-name> -n <namespace>

   Look for Last State: Terminated with Exit Code: 137 (OOMKilled) or Exit Code: 1 (application crash).
2. Review Container Logs:

   bash

   Copy code

   kubectl logs <pod-name> --previous -n <namespace>

   Adding --previous retrieves the standard output from the crashed container before restart.
3. Validate ConfigMaps & Secrets: Ensure environment variables, database connection strings, and mounted volume permissions are valid.
4. Interactive Shell: If the container can stay alive, debug live:

   bash

   Copy code

   kubectl exec -it <pod-name> -- /bin/sh

Question 9: What is the difference between Resource Requests and Limits?

Answer:

• Requests: The minimum guaranteed amount of CPU (e.g., 250m) and Memory (e.g., 512Mi) the pod requires. kube-scheduler uses requests to decide which node has enough capacity to host the pod.
• Limits: The maximum hard ceiling of resources a container can consume.
  • CPU Limit Exceeded: The Linux kernel CFS (Completely Fair Scheduler) throttles the container's CPU usage, causing latency spikes.
  • Memory Limit Exceeded: The container is terminated immediately by the Linux kernel Out-Of-Memory killer (OOMKilled, Exit Code 137).

Check our guide on Docker Interview Questions for foundational container concepts and REST API Interview Questions for API service networking.

Question 10: How does the Kubernetes Horizontal Pod Autoscaler (HPA) scale workloads?

Answer: The Horizontal Pod Autoscaler (HPA) automatically adjusts the number of Pod replicas in a Deployment or StatefulSet based on observed CPU/memory utilization or custom metrics:

1. Metrics Pipeline: The cluster Metrics Server periodically scrapes resource telemetry from kubelet's cAdvisor endpoints.
2. Scaling Calculation Algorithm: Desired Replicas = ⌈ Current Replicas × (Current Metric Value / Target Metric Value) ⌉ For example, if current CPU utilization is 80% and the target is 50% across 5 running pods: ⌈ 5 × (80 / 50) ⌉ = ⌈ 8.0 ⌉ = 8 replicas.
3. Custom & External Metrics: Using KEDA (Kubernetes Event-driven Autoscaling) or the Prometheus Adapter, HPA can scale based on SQS queue depth, Kafka consumer group lag, or active HTTP connection counts.
4. Stabilization Window: HPA enforces cooldown periods (default 5 minutes for scale-down) to prevent flapping (thrashing) when metric bursts fluctuate rapidly.

Question 11: What are ConfigMaps and Secrets, and how are they safely injected into Pods?

Answer: ConfigMaps and Secrets decouple configuration artifacts and credentials from container images, supporting twelve-factor application architecture:

• ConfigMaps: Store non-confidential configuration (e.g., database hostnames, feature flags, logging levels) as plain-text key-value pairs or configuration files.
• Secrets: Store sensitive data (e.g., passwords, TLS certificates, OAuth tokens, API keys). In etcd, Secrets should be encrypted at rest using KMS envelope encryption.
• Injection Mechanisms:
  1. Environment Variables: envFrom or valueFrom.configMapKeyRef. Fast to parse, but does not update dynamically when the ConfigMap/Secret changes without a pod restart.
  2. Volume Mounts: Injected as files inside a mounted directory (e.g., /etc/config/app.conf). Volume-mounted ConfigMaps update atomically within seconds when modified in the API server without restarting the application.
  3. Security Caution: Environment variables can be leaked via error logs or crash dumps; volume mounts are generally preferred for production credentials.

Question 12: Explain the architecture of Kubernetes Storage: PV, PVC, and StorageClass.

Answer: Kubernetes storage architecture decouples infrastructure provisioning from application deployment:

1. StorageClass: Defines the provisioner (e.g., AWS EBS CSI, GCP Persistent Disk, Azure Disk, Ceph) and storage parameters (IOPS, volume type, reclaim policy Delete or Retain). It enables Dynamic Provisioning without requiring manual disk pre-allocation.
2. PersistentVolume (PV): A cluster-scoped storage resource provisioned by an administrator or dynamically created by a StorageClass. It represents the physical block storage or network file share.
3. PersistentVolumeClaim (PVC): A namespace-scoped request for storage by a developer or workload (e.g., "I need 50Gi of ReadWriteOnce SSD storage").
4. Binding Phase: The Kubernetes control plane matches the PVC request to a matching PV or triggers the StorageClass CSI driver to provision a new physical disk and bind it.
5. Access Modes:
   • ReadWriteOnce (RWO): Mounted as read-write by a single node.
   • ReadOnlyMany (ROX): Mounted read-only by many nodes.
   • ReadWriteMany (RWX): Mounted read-write by many nodes simultaneously (e.g., NFS, AWS EFS).

Question 13: How does Kubernetes RBAC (Role-Based Access Control) work?

Answer: Kubernetes RBAC enforces fine-grained authorization for human users and automated ServiceAccounts:

• Roles vs ClusterRoles:
  • Role: Grants permissions within a single specific namespace (e.g., create pods, read configmaps in staging).
  • ClusterRole: Grants cluster-wide permissions (e.g., read nodes, manage persistent volumes) or non-namespaced resource access (e.g., /healthz).
• RoleBindings vs ClusterRoleBindings:
  • RoleBinding: Binds a Role or ClusterRole to a Subject (User, Group, or ServiceAccount) within a single namespace.
  • ClusterRoleBinding: Binds a ClusterRole to a Subject across the entire cluster.
• Rule Syntax:

  yaml

  Copy code

  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
    namespace: analytics
    name: pod-reader
  rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]

Question 14: What is a PodDisruptionBudget (PDB) and why is it critical during node maintenance?

Answer: A PodDisruptionBudget (PDB) limits the number of replicated pods that can be voluntarily taken down simultaneously during voluntary disruptions:

• Voluntary vs Involuntary Disruptions:
  • Involuntary: Hardware failure, kernel panic, hypervisor crash (PDB cannot prevent these).
  • Voluntary: Administrator draining a node for AMI patching (kubectl drain node-1), cluster autoscaler scaling down underutilized nodes, or deployment updates.
• Configuration:

  yaml

  Copy code

  apiVersion: policy/v1
  kind: PodDisruptionBudget
  metadata:
    name: api-pdb
  spec:
    minAvailable: 2  # or maxUnavailable: 1
    selector:
      matchLabels:
        app: api-gateway

• Operational Impact: When kubectl drain runs, the eviction API checks the PDB. If evicting a pod would violate minAvailable: 2, the eviction is blocked until replacements are healthy on other nodes, preventing customer-facing outages.

Question 15: How does kube-proxy handle network routing, and what is the difference between iptables and IPVS mode?

Answer: kube-proxy runs on every node to implement Kubernetes Service virtual IP (ClusterIP) abstractions:

• iptables Mode: Generates netfilter packet filtering rules for every service and endpoint. Incoming packets are NAT-rewritten using random probability selection.
  • Limitation: Rules are evaluated sequentially in an $O(N)$ linear chain. In large clusters with 5,000+ services and 50,000+ endpoints, rule evaluation consumes severe CPU and routing latency degrades.
• IPVS (IP Virtual Server) Mode: Uses Linux Netfilter kernel-level transport-layer load balancing backed by $O(1)$ hash tables.
  • Advantages: Negligible CPU overhead at massive scale, supports advanced load balancing algorithms (least connection, weighted round-robin, locality-based), and handles millions of connections seamlessly.

Question 16: What is the purpose of Init Containers and how do they execute?

Answer: Init Containers are specialized containers that run to completion before application containers start in a Pod:

1. Sequential Execution: Init containers run sequentially in the order defined in spec.initContainers. Each init container must exit with code 0 before the next starts.
2. Blocking Behavior: If any init container fails, kubelet restarts the Pod until it succeeds (subject to restartPolicy).
3. Common Analyst & Engineering Use Cases:
   • Database Migration: Running Alembic, Flyway, or Liquibase migrations before launching API web servers.
   • Dependency Readiness: Polling a PostgreSQL database or Redis cluster using nc -z db 5432 until it accepts connections.
   • Configuration Rendering: Fetching secrets from HashiCorp Vault or AWS Secrets Manager and writing them to a shared emptyDir volume.

Question 17: How does a RollingUpdate Deployment work, and what do maxSurge and maxUnavailable mean?

Answer: A RollingUpdate replaces old pods with new ones progressively without zero-downtime:

• maxSurge: The maximum number of Pods that can be created above the desired replica count during the update (e.g., maxSurge: 25%).
• maxUnavailable: The maximum number of Pods that can be unavailable during the update process (e.g., maxUnavailable: 0 guarantees 100% available capacity).
• Update Workflow:
  1. Deployment creates a new ReplicaSet (v2).
  2. Spawns new pods according to maxSurge.
  3. Waits for new pods to pass their Readiness Probes.
  4. Once healthy, terminates old pods from ReplicaSet v1 while honoring maxUnavailable.
  5. Repeats until all traffic routes to v2.

Question 18: How do Taints and Tolerations differ from Node Affinity?

Answer:

• Taints & Tolerations: Taints are applied to Nodes to repel a set of pods unless the pod explicitly has a matching toleration:
  • Node Taint: kubectl taint nodes node-gpu dedicated=gpu:NoSchedule
  • Pod Toleration: Allows the pod to schedule onto the tainted node.
  • Primary purpose: Reserve specialized hardware (GPUs, high-memory nodes) or isolate tainted nodes during maintenance.
• Node Affinity: Defined in the Pod spec to attract pods to specific nodes based on node labels:
  • requiredDuringSchedulingIgnoredDuringExecution: Hard constraint (must match labels or pod remains Pending).
  • preferredDuringSchedulingIgnoredDuringExecution: Soft constraint (scheduler attempts to place pod on matching nodes, but falls back to others if unavailable).

Question 19: How do you systematically troubleshoot a Pod stuck in Pending status?

Answer: A Pod in Pending has been accepted by the API server but cannot be scheduled onto any worker node:

1. Inspect Events: Run kubectl describe pod <pod-name> and examine the Events table at the bottom.
2. Common Root Causes:
   • Insufficient Resources: No single node has sufficient available CPU or memory to satisfy the pod's resources.requests.
   • Taints / Tolerations: Pod lacks tolerations for nodes with NoSchedule taints.
   • Node Selectors / Affinity: Pod requires labels (e.g., topology.kubernetes.io/zone=us-east-1a) that do not match available nodes.
   • Unbound PVC: Pod references a PVC that has not been bound to a physical PV.
3. Remediation: Adjust resource requests, add worker nodes via Cluster Autoscaler, or resolve storage binding errors.

Question 20: What is a Kubernetes Service Mesh (e.g., Istio, Linkerd) and what problems does it solve?

Answer: A Service Mesh provides a dedicated infrastructure layer for handling service-to-service communication:

1. Sidecar Proxy Architecture: Injects a lightweight proxy (Envoy) into every application pod alongside the main container. All inbound and outbound traffic passes through the proxy.
2. Key Capabilities:
   • Zero-Trust Security (mTLS): Automatically encrypts and authenticates all microservice traffic with mutual TLS without altering application code.
   • Traffic Management: Supports canary releases (e.g., route 95% traffic to v1, 5% to v2), blue-green deployments, traffic mirroring (shadowing), and automatic retries/circuit breaking.
   • Observability & Distributed Tracing: Automatically records uniform latency percentiles (p50, p95, p99), error rates, and OpenTelemetry distributed trace headers across polyglot microservice fleets.

Summary Checklist for Kubernetes Interview Questions

• Explain the roles of API Server, etcd, Scheduler, and Controller Manager clearly.
• Understand the distinction between Liveness, Readiness, and Startup probes.
• Know how to debug CrashLoopBackOff, OOMKilled, and ImagePullBackOff.
• Compare ClusterIP, NodePort, LoadBalancer, and Ingress routing paths.
• Articulate the difference between resource requests and resource limits.

Related Interview Guides

• Python Tutorial: Complete Guide for Analysts
• Data Analyst Interview Questions (2026 Edition)
• Python Basic Interview Questions
• SQL Interview Questions & Answers
• Explore All Guides in the Interview Prep Hub