Skip to main content

Kubernetes Interview Questions

This guide contains 60+ Kubernetes interview questions organized by difficulty level. Each question includes clear, concise answers suitable for technical interviews.

Beginner Questions (1-20)​

1. What is Kubernetes?​

Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications. It groups containers into logical units called Pods and provides declarative configuration for infrastructure management. Kubernetes is platform-agnostic and runs on any cloud provider, on-premises, or hybrid environments.

2. What are the main components of Kubernetes architecture?​

Kubernetes follows a master-worker architecture:

  • Control Plane: API Server, etcd, Scheduler, Controller Manager
  • Worker Nodes: kubelet, kube-proxy, container runtime
  • Networking: CNI plugins, DNS service
  • Storage: PersistentVolumes, storage classes

3. What is a Pod?​

A Pod is the smallest deployable unit in Kubernetes, typically containing one main container and optionally sidecar containers that share network namespace, storage, and specifications. Pods are ephemeral and not created directly; they're managed by higher-level controllers like Deployments. All containers in a Pod share the same IP address and can communicate via localhost.

4. What is the difference between a Pod and a Container?​

A Container is a standalone unit managed by a container runtime (Docker, containerd). A Pod is a Kubernetes-specific wrapper that can contain one or more containers, providing shared networking, storage, and execution context. Pods add scheduling capabilities, health checks, and cluster-aware resource management that containers alone don't provide.

5. What is a Deployment?​

A Deployment is a Kubernetes resource that describes a desired state for Pods and ReplicaSets. It enables declarative updates, rollback capabilities, and rolling updates without downtime. Deployments manage stateless applications by maintaining a specified number of replicas across the cluster.

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

6. What is a Service in Kubernetes?​

A Service is an abstraction that exposes a set of Pods as a network service with a stable IP address and DNS name. Services enable load balancing, service discovery, and abstract the underlying Pod replicas. They decouple consumers from producers, allowing Pods to be replaced without breaking connectivity.

7. What are the types of Services?​

  • ClusterIP: Exposes the service on a cluster-internal IP (default)
  • NodePort: Exposes the service on each node's IP at a static port
  • LoadBalancer: Exposes the service externally using a cloud provider's load balancer
  • ExternalName: Maps the service to an external DNS name

8. What is a Namespace?​

A Namespace is a logical isolation mechanism in Kubernetes that creates virtual clusters within the same physical cluster. Namespaces allow multiple teams to share resources with isolation, enable resource quotas and network policies, and support multi-tenancy. Default namespaces include default, kube-system, and kube-public.

9. What is kubectl?​

kubectl is the command-line interface for Kubernetes that enables users to interact with clusters. It communicates with the API Server and allows you to deploy applications, manage resources, inspect logs, execute commands, and perform administrative tasks.

Common commands:

kubectl get pods
kubectl apply -f deployment.yaml
kubectl logs pod-name
kubectl exec -it pod-name -- /bin/bash
kubectl delete deployment deployment-name

10. What is a ReplicaSet?​

A ReplicaSet is a Kubernetes controller that ensures a specified number of pod replicas run at all times. It continuously monitors pods and creates or deletes them to maintain the desired replica count. While Deployments manage ReplicaSets, understanding ReplicaSets helps with troubleshooting and understanding the hierarchy.

11. What is the role of kubelet?​

The kubelet is a node-level agent that ensures containers run in Pods as described in PodSpecs. It registers the node with the cluster, monitors Pod health through liveness and readiness probes, and communicates with the container runtime to manage container lifecycle. The kubelet acts as the Kubernetes representative on each node.

12. What is etcd?​

etcd is a distributed, consistent key-value store that serves as Kubernetes' primary data store. All cluster state, configurations, and secrets are persisted in etcd. It uses the Raft consensus algorithm to ensure data consistency across multiple replicas and is critical for cluster recovery and state management.

13. What is kube-proxy?​

