30 Kubernetes Interview Questions (2026 Edition) - With Answers

Kubernetes core components are split between control plane and worker nodes. Control plane: kube-apiserver (HTTP API gateway, validates and persists objects), etcd (consistent key-value store for cluster state), kube-scheduler (assigns pods to nodes), kube-controller-manager (runs controllers like Deployment, ReplicaSet, Node), cloud-controller-manager (cloud-provider-specific controllers). Worker nodes: kubelet (node agent ensuring pods run), kube-proxy (network proxy implementing Service load balancing via iptables or IPVS), container runtime (containerd or CRI-O - Docker removed in 1.24). Understanding where state lives (etcd) vs where logic runs (controllers) is critical for troubleshooting.

Three scaling mechanisms: Horizontal Pod Autoscaler (HPA) scales pod replicas based on CPU, memory, or custom metrics; Vertical Pod Autoscaler (VPA) adjusts pod resource requests/limits based on historical usage; Cluster Autoscaler or Karpenter provisions new nodes when pods can't schedule. For custom scaling (pending queue depth, Kafka lag, LLM inference requests), use KEDA (Kubernetes Event-Driven Autoscaler) which triggers HPA on 60+ external event sources. For production in 2026: Karpenter for node provisioning + KEDA for workload-specific scaling signals + HPA for baseline CPU/memory is the typical stack.

Deployments manage stateless pods - replicas are interchangeable, pods can be created/destroyed in any order, identities don't persist. Use for web services, APIs, most microservices. StatefulSets manage stateful pods with stable identities - ordered startup/shutdown (pod-0 before pod-1 before pod-2), persistent hostnames matching pod ordinals, stable storage via PersistentVolumeClaim templates. Use for databases, Kafka, ZooKeeper, Elasticsearch. Key rule: if your app needs consistent hostnames or ordered operations, use StatefulSet; otherwise Deployment.

Control plane HA: run multiple API servers behind a load balancer, etcd cluster of 3 or 5 nodes across availability zones, multiple controller-manager and scheduler instances (active-standby via leader election). Workload HA: pod disruption budgets to limit simultaneous evictions, topology spread constraints to distribute pods across zones, anti-affinity rules to keep replicas apart, readiness probes to route traffic only to healthy pods. For managed Kubernetes (EKS, AKS, GKE), the cloud provider handles control plane HA - focus on workload-level HA. For self-managed, also manage control plane HA via kubeadm or kops topology.

Each pod gets a unique cluster-wide IP (flat network, no NAT between pods). All containers in a pod share the IP and network namespace. Pod-to-pod communication is direct via IP; Kubernetes Services provide stable endpoints (ClusterIP, NodePort, LoadBalancer) with virtual IPs load-balanced by kube-proxy (iptables or IPVS) or eBPF (Cilium). CoreDNS resolves Service names to IPs. Network policies (via Calico, Cilium, or native) enforce pod-to-pod allow-lists. For 2026 clusters, Cilium with eBPF is increasingly the default CNI for performance and observability; Calico remains popular for policy depth.

Kubernetes abstracts storage via PersistentVolume (PV - cluster-level storage resource) and PersistentVolumeClaim (PVC - namespace-level request for storage). StorageClass defines dynamic provisioning templates (e.g., EBS gp3, Azure Premium SSD, NFS). CSI (Container Storage Interface) drivers handle cloud-specific provisioning. For stateful workloads, use StatefulSets with volumeClaimTemplates for per-pod stable storage. Key considerations: access modes (RWO/ROX/RWX), reclaim policy (Delete/Retain), performance tier selection, snapshot and backup strategy. For production databases, often bypass Kubernetes storage and use managed cloud databases.

Deployments orchestrate rolling updates by default: kubectl set image triggers a new ReplicaSet, old pods drain gradually while new pods come up subject to maxSurge and maxUnavailable settings (default 25% each). Readiness probes gate traffic to new pods. Rollback via kubectl rollout undo which promotes the previous ReplicaSet. For zero-downtime guarantees, pair with PodDisruptionBudget. For more advanced patterns (canary, blue-green, traffic splitting by percentage), use Argo Rollouts or Flagger - both integrate with service mesh (Istio, Linkerd) for fine-grained traffic control. See our GitOps comparison for progressive delivery patterns.

Systematic approach: (1) kubectl get pods to see status; Pending means unscheduled, CrashLoopBackOff means container crashing, ImagePullBackOff means image registry issue, (2) kubectl describe pod to see events, (3) kubectl logs for container output (use --previous for crashed containers), (4) kubectl exec into pod for interactive debugging, (5) kubectl get events --sort-by=.metadata.creationTimestamp for cluster-wide events. For deeper issues: check node conditions, resource pressure, scheduling predicates, NetworkPolicy impact. Observability stack (Prometheus, Grafana, Loki, Tempo) makes ongoing troubleshooting much faster than kubectl alone. See our observability platforms guide.

