Kubernetes Interview Questions
Ace your Kubernetes interview with this comprehensive Q&A guide covering basic to advanced topics, scenario-based questions, and design questions with detailed explanations for each answer.
These questions test fundamental understanding of Kubernetes concepts. They're typically asked in junior or mid-level interviews.
Answer: Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It was originally developed by Google and is now maintained by the Cloud Native Computing Foundation (CNCF).
- Container Orchestration: Automates container deployment, scaling, and management
- Service Discovery & Load Balancing: Exposes containers using DNS names or IP addresses
- Self-Healing: Restarts failed containers, replaces and reschedules containers
- Horizontal Scaling: Scale applications up and down with simple commands
- Automated Rollouts and Rollbacks: Gradually roll out changes and rollback if issues occur
- Secret and Configuration Management: Manage sensitive information without rebuilding images
Answer: A Pod is the smallest deployable unit in Kubernetes. It is a group of one or more containers that share storage and network resources. A Container is a single runtime instance of a container image.
Answer: The control plane consists of several components that manage the cluster:
- API Server: The central management point that exposes the Kubernetes API
- etcd: A distributed key-value store that stores all cluster data
- Scheduler: Assigns pods to nodes based on resource requirements
- Controller Manager: Runs controllers that handle cluster state
- Cloud Controller Manager: Interacts with cloud providers
Answer: A Service is an abstraction that defines a logical set of pods and a policy by which to access them. It provides stable network endpoints (IP or DNS name) for accessing pods, which can be dynamically created and destroyed.
- ClusterIP: Exposes the service on an internal IP (default)
- NodePort: Exposes the service on each node's IP
- LoadBalancer: Creates an external load balancer (cloud providers)
- Headless: No cluster IP (for stateful applications)
Answer: A Deployment manages stateless applications with identical replicas. A StatefulSet manages stateful applications with unique identities and persistent storage.
- StatefulSets provide stable network identities (pod-0, pod-1, etc.)
- StatefulSets support ordered deployment and scaling
- StatefulSets use persistent storage (PVCs) per pod
- Deployments are for stateless applications (cattle), StatefulSets are for stateful (pets)
Answer: Ingress manages external access to services in a cluster, typically HTTP/HTTPS. It provides load balancing, SSL termination, and name-based virtual hosting.
Answer: Labels are key-value pairs attached to Kubernetes objects (pods, services, etc.) for organization and grouping. Selectors are used to filter objects based on labels.
Answer: ConfigMaps store non-sensitive configuration data in key-value pairs. Secrets store sensitive data (passwords, API keys, certificates) and are encoded in base64.
These questions test deeper understanding of Kubernetes operations, networking, and security. Typically asked in senior engineer interviews.
Answer: The scheduler watches for newly created pods with no assigned node and selects the best node for them based on:
- Resource requirements (CPU, memory)
- Node affinity/anti-affinity rules
- Taints and tolerations
- Pod priority
- Topology spread constraints
- Node availability and health
Answer: Taints are applied to nodes to repel pods. Tolerations are applied to pods to allow scheduling on tainted nodes.
- Dedicated Nodes: Taint nodes for specific workloads (GPU, database)
- Node Maintenance: Taint with NoExecute to evict pods
- Node Group Isolation: Separate development and production workloads
- Spot Instances: Taint spot nodes for fault-tolerant workloads
Answer: A ReplicaSet ensures that a specified number of pod replicas are running at all times. A Deployment manages ReplicaSets and provides declarative updates, rollbacks, and scaling.
Answer: Kubernetes uses the Container Network Interface (CNI) to manage pod networking. Each pod gets its own IP address, and pods can communicate with each other without NAT.
- CNI plugins (Calico, Cilium, Flannel) implement the networking model
- Each pod has a unique IP address within the cluster network
- Services provide stable endpoints for accessing pods
- Network policies provide security controls at L3/L4
Answer: A headless service is a service with clusterIP: None. It doesn't provide load balancing; instead, DNS resolves to individual pod IPs.
- StatefulSets: Each pod needs direct access (e.g., databases)
- Service Discovery: Applications that need to discover all pod instances
- Custom Load Balancing: When you want to implement your own load balancing logic
- Peer-to-Peer Communication: Services that need to talk to specific pods
Answer: A PersistentVolume (PV) is a piece of storage in the cluster provisioned by an administrator. A PersistentVolumeClaim (PVC) is a request for storage by a user.
- Administrator provisions a PV (NFS, EBS, etc.)
- User creates a PVC requesting storage (size, access mode, etc.)
- Kubernetes binds the PVC to a matching PV
- Pods use PVCs to mount storage
Answer: Zero-downtime deployments can be achieved using:
- Rolling Updates: Default deployment strategy
- Blue-Green Deployments: Switch traffic between two environments
- Canary Deployments: Gradual rollout with traffic splitting
- PodDisruptionBudgets: Prevent excessive pod evictions
- Readiness Probes: Ensure pods are ready before routing traffic
These questions test deep expertise in Kubernetes architecture, performance, and complex troubleshooting. Typically asked in senior/principal or architect interviews.
Answer: etcd is a distributed, reliable key-value store that serves as Kubernetes' backing store for all cluster data. It stores the entire cluster state including configurations, secrets, and resource status.
- etcd is the single source of truth for the cluster
- All API server reads and writes go through etcd
- etcd uses Raft consensus for consistency and HA
- etcd failure means cluster failure
- Regular backups are mandatory for disaster recovery
Answer: QoS classes determine pod priority for eviction under resource pressure:
- Guaranteed: Requests = Limits (highest priority)
- Burstable: Requests < Limits (medium priority)
- BestEffort: No requests or limits (lowest priority)
Answer: Kubernetes supports multiple autoscaling mechanisms:
- Horizontal Pod Autoscaler (HPA): Scales pod replicas based on CPU/memory or custom metrics
- Vertical Pod Autoscaler (VPA): Adjusts pod resource requests
- Cluster Autoscaler: Adds/removes nodes based on pending pods
- KEDA: Event-driven scaling for queues and external metrics
Answer: CNI provides basic pod networking (IP assignment, routing, network policy). Service Mesh provides advanced networking features at L7 (traffic management, mTLS, observability).
- CNI operates at L3/L4, service mesh at L7
- Service mesh uses sidecar proxies (Envoy, Linkerd)
- Service mesh provides mTLS, canary, A/B testing
- Service mesh adds observability (metrics, tracing, logs)
- CNI is required for cluster networking; service mesh is optional
Answer: Backup and disaster recovery strategies include:
- etcd Backup: Regular etcd snapshots for cluster state
- Velero: Application-level backup with volume snapshots
- Volume Snapshots: CSI-based snapshots for persistent data
- Application Backups: Database-specific backups (pg_dump, mysqldump)
- Disaster Recovery Plan: Documented RTO/RPO and recovery procedures
Answer: The API server is the central management component that:
- Exposes the Kubernetes API
- Authenticates and authorizes requests
- Validates and mutates resources via admission controllers
- Persists state to etcd
- Provides the interface for all cluster operations
These questions test practical problem-solving skills in real-world scenarios. They're commonly asked in senior-level interviews to assess hands-on experience.
Answer: Systematic diagnostic approach:
- Check pod status:
kubectl top podsandkubectl get pods - Check node resources:
kubectl top nodes - Check pod logs:
kubectl logs <pod> - Check events:
kubectl get events - Check service endpoints:
kubectl get endpoints - Check network policies:
kubectl get networkpolicies - Check ingress controller logs:
kubectl logs -n ingress-nginx
Answer: Migration approach:
- Use Velero: Backup from source cluster, restore to target cluster
- Database Replication: Set up replication between clusters
- Data Migration: Use database-specific tools for data migration
- Application Deployment: Deploy application to target cluster
- Traffic Switch: Switch traffic using DNS or load balancer
- Validation: Test thoroughly before decomissioning source
Answer: Systematic approach to resolve OOMKilled issues:
- Diagnose: Identify which pods are OOMKilled (
kubectl get pods | grep OOMKilled) - Check usage: Monitor memory usage over time (
kubectl top pods) - Increase limits: Increase memory limits for affected pods
- Optimize code: Identify and fix memory leaks
- Scale horizontally: Add more replicas to distribute load
- Add nodes: Increase cluster capacity
- Use VPA: Implement VPA for automatic recommendations
Answer: Multi-tenant design considerations:
- Namespace Isolation: Each tenant gets a namespace with resource quotas
- Network Policies: Isolate tenant network traffic
- RBAC: Fine-grained access control per tenant
- Service Mesh: mTLS and identity-based security
- Storage Isolation: Separate PVCs or storage classes
- Resource Quotas: Limit resource consumption per tenant
- Audit Logging: Log all tenant activities
- Secrets Management: Per-tenant secrets with encryption
# Basic Commands
kubectl get nodes
kubectl get pods
kubectl get services
kubectl get deployments
# Debugging Commands
kubectl describe pod <pod>
kubectl logs <pod>
kubectl logs --previous <pod>
kubectl exec -it <pod> -- /bin/sh
# Resource Management
kubectl top nodes
kubectl top pods
kubectl scale deployment <name> --replicas=<count>
# Configuration
kubectl get configmaps
kubectl get secrets
kubectl create secret generic <name> --from-literal=key=value
# Networking
kubectl get services
kubectl get endpoints
kubectl get networkpolicies
kubectl get ingress
# Advanced
kubectl get events --all-namespaces
kubectl get componentstatuses
kubectl get nodes -o yaml
Preparation is key. Practice these questions, set up a test environment, and you'll be well-prepared for your Kubernetes interview. Good luck!