kube-proxy is a network proxy that maintains network rules on nodes to enable service abstraction and load balancing. It watches for Service and Endpoint changes and configures iptables or IPVS rules to route traffic to the correct Pod. kube-proxy ensures service discovery and load balancing work correctly.

14. What is the difference between Docker Swarm and Kubernetes?​

Docker Swarm is simpler, requires less resource overhead, and is easier to set up but offers basic orchestration capabilities. Kubernetes is more complex, feature-rich, and industry-standard with advanced scheduling, networking, security, and multi-tenancy features. Kubernetes dominates for enterprise and production environments due to its superior capabilities and ecosystem.

15. What is a ConfigMap?​

A ConfigMap is a Kubernetes object for storing non-sensitive configuration data as key-value pairs. ConfigMaps decouple configuration from application code and allow configuration changes without rebuilding container images. They can be mounted as files or exposed as environment variables in Pods.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  LOG_LEVEL: info
  config.properties: |
    server.port=8080
    debug=false

16. What is a Secret?​

A Secret is a Kubernetes object for storing sensitive data like passwords, API keys, and certificates. Secrets are base64-encoded and can be mounted as files or environment variables. Kubernetes allows encryption of etcd to protect secrets at rest, though they should be treated as confidential.

Types include Opaque (default), ServiceAccountToken, BasicAuth, SSHAuth, and TLS.

17. What is a DaemonSet?​

A DaemonSet ensures a Pod runs on every node (or selected nodes) in the cluster. DaemonSets are ideal for system daemons like logging collectors, monitoring agents, and network plugins that need presence on all nodes. When nodes are added or removed, DaemonSet Pods are automatically created or destroyed.

18. What is a StatefulSet?​

A StatefulSet manages stateful applications with stable identity, persistent storage, and ordered Pod deployment. Unlike Deployments, StatefulSets provide ordinal names, persistent network identities, and ordered startup/shutdown. StatefulSets are essential for databases, message queues, and applications requiring stable hostnames.

19. What is an Ingress?​

An Ingress is a Kubernetes resource that manages external HTTP/HTTPS access to services within the cluster. It provides load balancing, TLS termination, virtual hosting, and path-based routing without exposing individual services as LoadBalancer type. Ingress requires an Ingress Controller (nginx, AWS ALB, etc.) to function.

20. How do you scale a Deployment?​

You can scale a Deployment imperatively or declaratively:

# Imperative scaling
kubectl scale deployment nginx-deployment --replicas=5

# Declarative scaling - edit the YAML
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.0
kubectl patch deployment nginx-deployment -p '{"spec":{"replicas":3}}'

# Declarative - apply updated manifest
kubectl apply -f deployment.yaml

Intermediate Questions (21-45)​

21. Explain the difference between a Deployment and a StatefulSet​

Deployments are for stateless applications with interchangeable replicas, random names, and no persistent storage requirements. StatefulSets are for stateful applications requiring stable identity, ordered deployment, and persistent storage per replica. Deployments provide faster scaling and replacement; StatefulSets provide stable hostnames like mysql-0, mysql-1 and PVC persistence.

22. How does Kubernetes service discovery work?​

Kubernetes uses a built-in DNS system (CoreDNS by default) that automatically creates DNS records for each Service. Pods query the cluster DNS to resolve service names to ClusterIP addresses. DNS records follow the pattern: service-name.namespace.svc.cluster.local. Service discovery enables loose coupling and dynamic Pod discovery without hardcoding IPs.

23. What are liveness and readiness probes?​

Liveness probes determine if a container is alive and should be restarted if it fails. Readiness probes determine if a container is ready to accept traffic. Probes use exec, httpGet, or tcpSocket handlers. Failed readiness probes remove the Pod from service endpoints; failed liveness probes trigger container restart.

Example:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  exec:
    command: ["/bin/sh", "-c", "curl localhost:8080"]
  initialDelaySeconds: 5
  periodSeconds: 5

24. What is a Horizontal Pod Autoscaler?​