Native Kubernetes Secrets are base64-encoded (not encrypted) by default - insufficient for production. Proper approaches: (1) enable etcd encryption at rest with customer-managed KMS keys, (2) use External Secrets Operator to sync from HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager, (3) use Sealed Secrets for GitOps-friendly encrypted storage in Git, (4) integrate workload identity (IRSA, Workload Identity, Azure AD Workload Identity) to eliminate long-lived secrets entirely. For CBUAE-regulated UAE workloads, External Secrets + Vault with UAE-resident infrastructure + KMS encryption is the typical 2026 pattern.

Helm is the Kubernetes package manager. Helm charts are templated Kubernetes manifests with values.yaml parameterization, allowing the same chart to deploy across dev/staging/prod with different configurations. Use Helm for packaging your applications, installing third-party charts (from Bitnami, Artifact Hub, etc.), and managing release lifecycle (install, upgrade, rollback). Alternative: Kustomize (Kubernetes-native, no templating, just overlays). 2026 trend: many teams use Helm for third-party charts and Kustomize for in-house applications. For GitOps, both work - ArgoCD and Flux support both.

kubelet is the node agent that communicates with the API server to receive pod specifications and ensures those pods are running on the node - it manages container lifecycle via the container runtime (containerd, CRI-O), runs liveness and readiness probes, and reports node and pod status. kube-proxy is the network proxy that implements Kubernetes Service abstraction - it watches Service and Endpoints objects and programs iptables or IPVS rules (or eBPF with Cilium replacing kube-proxy entirely) to load-balance traffic to backend pods. kubelet handles pod lifecycle; kube-proxy handles service networking.

etcd is the distributed key-value store that holds all Kubernetes cluster state - every Deployment, Service, Secret, ConfigMap lives in etcd. Uses Raft consensus for strong consistency across 3 or 5 nodes. Matters because: (1) etcd performance is often cluster bottleneck at scale, (2) etcd backup/restore is your cluster disaster recovery strategy, (3) etcd encryption at rest is a compliance requirement for regulated workloads, (4) etcd version compatibility matters during Kubernetes upgrades. For managed Kubernetes (EKS, AKS, GKE), the provider operates etcd - you don't see it. For self-managed, operating etcd is one of the hardest parts of running Kubernetes.

Kubernetes scheduler (kube-scheduler) assigns pods to nodes through two phases: (1) Filtering - which nodes can run this pod (based on resource requests, node selectors, affinity, taints/tolerations, topology constraints), (2) Scoring - which filtered node is best (node resources, balanced resource allocation, image locality, spread across zones). Default scheduler handles most workloads. For specialized scheduling (batch ML training, GPU-aware scheduling, fair-share multi-tenancy), use Kueue, Volcano, or YuniKorn as secondary schedulers. Scheduler policy customization via scheduler configuration or scheduling profiles in newer Kubernetes versions.

CNI (Container Network Interface) is the standard for configuring pod networking. When a pod is created, kubelet calls the CNI plugin to set up the pod's network namespace, IP address, and routes. Common 2026 CNIs: Cilium (eBPF-based, highest performance, rich policy + service mesh + observability via Hubble), Calico (mature, strong network policies, BGP routing support), AWS VPC CNI (native pod IPs on AWS VPC), Azure CNI (native pod IPs on Azure VNet), Flannel (simple overlay, declining use). For 2026 new clusters, Cilium is increasingly the default for its combined CNI + network policy + service mesh + observability story. For AWS EKS, VPC CNI is often chosen for IP-per-pod simplicity.

RBAC (Role-Based Access Control) controls who can perform which actions on which resources. Four primary objects: Role (namespace-scoped permissions), ClusterRole (cluster-scoped permissions), RoleBinding (binds Role to User/Group/ServiceAccount in a namespace), ClusterRoleBinding (binds ClusterRole cluster-wide). Principle: grant minimum permissions needed. Common patterns: per-team RoleBindings for namespaces, service account RoleBindings for workloads, admin ClusterRoleBindings for cluster operators. Audit via kubectl auth can-i and kubectl describe rolebinding. For CBUAE regulated workloads, document RBAC model as part of access-control compliance evidence.

PodSecurityPolicy (PSP) was removed in Kubernetes 1.25. Replacement: Pod Security Admission (PSA), a built-in admission controller enforcing Pod Security Standards (Privileged / Baseline / Restricted) per-namespace via labels. Privileged: unrestricted (legacy workloads only). Baseline: prevents known privilege escalations while allowing common workloads. Restricted: hardened pod security (no privileged, non-root user, read-only root filesystem, specific capabilities only). Apply via namespace label pod-security.kubernetes.io/enforce=restricted. For stricter customization beyond the three standards, use Kyverno or OPA/Gatekeeper policies.

