Kubernetes Interview Questions Part 1 — Top 15 for 1–3 Years Experience
☸️ Day 5 of 30 — Interview Prep
Kubernetes Interview Questions — Part 1
Top 15 questions for 1–3 years experience — with answers and real-world analogies
15
Questions covered
1–3
Years experience level
15
Real-world analogies
Part 1
of Interview Series
📋 Questions covered in Part 1
- What is the difference between a Pod and a Container?
- What is a Deployment and why do we use it over a bare Pod?
- What is a ReplicaSet and how does it relate to a Deployment?
- What is auto healing in Kubernetes?
- What are the types of Kubernetes Services?
- What is the difference between ClusterIP, NodePort and LoadBalancer?
- What is a Namespace and why do we use it?
- What is the role of the Kubernetes Scheduler?
- What is etcd and why is it critical?
- What is the difference between liveness and readiness probes?
- How does Kubernetes handle configuration and secrets?
- What is a rolling update and how does it work?
- What happens when you run kubectl apply?
- What is the difference between requests and limits in Kubernetes?
- What is a label and selector in Kubernetes?
💼 Before you read — how to use this post in an interview
- Do not memorise answers word for word. Understand the concept, then explain it in your own words.
- Use the analogy first to show intuition, then follow with the technical detail — interviewers love that.
- For every answer, think of one time you used this in a real project and mention it.
- If you do not know something, say: "I haven't worked with this deeply, but from what I understand..." — honesty + curiosity beats bluffing every time.
Section 1 — Core Concepts
1
What is the difference between a Pod and a Container?
✅ Answer
A container is a single isolated process — it packages your application code, runtime, and dependencies together. A Pod is a Kubernetes abstraction that wraps one or more containers. All containers inside a Pod share the same network namespace (same IP address), the same storage volumes, and the same lifecycle. They are created together, scheduled on the same node, and terminated together.
In practice, most Pods run a single container. Multi-container Pods are used for the sidecar pattern — where a helper process (like a log shipper or service mesh proxy) runs alongside the main application.
In practice, most Pods run a single container. Multi-container Pods are used for the sidecar pattern — where a helper process (like a log shipper or service mesh proxy) runs alongside the main application.
🏢 Analogy: A container is a single employee. A Pod is the office room they work in. Employees in the same room can talk directly, share the same whiteboard (storage), and use the same phone extension (IP). Employees in different rooms must go through the hallway (network) to communicate.
💡 Follow-up interviewers love to ask: "Can two containers in the same Pod communicate via localhost?" — Yes, because they share a network namespace.
2
What is a Deployment and why do we use it instead of creating bare Pods?
✅ Answer
A Deployment is a higher-level Kubernetes object that manages Pods through a ReplicaSet. It adds three critical capabilities that bare Pods do not have:
1. Self-healing — if a Pod dies, the Deployment's ReplicaSet creates a replacement automatically.
2. Rolling updates — when you update the container image, Kubernetes replaces old Pods with new ones gradually, with zero downtime.
3. Rollback — if a bad deployment is pushed, one command rolls back to the previous working version.
A bare Pod that dies is gone forever. A Deployment-managed Pod that dies is replaced in seconds.
1. Self-healing — if a Pod dies, the Deployment's ReplicaSet creates a replacement automatically.
2. Rolling updates — when you update the container image, Kubernetes replaces old Pods with new ones gradually, with zero downtime.
3. Rollback — if a bad deployment is pushed, one command rolls back to the previous working version.
A bare Pod that dies is gone forever. A Deployment-managed Pod that dies is replaced in seconds.
🏭 Analogy: A bare Pod is a single worker hired directly with no HR department. If that worker quits, nobody replaces them — work stops. A Deployment is a staffing agency contract that says "always keep 3 workers in this role." If one leaves, the agency immediately sends a replacement.
⚠️ Never create bare Pods in production. Always wrap them in a Deployment. This is a very common interview trap — if you say "I just use kubectl run to create Pods", that is a red flag for experienced interviewers.
3
What is a ReplicaSet and how does it relate to a Deployment?
✅ Answer
A ReplicaSet has one job: ensure a specified number of Pod replicas are always running. It uses a label selector to identify which Pods it owns. If the count drops below desired, it creates new Pods. If it goes above, it deletes extras.
A Deployment manages ReplicaSets. When you create a Deployment, it creates a ReplicaSet automatically. When you do a rolling update, the Deployment creates a second new ReplicaSet (for the new version) and gradually scales it up while scaling the old one down. The old ReplicaSet is kept around for rollback purposes.
So the relationship is: Deployment → owns ReplicaSet → owns Pods. In practice, you never interact with ReplicaSets directly — you always go through Deployments.
A Deployment manages ReplicaSets. When you create a Deployment, it creates a ReplicaSet automatically. When you do a rolling update, the Deployment creates a second new ReplicaSet (for the new version) and gradually scales it up while scaling the old one down. The old ReplicaSet is kept around for rollback purposes.
So the relationship is: Deployment → owns ReplicaSet → owns Pods. In practice, you never interact with ReplicaSets directly — you always go through Deployments.
🎬 Analogy: A ReplicaSet is the floor manager who makes sure exactly 3 cashiers are always at the checkout. A Deployment is the store manager who tells the floor manager how many cashiers to keep, and also handles shift changes (rolling updates) by bringing in new staff before sending old ones home.
4
What is auto healing in Kubernetes and how does it work?
✅ Answer
Auto healing is Kubernetes' ability to automatically detect and recover from failures — without any human intervention. It is powered by the reconciliation loop running inside the Controller Manager on the Control Plane.
The loop runs continuously: it reads the desired state from etcd (e.g. "3 replicas") and compares it to the actual state (e.g. "2 running"). If they differ, it takes corrective action — creating a new Pod to close the gap. This loop never stops, which means Kubernetes is constantly watching and correcting.
Auto healing covers: container crashes, failed liveness probes, node failures, and manual Pod deletions.
The loop runs continuously: it reads the desired state from etcd (e.g. "3 replicas") and compares it to the actual state (e.g. "2 running"). If they differ, it takes corrective action — creating a new Pod to close the gap. This loop never stops, which means Kubernetes is constantly watching and correcting.
Auto healing covers: container crashes, failed liveness probes, node failures, and manual Pod deletions.
🌡️ Analogy: Auto healing is like a thermostat. You set the desired temperature (desired state = 3 replicas). The thermostat constantly checks the actual temperature (actual running Pods). If it drops, it automatically turns on the heater (creates new Pods). You do not touch anything — it self-corrects.
# The reconciliation loop (simplified):
loop every few seconds:
desired = etcd # e.g. replicas: 3
actual = running Pods # e.g. 2
if actual < desired → create new Pod
if actual > desired → delete excess Pod
Section 2 — Networking & Services
5
What are the types of Kubernetes Services and when do you use each?
✅ Answer
There are four Service types in Kubernetes:
| Type | Accessible from | Use case |
|---|---|---|
ClusterIP | Inside cluster only | Default. Backend services, databases, APIs talking to each other |
NodePort | Cluster + org network | Internal team access, dev/test environments, Minikube demos |
LoadBalancer | Cluster + internet | Production customer-facing apps on cloud clusters |
ExternalName | Cluster only (DNS alias) | Map a K8s Service to an external DNS name like an RDS database |
📮 Analogy: ClusterIP is an internal office extension — only colleagues inside the building can call it. NodePort is the office's direct phone number — people in your organisation can call from outside the building. LoadBalancer is a public 1-800 number that anyone in the world can dial.
6
What is the difference between ClusterIP, NodePort and LoadBalancer?
✅ Answer
ClusterIP is the default Service type. It assigns a virtual IP reachable only within the cluster. Every Service automatically gets a DNS name like
NodePort extends ClusterIP by opening a static port (30000–32767) on every node in the cluster. Anyone who can reach a node's IP on that port can access your app. It is good for dev/test environments but not recommended for direct internet exposure.
LoadBalancer extends NodePort by also provisioning a real cloud load balancer (AWS ALB, GCP Load Balancer) with a public IP. It is the production standard for internet-facing applications. It costs money because the cloud charges for the load balancer resource.
They are additive — LoadBalancer includes all NodePort functionality, which includes all ClusterIP functionality.
my-service.default.svc.cluster.local. Use it for all internal service-to-service communication.NodePort extends ClusterIP by opening a static port (30000–32767) on every node in the cluster. Anyone who can reach a node's IP on that port can access your app. It is good for dev/test environments but not recommended for direct internet exposure.
LoadBalancer extends NodePort by also provisioning a real cloud load balancer (AWS ALB, GCP Load Balancer) with a public IP. It is the production standard for internet-facing applications. It costs money because the cloud charges for the load balancer resource.
They are additive — LoadBalancer includes all NodePort functionality, which includes all ClusterIP functionality.
🏨 Analogy: ClusterIP is a room-to-room intercom — only works inside the hotel. NodePort is the hotel's side entrance — staff with a keycard (access to node IPs) can use it. LoadBalancer is the grand front entrance with a doorman — open to anyone, with professional traffic management.
7
What is a Kubernetes Namespace and why do we use it?
✅ Answer
A Namespace is a way to divide a single Kubernetes cluster into multiple virtual clusters. Resources like Pods, Services, and Deployments are scoped to a Namespace — the same name can exist in different Namespaces without conflict.
Namespaces are used for:
Environment separation — dev, staging, production all on the same cluster
Team separation — frontend team, backend team, data team each get their own space
Resource quotas — limit how much CPU/memory a team can consume
Access control — RBAC permissions can be scoped per Namespace
Kubernetes ships with four default namespaces:
Namespaces are used for:
Environment separation — dev, staging, production all on the same cluster
Team separation — frontend team, backend team, data team each get their own space
Resource quotas — limit how much CPU/memory a team can consume
Access control — RBAC permissions can be scoped per Namespace
Kubernetes ships with four default namespaces:
default, kube-system, kube-public, and kube-node-lease.🏢 Analogy: A Namespace is like a floor in a large office building. Multiple companies (teams) share the same building (cluster) but each has their own floor (namespace) with their own rooms (Pods), their own resources, and their own access rules. A "conference room" can exist on floor 3 and floor 7 simultaneously — they are completely separate.
# List all namespaces
kubectl get namespaces
# Run commands in a specific namespace
kubectl get pods -n kube-system
# Create a new namespace
kubectl create namespace dev-team
Section 3 — Architecture & Control Plane
8
What is the role of the Kubernetes Scheduler?
✅ Answer
The Scheduler is a Control Plane component that decides which node a newly created Pod should run on. When a Pod is created without a node assignment, the Scheduler watches for it and runs a two-phase process:
1. Filtering — eliminates nodes that cannot run this Pod (insufficient CPU/memory, taints, node affinity rules not met, etc.)
2. Scoring — ranks the remaining eligible nodes by how good a fit they are (resource availability, spreading, data locality, etc.)
The highest-scoring node gets the Pod assigned. The Scheduler then updates the Pod object in the API Server. The kubelet on that node then picks it up and starts the container. The Scheduler itself never runs containers — it only makes placement decisions.
1. Filtering — eliminates nodes that cannot run this Pod (insufficient CPU/memory, taints, node affinity rules not met, etc.)
2. Scoring — ranks the remaining eligible nodes by how good a fit they are (resource availability, spreading, data locality, etc.)
The highest-scoring node gets the Pod assigned. The Scheduler then updates the Pod object in the API Server. The kubelet on that node then picks it up and starts the container. The Scheduler itself never runs containers — it only makes placement decisions.
✈️ Analogy: The Scheduler is an air traffic controller. New flights (Pods) arrive and need to be assigned to a runway (node). The controller checks which runways are available (filtering), considers factors like runway length and current traffic (scoring), and assigns the best one. The controller never lands the plane — that is the pilot's (kubelet's) job.
9
What is etcd and why is it critical to a Kubernetes cluster?
✅ Answer
etcd is a distributed, strongly consistent key-value store that serves as the single source of truth for the entire Kubernetes cluster. Every piece of cluster state — what Pods exist, what Services are defined, what the desired replica count is, which nodes are registered — is stored in etcd.
It is critical because:
If etcd goes down, the cluster cannot make any new decisions (though running workloads continue until they need rescheduling).
If etcd loses data without a backup, you lose your entire cluster state — all Deployments, Services, ConfigMaps, and Secrets are gone.
For this reason, production clusters run etcd with 3 or 5 members for fault tolerance, and etcd backups are performed regularly. The CKA exam includes etcd backup and restore as a mandatory skill.
It is critical because:
If etcd goes down, the cluster cannot make any new decisions (though running workloads continue until they need rescheduling).
If etcd loses data without a backup, you lose your entire cluster state — all Deployments, Services, ConfigMaps, and Secrets are gone.
For this reason, production clusters run etcd with 3 or 5 members for fault tolerance, and etcd backups are performed regularly. The CKA exam includes etcd backup and restore as a mandatory skill.
🧠 Analogy: etcd is the cluster's long-term memory. Kubernetes components are like the brain's thinking regions — but if the memory (etcd) is wiped, the brain forgets everything: who it is, what it was doing, what it wants. All decisions stop. This is why you protect etcd like you protect a production database.
# Backup etcd — a must-know CKA command
ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/etcd/ca.crt \
--cert=/etc/etcd/server.crt \
--key=/etc/etcd/server.key
Section 4 — Operations & Configuration
10
What is the difference between a liveness probe and a readiness probe?
✅ Answer
Both are health checks defined in your Pod spec that Kubernetes uses to manage container lifecycle — but they answer different questions.
Liveness probe — asks: "Is this container still alive?" If it fails repeatedly, Kubernetes kills and restarts the container. Use it to detect a container that has hung or entered a broken state it cannot recover from on its own (e.g. a deadlock).
Readiness probe — asks: "Is this container ready to receive traffic?" If it fails, Kubernetes removes the Pod from the Service's endpoints — traffic stops being sent to it, but the container is NOT restarted. Use it during startup (app is loading data) or during temporary unavailability (app is processing a heavy job).
Liveness probe — asks: "Is this container still alive?" If it fails repeatedly, Kubernetes kills and restarts the container. Use it to detect a container that has hung or entered a broken state it cannot recover from on its own (e.g. a deadlock).
Readiness probe — asks: "Is this container ready to receive traffic?" If it fails, Kubernetes removes the Pod from the Service's endpoints — traffic stops being sent to it, but the container is NOT restarted. Use it during startup (app is loading data) or during temporary unavailability (app is processing a heavy job).
🏥 Analogy: Imagine a doctor in a hospital. The liveness probe is a heartbeat monitor — if the heart stops, the team performs emergency resuscitation (restart the container). The readiness probe is checking if the doctor is ready to see patients — if they are in surgery, you do not send new patients to their room, but you do not call an emergency either. They are just temporarily unavailable.
💡 Key difference to memorise: Liveness failure → container restarts. Readiness failure → traffic stops, container stays running.
11
How does Kubernetes handle application configuration and secrets?
✅ Answer
Kubernetes provides two objects for externalising configuration from your container images:
ConfigMap — stores non-sensitive configuration data as key-value pairs. Database hostnames, feature flags, log levels, API endpoints. Injected into Pods as environment variables or mounted as files.
Secret — stores sensitive data like passwords, API keys, TLS certificates. Stored base64-encoded in etcd (and encrypted at rest in production clusters). Also injected as environment variables or mounted as files.
The key principle: never bake configuration into your container image. Images should be environment-agnostic — the same image runs in dev and production, just with different ConfigMaps and Secrets injected.
ConfigMap — stores non-sensitive configuration data as key-value pairs. Database hostnames, feature flags, log levels, API endpoints. Injected into Pods as environment variables or mounted as files.
Secret — stores sensitive data like passwords, API keys, TLS certificates. Stored base64-encoded in etcd (and encrypted at rest in production clusters). Also injected as environment variables or mounted as files.
The key principle: never bake configuration into your container image. Images should be environment-agnostic — the same image runs in dev and production, just with different ConfigMaps and Secrets injected.
🎁 Analogy: A ConfigMap is the instruction manual that comes with a product — generic, readable by anyone. A Secret is the product's serial key — it unlocks functionality but you do not share it publicly. Both are kept separate from the product (container image) itself, so you can change them without rebuilding the product.
⚠️ Common interview mistake: Saying "Secrets are encrypted by default." They are not — they are only base64 encoded. Encryption at rest requires explicit cluster configuration (EncryptionConfiguration). Always clarify this distinction.
12
What is a rolling update and how does Kubernetes implement it?
✅ Answer
A rolling update is the default Deployment strategy in Kubernetes. It replaces old Pods with new ones gradually, ensuring that the application never fully goes offline during an update.
Kubernetes implements it by creating a new ReplicaSet for the new version and simultaneously scaling it up while scaling the old ReplicaSet down — one Pod at a time (or in configurable batches). The pace is controlled by two fields:
Setting
Kubernetes implements it by creating a new ReplicaSet for the new version and simultaneously scaling it up while scaling the old ReplicaSet down — one Pod at a time (or in configurable batches). The pace is controlled by two fields:
maxSurge — how many extra Pods above the desired count can exist during the updatemaxUnavailable — how many Pods below the desired count are acceptable during the updateSetting
maxUnavailable: 0 guarantees zero downtime — new Pods must be Ready before old ones are removed.🛤️ Analogy: Imagine replacing the tracks on a train line while trains are still running. You replace one section at a time — the new track is laid, tested, and trains run on it before you remove the old section. At no point does the entire line go offline. That is a rolling update.
# Trigger a rolling update
kubectl set image deployment/my-app app=my-app:v2
# Watch it happen
kubectl rollout status deployment/my-app
# Roll back if something goes wrong
kubectl rollout undo deployment/my-app
13
What happens internally when you run kubectl apply -f deployment.yaml?
✅ Answer
This is a great question to show your understanding of Kubernetes internals. Here is the complete flow:
1.
2. The request hits the API Server — which authenticates the user, authorises the action (RBAC), and validates the object schema.
3. The API Server writes the desired state to etcd.
4. The Deployment Controller (inside Controller Manager) detects the new/changed Deployment and creates or updates a ReplicaSet.
5. The ReplicaSet Controller detects it needs N Pods and creates Pod objects (with no node assigned).
6. The Scheduler detects unscheduled Pods, scores nodes, and assigns each Pod to the best node.
7. The kubelet on each assigned node detects its new Pod assignment and tells the container runtime to pull the image and start the container.
8. kubelet reports status back → API Server updates etcd → you see
1.
kubectl reads the YAML file and converts it to a JSON API request.2. The request hits the API Server — which authenticates the user, authorises the action (RBAC), and validates the object schema.
3. The API Server writes the desired state to etcd.
4. The Deployment Controller (inside Controller Manager) detects the new/changed Deployment and creates or updates a ReplicaSet.
5. The ReplicaSet Controller detects it needs N Pods and creates Pod objects (with no node assigned).
6. The Scheduler detects unscheduled Pods, scores nodes, and assigns each Pod to the best node.
7. The kubelet on each assigned node detects its new Pod assignment and tells the container runtime to pull the image and start the container.
8. kubelet reports status back → API Server updates etcd → you see
Running in kubectl get pods.🏗️ Analogy: You submit a building permit (kubectl apply) to City Hall (API Server). City Hall files it (etcd), assigns a project manager (Deployment Controller), who hires a contractor (ReplicaSet Controller), who calls the construction company (Scheduler + kubelet) to actually build the building (start containers). You just submitted the paperwork — the whole system executes it.
14
What is the difference between resource requests and resource limits in Kubernetes?
✅ Answer
Requests are the minimum resources guaranteed to a container. The Scheduler uses requests to decide which node to place a Pod on — it only picks nodes with enough available resources to satisfy the request. If you set
Limits are the maximum resources a container is allowed to use. If a container tries to exceed its CPU limit, it is throttled. If it exceeds its memory limit, it is killed and restarted (
Always set both in production. Without requests, the Scheduler cannot make good placement decisions. Without limits, one misbehaving container can starve every other Pod on the node.
cpu: 250m, the Scheduler will not place the Pod on a node with less than 250m CPU available.Limits are the maximum resources a container is allowed to use. If a container tries to exceed its CPU limit, it is throttled. If it exceeds its memory limit, it is killed and restarted (
OOMKilled).Always set both in production. Without requests, the Scheduler cannot make good placement decisions. Without limits, one misbehaving container can starve every other Pod on the node.
🍽️ Analogy: You are booking a table at a restaurant. Requests are your reservation — "I need at least a table for 2." The restaurant guarantees this space for you (the Scheduler guarantees resources). Limits are the maximum seats at your table — even if more people show up, you cannot take over the whole restaurant (container cannot exceed limits and starve other tables).
💡 OOMKilled in interviews: If asked "why does my Pod keep restarting?", one common answer is it is exceeding its memory limit. The container is OOMKilled and the kubelet restarts it — causing CrashLoopBackOff.
15
What are labels and selectors in Kubernetes and why are they so important?
✅ Answer
Labels are arbitrary key-value pairs attached to any Kubernetes object — Pods, Services, Nodes, Deployments. They have no meaning to Kubernetes itself — they are purely for humans and other objects to use for organisation and selection.
Selectors are how one Kubernetes object finds another using labels. A Service uses a selector to find its Pods. A Deployment uses a selector to know which Pods it owns. A ReplicaSet uses a selector to count how many Pods it is responsible for.
Labels and selectors are the glue of Kubernetes. They are what make the system loosely coupled — a Service does not care about a Pod's name or IP, it only cares about its labels. This means you can replace, scale, and update Pods freely as long as labels stay consistent.
Selectors are how one Kubernetes object finds another using labels. A Service uses a selector to find its Pods. A Deployment uses a selector to know which Pods it owns. A ReplicaSet uses a selector to count how many Pods it is responsible for.
Labels and selectors are the glue of Kubernetes. They are what make the system loosely coupled — a Service does not care about a Pod's name or IP, it only cares about its labels. This means you can replace, scale, and update Pods freely as long as labels stay consistent.
🏷️ Analogy: Labels are luggage tags at an airport. Every bag (Pod) gets tagged with details — owner, destination, priority. Selectors are the baggage handlers' instructions — "collect all bags tagged destination=NYC, priority=urgent." They do not look up bags by name or belt number — they just match the tag. New bags with the same tag are automatically included.
# Label a Pod manually
kubectl label pod my-pod environment=production
# Select Pods by label
kubectl get pods -l app=nginx
kubectl get pods -l environment=production,app=nginx
📌 Quick Reference — All 15 Questions
- Q1 — Pod vs Container: Container = single process. Pod = wrapper for 1+ containers sharing network + storage.
- Q2 — Deployment vs bare Pod: Deployment adds self-healing, rolling updates, and rollback. Never use bare Pods in production.
- Q3 — ReplicaSet vs Deployment: RS keeps N Pods alive. Deployment manages RS + handles version changes. Always use Deployment.
- Q4 — Auto healing: Reconciliation loop compares desired vs actual state and corrects continuously.
- Q5 — Service types: ClusterIP (internal), NodePort (org), LoadBalancer (internet), ExternalName (DNS alias).
- Q6 — ClusterIP vs NodePort vs LoadBalancer: Additive — each builds on the previous. LB costs cloud money.
- Q7 — Namespace: Virtual cluster partition for team/env separation, resource quotas, and RBAC scoping.
- Q8 — Scheduler: Assigns unscheduled Pods to nodes via filtering + scoring. Never runs containers itself.
- Q9 — etcd: Single source of truth for all cluster state. Loss = cluster amnesia. Always back it up.
- Q10 — Liveness vs Readiness: Liveness fails → restart container. Readiness fails → remove from Service endpoints, no restart.
- Q11 — ConfigMap vs Secret: ConfigMap = non-sensitive config. Secret = sensitive data (base64, not encrypted by default).
- Q12 — Rolling update: New RS scales up, old RS scales down gradually. maxSurge + maxUnavailable control the pace.
- Q13 — kubectl apply flow: kubectl → API Server → etcd → controllers → Scheduler → kubelet → container runtime.
- Q14 — Requests vs Limits: Requests = scheduling guarantee. Limits = usage ceiling. OOM = exceeding memory limit.
- Q15 — Labels & Selectors: Labels are tags on objects. Selectors find objects by tags. The glue that connects Services to Pods.
🚀 Part 2 preview: Next interview post covers advanced topics — Ingress, RBAC, Persistent Volumes, StatefulSets, DaemonSets, HorizontalPodAutoscaler, taints & tolerations, and real troubleshooting scenarios you will face in interviews.
Comments
Post a Comment