A Horizontal Pod Autoscaler (HPA) automatically scales the number of Pods in a Deployment based on metrics like CPU usage or custom metrics. HPA monitors metrics from metrics-server, calculates desired replicas using a formula, and updates the Deployment. It enables cost optimization by scaling down during low demand and scaling up during peaks.

25. Explain taints and tolerations​

Taints are applied to nodes to repel certain Pods; tolerations allow Pods to schedule on tainted nodes. Taints prevent unwanted Pods from running on specific nodes (e.g., GPU-only nodes). A Pod with matching tolerations can schedule despite the taint. They're essential for node constraints and multi-tenancy.

Example:

# Taint on node
kubectl taint nodes node1 gpu=true:NoSchedule

# Toleration in Pod spec
tolerations:
- key: "gpu"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

26. What is node affinity?​

Node affinity is a Kubernetes feature that constrains Pods to run on specific nodes based on labels. It has two types: requiredDuringSchedulingIgnoredDuringExecution (hard constraint) and preferredDuringSchedulingIgnoredDuringExecution (soft preference). Node affinity is more flexible than taints/tolerations and enables pod placement strategies like running on specific zones or hardware.

27. How do rolling updates work?​

Rolling updates gradually replace old Pod replicas with new ones, maintaining availability. The Deployment controller manages ReplicaSet versions, scaling up the new version while scaling down the old version based on maxSurge and maxUnavailable settings. Rolling updates enable zero-downtime deployments with automatic rollback on failure.

28. What are PersistentVolumes and PersistentVolumeClaims?​

A PersistentVolume (PV) is a cluster-wide storage resource provisioned by administrators. A PersistentVolumeClaim (PVC) is a storage request by a Pod that binds to a PV. PVs abstract storage implementation details; PVCs enable applications to request storage without knowing infrastructure. Together they decouple storage from compute and enable data persistence.

29. How does RBAC work?​

Role-Based Access Control (RBAC) restricts user and service account access to Kubernetes resources. It consists of Roles/ClusterRoles (define permissions), RoleBindings/ClusterRoleBindings (assign roles to users), and Subjects (users, groups, service accounts). RBAC enforces least privilege and multi-tenancy by controlling who can perform which actions on which resources.

30. What is a Network Policy?​

A Network Policy restricts inbound and outbound network traffic to Pods based on labels and port rules. Without NetworkPolicies, all Pods can communicate freely. NetworkPolicies enable zero-trust networking, data isolation, and compliance requirements by explicitly allowing traffic flows. They require a CNI plugin that supports NetworkPolicy.

31. What is Helm?​

Helm is the package manager for Kubernetes that simplifies application deployment and management. Helm uses Charts (packages containing templates, values, and metadata) to define, install, upgrade, and rollback applications. Helm enables templating, versioning, dependencies, and sharing reusable application definitions across teams.

32. How does the Kubernetes scheduler decide where to place pods?​

The scheduler uses a filtering and scoring process. It filters nodes using predicates (resource availability, node selectors, affinity, taints) to identify feasible nodes. Then it scores remaining nodes using priorities (pod affinity, resource utilization, zone spread) and selects the highest-scoring node. The kube-scheduler runs on the control plane and watches for unscheduled Pods.

33. What is a sidecar container pattern?​

A sidecar is an auxiliary container deployed alongside the main application container in the same Pod. Sidecars handle cross-cutting concerns like logging, monitoring, service mesh proxies, and config reloading without modifying application code. Sidecars share the network namespace, enabling transparent proxying and inter-container communication via localhost.

34. What are init containers?​

Init containers are specialized containers that run before the main application container in a Pod. Init containers must complete successfully before main containers start. They're useful for setup tasks like downloading configuration, checking dependencies, or initializing data. Init containers have the same image as the application but run with different commands.

35. Explain resource requests vs limits​

Requests specify the minimum resources a Pod needs; the scheduler uses requests for placement decisions. Limits define the maximum resources a Pod can consume. If a container exceeds memory limits, it's OOM-killed; if it exceeds CPU limits, it's throttled. Setting appropriate requests and limits ensures fair resource allocation and cluster stability.