NetworkPolicy objects define allow-lists for pod-to-pod and namespace-to-namespace traffic. By default, all traffic is allowed - once you create a NetworkPolicy selecting a pod, the pod becomes isolated and only explicitly allowed traffic passes. Requires a CNI that enforces policies (Cilium, Calico, or some others). Best practice: deny-all default NetworkPolicy per namespace, then allow specific flows explicitly. For egress: deny-all egress, then allow DNS, allow internet for specific services, etc. For L7 (HTTP path-level) policy, use service mesh (Istio, Linkerd) or Cilium L7 policies. For CBUAE regulated clusters, document network segmentation as part of Article 13 compliance evidence.

Admission controllers intercept API server requests before they persist to etcd - they can validate (accept/reject) or mutate (modify) objects. Built-in admission controllers handle defaults and basic security. Custom admission via ValidatingAdmissionWebhook and MutatingAdmissionWebhook. OPA/Gatekeeper uses Rego policies for custom admission logic - powerful but Rego has a learning curve. Kyverno uses YAML-based policies - easier to write, similar capability for most use cases, CNCF-graduated. Both enforce policy-as-code at cluster entry: 'no images from untrusted registries', 'all pods must have resource limits', 'no root containers'. 2026 trend: Kyverno is increasingly the default over OPA/Gatekeeper for new deployments due to YAML accessibility.

Service exposes pods within the cluster (ClusterIP), to nodes (NodePort), or externally (LoadBalancer, provisioning cloud LB). Ingress is L7 HTTP routing - Ingress object + Ingress controller (nginx, traefik, HAProxy, Contour) routes requests by host/path to Services. Gateway API (newer, stable in 2023) is the evolution of Ingress - richer model with separate concerns: GatewayClass (who), Gateway (where/how), HTTPRoute/TLSRoute/TCPRoute (what). Use Gateway API for new clusters in 2026 - better designed, more capability, actively evolving. Nginx Ingress remains the default Ingress controller for legacy Ingress resources.

A service mesh provides mTLS between services, advanced traffic management (canary, retry, timeout), service-to-service observability, and policy enforcement - typically via sidecar proxies or node-level eBPF. For clusters with under 10 services and simple communication, native NetworkPolicies + Ingress + app-level TLS is enough. For 20+ services with compliance requirements (CBUAE Article 13 encryption-in-transit), multi-team clusters, complex traffic management, or need for service-to-service observability, deploy a service mesh. Options: Istio Ambient (feature-rich), Linkerd (operationally simple), Cilium Service Mesh (eBPF, best performance for Cilium clusters). See our service mesh comparison for detailed selection.

Systematic debugging: (1) kubectl logs pod-name --previous to see the crashed container's last output (most bugs are visible here), (2) kubectl describe pod to check Events section for container exit codes (137=OOMKilled, 143=SIGTERM, 1=application error, 127=command not found), (3) check resource limits - OOMKilled means memory limit too low, (4) check image - ImagePullBackOff means registry or credentials issue, (5) kubectl exec into the pod (if it briefly runs) to inspect environment, (6) check liveness probe configuration - too-aggressive probes cause unnecessary restarts. For production cluster debugging, ephemeral debug containers (kubectl debug) let you attach debugging tools to running pods without rebuilding images.

Deploy NVIDIA GPU Operator to manage driver + device plugin installation on nodes. Pod specs request GPUs via resources.limits.nvidia.com/gpu. For MIG-partitioned A100/H100, request specific MIG profiles. For multi-tenant GPU sharing, use Kueue for queuing + fair-share or MIG time-slicing. For LLM inference serving, deploy vLLM (see our vLLM on Kubernetes UAE guide) with appropriate GPU count based on model size (Llama 3 70B: 1x H100 with FP8 or 2x H100 FP16). Monitor via DCGM Exporter + Prometheus + Grafana. Typical GPU utilization without proper scheduling: 25-35%; with Kueue + MIG: 60-85%.

Kueue is a Kubernetes-native job queuing system designed for multi-tenant workload sharing, especially GPU / AI/ML workloads. It queues jobs, admits them based on available capacity and fair-share policies, handles preemption and priority, and supports hierarchical resource management (ClusterQueue, LocalQueue, ResourceFlavor). Use Kueue when: multiple teams share GPU pools, you need fair-share between teams, you have batch ML training workloads that need queuing, or you want preemption-based priority for critical workloads. 2026 Kueue has become the standard for GPU scheduling in shared Kubernetes clusters.

CRD (Custom Resource Definition) extends Kubernetes API with custom objects (e.g., VirtualService, ArgoCD Application, KafkaCluster). Operators are controllers that reconcile custom resources - they watch for CRs and take action to make cluster state match desired state. Operators encode operational knowledge for specific applications (Postgres, Kafka, Cassandra, Elasticsearch) as code. Common operators: cert-manager (TLS certs), ArgoCD (GitOps), Prometheus Operator (monitoring stack), Strimzi (Kafka), CloudNativePG (Postgres). For 2026 production, operators are how you deploy and manage complex stateful applications on Kubernetes - avoid hand-crafted Deployment + StatefulSet configurations when a mature operator exists.

Kustomize is the Kubernetes-native configuration management tool (built into kubectl apply -k). It works via overlays: a base directory with standard manifests, and overlay directories that patch the base for different environments (dev, staging, prod). No templating - pure YAML composition. Helm uses Go-template-based templating with values.yaml parameterization. Kustomize wins for: declarative YAML transparency, no template escaping issues, Kubernetes-native semantics. Helm wins for: complex templating logic, package management for third-party applications, release lifecycle management. 2026 practice: Kustomize for in-house applications, Helm for third-party charts, both supported by ArgoCD and Flux.

GitOps is declarative continuous deployment where Git is the source of truth and automated controllers reconcile cluster state to Git-defined desired state. Benefits: auditability (full Git history), security (cluster credentials never leave cluster), rollback (Git revert), drift detection (controllers flag when actual state diverges from Git). Main 2026 tools: ArgoCD (rich UI, strongest multi-cluster, largest ecosystem), Flux (lightweight, GitOps Toolkit composable architecture), Jenkins X (all-in-one but declining), Codefresh (commercial ArgoCD). For new Kubernetes deployments in 2026, ArgoCD is the default choice. See our GitOps tools comparison for detailed selection.

Typical clusters run 30-50% over-provisioned. Cost optimization techniques: (1) Right-size pods via VPA recommendations or manual analysis of actual usage, (2) Use Karpenter or Cluster Autoscaler with spot instances for non-critical workloads, (3) Consolidate workloads via bin-packing and pod disruption policies, (4) Delete idle resources - terminated pods, unused PVs, orphaned LoadBalancers, (5) Use Kubernetes cost tools: Kubecost, OpenCost, or cloud-native billing correlation, (6) Implement quotas and limits per namespace to prevent overconsumption. For regulated UAE clusters on me-central-1 or UAE North, typical savings are 30-50% vs unoptimized clusters. FinOps engagement is often necessary to drive sustained cost discipline.

Planned upgrade workflow: (1) Review release notes for breaking changes and deprecated APIs, (2) Run kube-no-trouble (kubent) or pluto to detect deprecated API usage in manifests, (3) Upgrade test environments first with production-like workloads, (4) Upgrade control plane first (one minor version at a time), (5) Upgrade node pools incrementally with pod disruption budgets respected, (6) Verify workloads post-upgrade. For managed Kubernetes (EKS, AKS, GKE), upgrade via cloud provider UI/API - the provider handles control plane. For self-managed, kubeadm upgrade or cluster-management tool (Cluster API, kops). Don't skip minor versions - upgrade 1.30 -> 1.31 -> 1.32, not 1.30 -> 1.32 directly.

Multi-cluster architectures in 2026 typically combine: (1) GitOps tool with multi-cluster support (ArgoCD ApplicationSets or Flux multi-repo) for centralized deployment, (2) Service mesh with multi-cluster support (Istio, Cilium Cluster Mesh, Consul Connect) for cross-cluster service discovery, (3) Centralized observability to aggregate metrics/logs/traces across clusters, (4) Identity federation (workload identity across clusters, cross-cluster IAM), (5) Network connectivity (Transit Gateway, VPC peering, or overlay networks). For UAE enterprises running multi-region (AWS me-central-1 + Azure UAE North + Core42), multi-cluster is inevitable - invest in the architecture early. See our service mesh and CNAPP comparisons for platform selection.

AI/ML on Kubernetes adds requirements beyond traditional web workloads: (1) GPU scheduling with NVIDIA GPU Operator + Kueue, (2) Larger pod resource requests (training jobs can be 8x A100s for 48 hours), (3) PersistentVolume for model weights and datasets (often TB-scale), (4) Inference serving with vLLM, Triton, KServe, or TensorRT-LLM optimized for GPU throughput, (5) Specialized autoscaling (KEDA on queue depth or tokens-per-second, not CPU), (6) Observability for GPU utilization and model metrics (DCGM Exporter, inference-specific metrics), (7) Cost attribution per ML team due to high GPU costs. Infrastructure maturity typical for production AI/ML on Kubernetes is significantly above what web-service infrastructure requires. See our vLLM on Kubernetes UAE and AI/ML infrastructure guides.