Example:

resources:
  requests:
    memory: "64Mi"
    cpu: "250m"
  limits:
    memory: "128Mi"
    cpu: "500m"

36. What is a Pod Disruption Budget?​

A Pod Disruption Budget (PDB) limits the number of Pods of an application that can be disrupted simultaneously during voluntary disruptions (node maintenance, cluster scaling). PDBs ensure application availability during planned maintenance. They define minAvailable or maxUnavailable thresholds that Kubernetes respects when draining nodes or evicting Pods.

37. How do you perform a rollback?​

You can rollback a Deployment to a previous revision:

# View rollout history
kubectl rollout history deployment/nginx-deployment

# Rollback to previous revision
kubectl rollout undo deployment/nginx-deployment

# Rollback to specific revision
kubectl rollout undo deployment/nginx-deployment --to-revision=2

Kubernetes maintains revision history automatically; you can adjust revisionHistoryLimit to control how many revisions are retained.

38. What is the difference between kubectl apply and kubectl create?​

kubectl create creates new resources from manifest files and fails if the resource already exists. kubectl apply creates resources if they don't exist or updates existing resources using a three-way merge (current state, last applied, new manifest). kubectl apply is idempotent and recommended for declarative configuration management.

39. What are annotations used for?​

Annotations are unstructured key-value metadata attached to Kubernetes objects that don't affect functionality. Unlike labels (used for selection), annotations store tool-specific metadata like build information, deployment timestamps, or tool-specific configuration. They're commonly used by admission webhooks, ingress controllers, and monitoring systems.

40. How does DNS work in Kubernetes?​

Kubernetes runs a DNS service (typically CoreDNS) that responds to DNS queries from Pods. Services get DNS entries like service-name.namespace.svc.cluster.local. Pods can query the cluster DNS to resolve service names to ClusterIPs without hardcoding addresses. DNS enables service discovery and simplifies application configuration across different deployments.

41. What is a headless service?​

A headless service is a service with clusterIP: None, which doesn't allocate a ClusterIP. Instead, DNS returns individual Pod IPs, enabling direct Pod-to-Pod communication. Headless services are essential for StatefulSets where applications need to know specific Pod identities and are useful for peer-to-peer applications like databases and message queues.

42. Explain Blue/Green deployment in Kubernetes​

Blue/Green deployment runs two identical production environments (Blue and Green). The old version (Blue) handles production traffic while the new version (Green) runs alongside. Traffic switches to Green after validation, enabling instant rollback if issues occur. It requires 2x resources but provides zero-downtime deployments with minimal risk.

43. What is a Job and CronJob?​

A Job creates one or more Pods to run a batch task to completion. CronJobs schedule Jobs to run on a cron schedule. Jobs and CronJobs are ideal for batch processing, backups, and scheduled tasks. Unlike Deployments, Jobs don't continuously maintain replicas; they complete and stop.

Example:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-job
spec:
  schedule: "0 2 * * *"  # 2 AM daily
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup:v1
          restartPolicy: OnFailure

44. How do you pass environment variables to a pod?​

You can pass environment variables via:

env:
- name: APP_ENV
  value: "production"
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password
- name: POD_IP
  valueFrom:
    fieldRef:
      fieldPath: status.podIP

Environment variables can come from ConfigMaps, Secrets, or literal values, and support downward API for Pod metadata.

45. What is kustomize?​

Kustomize is a template-free customization tool for Kubernetes manifests that uses patching and composition. Unlike Helm, Kustomize doesn't use templating; it overlays changes on top of base manifests for different environments (dev, staging, prod). Kustomize is built into kubectl and enables managing variations without duplicating YAML.

Advanced Questions (46-60+)​

46. How does the Kubernetes networking model work?​

Kubernetes requires a flat networking model where every Pod has a unique IP address and can communicate with any other Pod without NAT. This is enforced by Container Network Interface (CNI) plugins like Flannel, Calico, or Weave. Pods communicate across nodes via overlay networks or direct routing; services provide stable endpoints for pod-to-service communication; and NodePorts and Ingress handle external traffic.

47. Explain how etcd handles consensus (Raft protocol)​

etcd uses the Raft consensus algorithm to replicate data across multiple instances. In Raft, one node becomes the Leader, which accepts all writes and replicates them to Followers. Followers acknowledge replication; once a majority acknowledges, the write is committed. If the Leader fails, Followers elect a new Leader. This ensures consistency and fault tolerance, critical for Kubernetes cluster state.

48. What is a Custom Resource Definition (CRD)?​

A CRD extends the Kubernetes API with custom resources specific to applications or organizations. CRDs are defined via YAML and enable storing arbitrary data in etcd with API Server validation and kubectl integration. CRDs are the foundation for Operators and allow applications to use Kubernetes as a data store for domain-specific concepts.

Example:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.example.com
spec:
  group: example.com
  names:
    kind: Database
    plural: databases
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true

49. What is an Operator pattern?​

An Operator is a Kubernetes controller that manages application-specific operations using CRDs and domain knowledge. Operators encode operational expertise, automating complex tasks like provisioning, scaling, backup, and upgrade of stateful applications. Examples include Prometheus Operator, Kafka Operator, and database operators that handle lifecycle management beyond basic orchestration.

50. How do you secure a Kubernetes cluster?​

Key security practices include:

  • Authentication: Use strong credentials, disable anonymous access, integrate with identity providers
  • Authorization: Implement RBAC with least privilege
  • Network policies: Restrict pod-to-pod communication
  • Pod security: Use security contexts, network policies, admission controllers
  • Secrets: Encrypt etcd at rest, rotate secrets, use external secret management
  • Image security: Use private registries, scan for vulnerabilities, enforce image policies
  • Audit logging: Monitor API access, track changes
  • Supply chain: Verify image signatures, enforce policy with tools like Kyverno

51. Explain pod security contexts​

A security context defines OS-level privileges and access controls for Pods and containers. It configures:

  • User and group IDs for process execution
  • Linux capabilities to add/drop
  • Read-only root filesystem enforcement
  • Privilege escalation restrictions
  • SELinux options
  • AppArmor profiles

Security contexts enforce least privilege and prevent container escape vulnerabilities.

52. What is a service mesh and why use one?​

A service mesh is infrastructure managing service-to-service communication using sidecar proxies. Service meshes (Istio, Linkerd) handle traffic management, security, observability, and resilience without modifying application code. They enable circuit breaking, retry logic, distributed tracing, mutual TLS, and traffic shaping, improving reliability and security of microservices architectures.

53. How do you troubleshoot a pod stuck in CrashLoopBackOff?​

A Pod in CrashLoopBackOff means it's continuously crashing and restarting. Troubleshooting steps:

kubectl describe pod pod-name  # Check events and status
kubectl logs pod-name --previous  # View logs from crashed container
kubectl logs pod-name -c container-name  # View logs from specific container
kubectl exec -it pod-name -- /bin/bash  # Debug interactively (if possible)
kubectl get events --sort-by='.lastTimestamp'  # View cluster events

Common causes: missing dependencies, permission issues, resource exhaustion, or application bugs. Check logs and events first.

54. What is the Container Storage Interface (CSI)?​

CSI is a standard interface for container orchestrators (Kubernetes) to expose storage systems to workloads. CSI enables drivers (AWS EBS, GCP Persistent Disk, NetApp, etc.) to implement storage provisioning without modifying core Kubernetes code. CSI abstracts storage implementation, allowing portable applications and vendor-agnostic storage management.

55. How do you handle secrets securely in production?​

Best practices include:

  • At rest: Enable encryption in etcd using --encryption-provider-config
  • In transit: Use TLS for API communication
  • Rotation: Implement regular secret rotation
  • External management: Use HashiCorp Vault, AWS Secrets Manager, or similar
  • Access control: Restrict RBAC access to secrets
  • Monitoring: Audit secret access and changes
  • Mount: Use secret volumes instead of environment variables to prevent exposure in ps output
  • Scanning: Scan images and repositories for accidentally committed secrets

56. What is GitOps?​

GitOps is an operational model using Git as the single source of truth for infrastructure and application configuration. All changes go through version control, enabling auditability, rollback capability, and collaboration. Tools like ArgoCD, Flux, and Werf automatically sync cluster state to Git state, enabling declarative and observable deployments.

57. How does cluster autoscaling work?​

Cluster autoscaling monitors Pods that can't be scheduled due to insufficient node resources. When pending Pods are detected, the autoscaler provisions new nodes from the cloud provider. When nodes become underutilized, the autoscaler removes them after a grace period. Cluster autoscaling integrates with cloud provider APIs and works alongside Horizontal Pod Autoscaler for complete scaling.

58. What is a mutating admission webhook?​

A mutating admission webhook is a custom component that intercepts and modifies API requests before they're persisted. Webhooks run outside the cluster, enabling dynamic request transformation. Common uses include injecting sidecar containers, modifying resource defaults, enforcing labels, or applying security policies. Webhooks enable extending Kubernetes behavior without modifying core code.

59. How would you design a multi-tenant Kubernetes cluster?​

Multi-tenancy design involves:

  • Isolation: Use namespaces as primary isolation boundary
  • Resource quotas: Limit per-tenant resource consumption
  • Network policies: Prevent cross-tenant pod communication
  • RBAC: Separate service accounts and role bindings per tenant
  • Storage: Use StorageClasses with isolation; avoid shared PVs
  • Monitoring: Separate metrics and logs per tenant
  • API isolation: Consider Kubernetes API access controls
  • Cost allocation: Track resource usage per tenant
  • Pod security: Enforce security policies per tenant

Full isolation requires dedicated control planes for strong security requirements.

60. Explain the difference between Ingress and Gateway API​

Ingress is a stable Kubernetes resource for HTTP/HTTPS routing with a simple but limited API. Gateway API is a newer, more expressive API with improved support for advanced routing, load balancing, and traffic management. Gateway API is more extensible and supports protocols beyond HTTP; it's the recommended approach for new deployments but requires GatewayClass implementations.

Interview Tips for Kubernetes​

  1. Understand the fundamentals deeply: Master Pods, Deployments, Services, and namespace concepts before diving into advanced topics. Interviewers value solid foundational knowledge.

  2. Practice kubectl commands: Be comfortable with kubectl get, kubectl describe, kubectl logs, kubectl exec, and kubectl apply. Hands-on familiarity demonstrates practical experience.

  3. Know the architecture: Understand control plane components (API Server, scheduler, controller manager) and worker node components (kubelet, kube-proxy). Be able to explain how they communicate and their responsibilities.

  4. Draw diagrams when explaining complex concepts: For topics like networking, service discovery, or stateful applications, drawing helps clarify your understanding and impresses interviewers.

  5. Real-world scenario thinking: Prepare for scenario questions like "How would you deploy a stateful database?" or "How do you ensure zero-downtime updates?" Frame answers around business requirements, not just technical capabilities.

  6. Common troubleshooting workflows: Master debugging techniques for CrashLoopBackOff, ImagePullBackOff, Pending state, and networking issues. Know which commands to run first and how to interpret output.

  7. Security mindset: Always consider security when discussing features. Mention RBAC, network policies, secrets management, and pod security in relevant discussions. Security awareness is valued in production environments.

  8. Stay current with ecosystem changes: Kubernetes evolves rapidly. Mention familiarity with Helm, service meshes, GitOps, and recent GA features like Gateway API. Show awareness of industry trends and best practices.

Last Updated: March 2026

These questions reflect current Kubernetes best practices and cover typical interview scenarios. Focus on understanding concepts, practice hands-on examples, and be ready to discuss real-world applications of each topic.