DEV Community

Er. Bhupendra
Er. Bhupendra

Posted on • Edited on

KUBERNATES(K8S)

#kubernetes #cloud #infrastructure #devops

Bilkul. Isko ratne ke bajay ek single mental model se samjho. Kubernetes mein ye 4 topics actually ek hi problem solve karte hain:

“Pod ko KAHAN chalana hai, KISKE SAATH/DOOR chalana hai, aur KAUNSE node par allowed hai?”

Aur probes alag problem solve karti hain:

“Pod ke andar application healthy hai ya nahi?”

1. Sabse pehle: Kubernetes Pod ko node par kaise place karta hai?

Maan lo tumhare paas 3 nodes hain:

Node-1        Node-2        Node-3
SSD           HDD           GPU
Enter fullscreen mode Exit fullscreen mode

Aur tumhara pod hai:

booking-service
Enter fullscreen mode Exit fullscreen mode

Kubernetes Scheduler decide karega:

booking-service → Node-1
Enter fullscreen mode Exit fullscreen mode

Ab question hai: Scheduler ko kaise bataoge ki pod ko kis node par bhejna hai?

Yahan Node Affinity aati hai.

2. Node Affinity = "Mujhe KAUNSA NODE chahiye?"

Suppose nodes ke labels:

Node-1:
disk=ssd

Node-2:
disk=hdd

Node-3:
disk=ssd
Enter fullscreen mode Exit fullscreen mode

Tum bolte ho:

"Mera booking-service sirf SSD node par chale."

Then:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: disk
              operator: In
              values:
                - ssd
Enter fullscreen mode Exit fullscreen mode

Ab scheduler dekhega:

Node-1 → disk=ssd ✅
Node-2 → disk=hdd ❌
Node-3 → disk=ssd ✅
Enter fullscreen mode Exit fullscreen mode

Toh pod:

booking-service
      ↓
Node-1 or Node-3
Enter fullscreen mode Exit fullscreen mode

Simple line for interview

Node Affinity tells Kubernetes which nodes a pod should or must run on, based on node labels.

3. Pod Affinity = "Mujhe KAUNSE POD ke PAAS rehna hai?"

Ab scenario change.

Maan lo:

frontend
backend
database
Enter fullscreen mode Exit fullscreen mode

Tum chahte ho:

frontend
   ↓
backend
Enter fullscreen mode Exit fullscreen mode

same zone/node ke close ho.

Yahan tum Pod Affinity use kar sakte ho.

Mental model:

Node Affinity
     ↓
"Which NODE?"

Pod Affinity
     ↓
"Which POD ke NEAR?"
Enter fullscreen mode Exit fullscreen mode

Example:

Node-1
 ├── frontend
 └── backend
Enter fullscreen mode Exit fullscreen mode

Tum bol rahe ho:

"Backend ko frontend pod ke paas rakhna."

Kubernetes matching pod ke labels dekhega.

For example:

labels:
  app: frontend
Enter fullscreen mode Exit fullscreen mode

Then backend ki affinity:

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - frontend
        topologyKey: kubernetes.io/hostname
Enter fullscreen mode Exit fullscreen mode

Meaning:

"Backend pod ko aise node par schedule karo jahan app=frontend wala pod already hai."

4. Pod Anti-Affinity = "Mujhe KAUNSE POD se DOOR rehna hai?"

Ye production mein bahut important hai.

Suppose tumhare paas:

booking-service
replica = 3
Enter fullscreen mode Exit fullscreen mode

Kubernetes theoretically kar sakta hai:

Node-1
 ├── booking-1
 ├── booking-2
 └── booking-3
Enter fullscreen mode Exit fullscreen mode

Problem?

Agar Node-1 down:

Node-1 💥
Enter fullscreen mode Exit fullscreen mode

Toh teenon replicas ek saath gone.

Anti-Affinity bolti hai:

"Mere same application ke pods ko same node par mat rakho."

Result:

Node-1
 └── booking-1

Node-2
 └── booking-2

Node-3
 └── booking-3
Enter fullscreen mode Exit fullscreen mode

Ab:

Node-1 💥
Enter fullscreen mode Exit fullscreen mode

Then:

booking-2 ✅
booking-3 ✅
Enter fullscreen mode Exit fullscreen mode

Application available rahegi.

Example 

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values:
                - booking
        topologyKey: kubernetes.io/hostname
Enter fullscreen mode Exit fullscreen mode

topologyKey yahan important hai.

kubernetes.io/hostname
Enter fullscreen mode Exit fullscreen mode

means:

Same node ke hostname ko topology boundary maan ke spread karo.

5. Affinity ko ek table se yaad rakho

Concept Simple Question
Node Affinity Kaunse node par?
Pod Affinity Kaunse pod ke paas?
Pod Anti-Affinity Kaunse pod se door?

Bas ye 3 line yaad kar lo.

6. Required vs Preferred

Ab ek aur important concept.

Suppose tum bolte ho:

"Booking pod SSD node par hi hona chahiye."

Ye hard requirement hai.

requiredDuringSchedulingIgnoredDuringExecution
Enter fullscreen mode Exit fullscreen mode

Meaning:

Rule follow karna MUST hai.
Enter fullscreen mode Exit fullscreen mode

Agar SSD node available nahi:

Pod → Pending
Enter fullscreen mode Exit fullscreen mode

Preferred

Ab tum bolte ho:

"SSD node better hai, but agar available nahi toh kisi aur node par chala dena."

Then:

preferredDuringSchedulingIgnoredDuringExecution
Enter fullscreen mode Exit fullscreen mode

Meaning:

Try this rule.
But if impossible → other node is okay.
Enter fullscreen mode Exit fullscreen mode

Interview line

Required is a hard scheduling constraint, while preferred is a soft scheduling preference.

7. Ab Taint aur Toleration

Affinity ko samajhne ke baad Taint easy hai.

Affinity mein:

Pod bolta hai: mujhe yahan jaana hai.

Taint mein:

Node bolta hai: mujhe har pod nahi chahiye.

Example:

GPU Node
Enter fullscreen mode Exit fullscreen mode

GPU node expensive hai.

Tum nahi chahte:

random application ❌
frontend ❌
logging ❌
booking ❌
Enter fullscreen mode Exit fullscreen mode

GPU node par chale.

Tum node ko taint kar sakte ho:

kubectl taint nodes gpu-node gpu=true:NoSchedule
Enter fullscreen mode Exit fullscreen mode

Ab node ka attitude:

GPU Node:

❌ Normal Pod
❌ Normal Pod
❌ Normal Pod

✅ GPU workload
Enter fullscreen mode Exit fullscreen mode

8. Toleration = Pod ka permission

Ab GPU pod ko bolo:

"Tum GPU node par ja sakte ho."

Pod mein:

tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
Enter fullscreen mode Exit fullscreen mode

Ab:

GPU Node
   ↑
   │ taint
   │ gpu=true:NoSchedule
   │
GPU Pod
   ↑
   │ toleration
   │
   └── "I tolerate this"
Enter fullscreen mode Exit fullscreen mode

Sabse important point

Toleration ka matlab ye nahi hai ki pod automatically us node par jayega.

Ye sirf bolta hai:

"Mujhe is tainted node par jaane ki permission hai."

Agar tum specifically GPU node select karna chahte ho, toh commonly:

Taint + Toleration
        +
Node Affinity / Node Selector
Enter fullscreen mode Exit fullscreen mode

use karoge.

9. Taint ke 3 Effects

NoSchedule

New pod:

No toleration → ❌
Toleration → ✅
Enter fullscreen mode Exit fullscreen mode

Existing pod normally evict nahi hota just because taint added.

PreferNoSchedule

Kubernetes bolega:

"Is node ko avoid karne ki koshish karo."

But strict rule nahi.

Prefer avoid → yes
Mandatory → no
Enter fullscreen mode Exit fullscreen mode

NoExecute

Ye stronger hai.

New pod without toleration → ❌
Existing pod without toleration → evicted
Enter fullscreen mode Exit fullscreen mode

Mental model:

NoSchedule
= naye pods ko rokna

NoExecute
= naye pods ko rokna
+ existing incompatible pods ko hataana
Enter fullscreen mode Exit fullscreen mode

10. Affinity vs Taint/Toleration

Ye interview mein bahut poocha ja sakta hai.

Affinity

Pod ka perspective:

"Mujhe kis node/pod ke paas jaana hai?"

Taint

Node ka perspective:

"Mere paas kaun nahi aa sakta?"

Toleration

Pod ka permission:

"Main is node ke restriction ko tolerate kar sakta hoon."

11. Ab Probes

Ab tak humne decide kiya:

Pod ko KAHAN run karna hai?
Enter fullscreen mode Exit fullscreen mode

Probes different question poochti hain:

Pod ke ANDAR application ki condition kya hai?
Enter fullscreen mode Exit fullscreen mode

Maan lo:

booking-service Pod
        ↓
Spring Boot application
        ↓
Java process
Enter fullscreen mode Exit fullscreen mode

Container running ho sakta hai, but application broken ho sakti hai.

Example:

Java process → running ✅
Spring Boot → stuck ❌
Enter fullscreen mode Exit fullscreen mode

Kubernetes ko ye pata hona chahiye.

Isliye probes.

12. Liveness Probe

Liveness ka question:

"Application zinda hai?"

Suppose application deadlock mein chali gayi:

Container → Running
Application → Hung
Enter fullscreen mode Exit fullscreen mode

Liveness fail:

Liveness ❌
      ↓
Kubernetes restarts container
      ↓
Application starts again
Enter fullscreen mode Exit fullscreen mode

Mental model 

Liveness = Restart?
Enter fullscreen mode Exit fullscreen mode

Agar liveness fail:

Container restart ho sakta hai.

13. Readiness Probe

Readiness ka question:

"Kya application abhi traffic lene ke liye ready hai?"

Example:

Spring Boot application start ho rahi hai:

Application starting...
       ↓
Database connection
       ↓
Cache connection
       ↓
Kafka initialization
       ↓
Application ready
Enter fullscreen mode Exit fullscreen mode

During startup:

Readiness ❌
Enter fullscreen mode Exit fullscreen mode

Kubernetes service us pod ko traffic nahi bhejegi.

Once:

Readiness ✅
Enter fullscreen mode Exit fullscreen mode

Traffic aa sakta hai.

Mental model 

Readiness = Traffic?
Enter fullscreen mode Exit fullscreen mode

Readiness fail hone par normally:

Pod restart ❌
Traffic to pod ❌
Enter fullscreen mode Exit fullscreen mode

14. Liveness vs Readiness — sabse important

Imagine restaurant.

Liveness

"Restaurant zinda hai?"

Restaurant completely broken hai → restart/recovery required.

Readiness

"Restaurant abhi customers serve kar sakta hai?"

Restaurant alive hai but:

Kitchen preparation chal rahi hai
Enter fullscreen mode Exit fullscreen mode

Then:

Alive ✅
Ready ❌
Enter fullscreen mode Exit fullscreen mode

Customer ko andar nahi bhejna.

15. Startup Probe

Ab ek slow application.

Suppose:

Spring Boot application
Startup time = 90 seconds
Enter fullscreen mode Exit fullscreen mode

Tumne liveness check laga diya:

Liveness starts immediately
Enter fullscreen mode Exit fullscreen mode

20 sec par:

Application → not ready
Liveness → ❌
Enter fullscreen mode Exit fullscreen mode

Kubernetes:

Restart ❌
Enter fullscreen mode Exit fullscreen mode

Again startup.

Again 20 sec.

Again restart.

Ye restart loop ban sakta hai.

Startup probe bolti hai:

"Pehle application ko startup complete karne do."

Startup Probe
     ↓
Application starting
     ↓
Startup successful ✅
     ↓
Liveness starts checking
     ↓
Readiness controls traffic
Enter fullscreen mode Exit fullscreen mode

Mental model 

Startup  = "Start hua?"

Readiness = "Traffic le sakta hai?"

Liveness  = "Zinda hai?"
Enter fullscreen mode Exit fullscreen mode

16. Teeno probes ek saath

Real-world Spring Boot application:

                Pod
                 │
        ┌────────┴────────┐
        │                 │
   Startup Probe     Application
        │
        ↓
"Start ho gaya?"
        │
        ✅
        ↓
 ┌──────┴──────┐
 ↓             ↓
Liveness    Readiness
 ↓             ↓
"Alive?"    "Traffic?"
 ↓             ↓
restart       traffic
if broken     allow/block
Enter fullscreen mode Exit fullscreen mode

17. Ek real EKS example

Suppose tumhari architecture:

AWS EKS
│
├── Node-1
├── Node-2
└── Node-3
     │
     ├── booking-service
     ├── order-service
     └── notification-service
Enter fullscreen mode Exit fullscreen mode

Tum production mein bol sakte ho:

Requirement 1

Booking service sirf high-performance nodes par chale.

Node Affinity
Enter fullscreen mode Exit fullscreen mode

Requirement 2

Booking ke replicas same node par na aayein.

Pod Anti-Affinity
Enter fullscreen mode Exit fullscreen mode

Requirement 3

GPU node sirf ML workloads ke liye reserve hai.

Taint
Enter fullscreen mode Exit fullscreen mode

Requirement 4

ML pod ko GPU node par permission deni hai.

Toleration
Enter fullscreen mode Exit fullscreen mode

Requirement 5

Booking service traffic tabhi le jab application ready ho.

Readiness Probe
Enter fullscreen mode Exit fullscreen mode

Requirement 6

Booking application deadlock ho jaye.

Liveness Probe
Enter fullscreen mode Exit fullscreen mode

Requirement 7

Booking application bahut slowly start hoti hai.

Startup Probe
Enter fullscreen mode Exit fullscreen mode

18. Ekdum final mental map 🧠

Isko interview se pehle bas ye yaad karo:

                 POD SCHEDULING
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   Node Affinity   Pod Affinity   Pod Anti-Affinity
        │              │              │
   WHICH NODE?     NEAR WHICH?     AWAY FROM WHICH?
Enter fullscreen mode Exit fullscreen mode

Aur:

                 NODE RESTRICTION
                       │
                 ┌─────┴─────┐
                 │           │
               Taint     Toleration
                 │           │
          Node says NO    Pod says
          to most pods    "I can enter"
Enter fullscreen mode Exit fullscreen mode

Aur:

                 APPLICATION HEALTH
                        │
             ┌──────────┼──────────┐
             │          │          │
          Startup    Readiness   Liveness
             │          │          │
          "Started?" "Traffic?" "Alive?"
             │          │          │
             └──────────┴──────────┘
Enter fullscreen mode Exit fullscreen mode

🔥 Interview mein 20-second answer

Affinity controls pod placement. Node Affinity selects nodes based on node labels, while Pod Affinity and Anti-Affinity control placement relative to other pods. Taints are applied on nodes to restrict scheduling, and tolerations are applied on pods to allow them to run on tainted nodes. For application health, Startup Probe handles slow startup, Readiness Probe controls whether a pod receives traffic, and Liveness Probe determines whether the container should be restarted.

Ek important correction: tumhare pasted GPU example mein taint gpu=true hai, lekin toleration mein value: "true" hona chahiye. Sirf key: gpu wala example tabhi match karega jab operator/effect configuration uske according ho.

33333333333333333333333333333333333333333333333333333333##################
simple explanatipon

Pod Affinity — ekdum simple

Pod Affinity ka matlab:

“Mere pod ko kisi doosre particular pod ke paas rakhna.”

Example:

Frontend Pod
     ↓
Backend Pod
Enter fullscreen mode Exit fullscreen mode

Tum Kubernetes ko bolte ho:

“Backend ko Frontend ke paas hi run karo.”

Toh Kubernetes try karega:

Node-1
 ├── Frontend Pod
 └── Backend Pod
Enter fullscreen mode Exit fullscreen mode

Kyu use karte hain?

Jab do related pods ko paas rakhna ho.

Example:

  • Backend + Cache
  • Frontend + Backend
  • Application + related service

Yaad rakhne ka shortcut:

Pod Affinity = POD ke paas POD ✅

Node Affinity = POD ko specific NODE ✅

Pod Anti-Affinity = POD ko doosre POD se door ✅

Taint kya hai kyuy hia kis kam ki leye hai

Taint kya hai? — ekdum simple

Taint Node par lagaya jata hai.

Taint ka matlab:

“Is node par normal pods mat bhejo.” 🚫

Kubernetes scheduler ko node bolta hai:

Node
  ↓
"Sab pods ke liye available nahi hoon."
Enter fullscreen mode Exit fullscreen mode

Kyu lagate hain?

Jab tum kisi node ko special purpose ke liye reserve karna chahte ho.

Example:

Node-1 → Normal applications
Node-2 → Normal applications
Node-3 → GPU workload only
Enter fullscreen mode Exit fullscreen mode

Node-3 par taint laga diya:

gpu=true:NoSchedule
Enter fullscreen mode Exit fullscreen mode

Ab normal pod:

Normal Pod
    ↓
GPU Node
    ❌
Enter fullscreen mode Exit fullscreen mode

Lekin jis pod ke paas matching Toleration hai:

GPU Pod
    ↓
GPU Node
    ✅
Enter fullscreen mode Exit fullscreen mode

Simple real-life example 🧠

Socho ek room ke bahar board laga hai:

🚫 “Entry restricted”

Ye Taint hai.

Jiske paas permission hai:

✅ “I have permission.”

Ye Toleration hai.

Interview mein ek line:

Taint is applied to a node to prevent pods from being scheduled there unless they have a matching toleration.

Yaad rakho:

TAINT       → Node par
TOLERATION  → Pod par

Taint       → "Mere paas mat aao"
Toleration  → "Mujhe aane ki permission hai"
Enter fullscreen mode Exit fullscreen mode

TOLERATION jru hai kam kya hai kis leye hai

Toleration kya hai?

Toleration Pod par lagaya jata hai.

Iska simple meaning:

“Mujhe tainted node par run karne ki permission hai.” ✅

Example

Maan lo ek node par Taint laga hai:

GPU Node
Taint: gpu=true:NoSchedule
Enter fullscreen mode Exit fullscreen mode

Iska matlab:

🚫 Normal pods, yahan schedule mat karo.

Ab GPU Pod mein toleration:

tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
Enter fullscreen mode Exit fullscreen mode

Ab Kubernetes dekhta hai:

GPU Node
   │
   │ Taint: gpu=true
   ↓
GPU Pod
   │
   │ Toleration: gpu=true
   ↓
       ✅ Allowed
Enter fullscreen mode Exit fullscreen mode

Kyu use karte hain?

Special node ko special pods ke liye reserve karne ke liye.

Examples:

  • GPU node → sirf ML/GPU workloads
  • Dedicated node → sirf database workloads
  • High-memory node → memory-heavy applications
  • Special hardware node → specific workloads

Sabse important baat ⚠️

Toleration ka matlab “pod ko us node par bhejo” nahi hai.

Toleration sirf bolta hai:

“Agar scheduler mujhe is node par bhejna chahe, toh taint ki wajah se mujhe reject mat karo.”

Agar tum specifically us node par bhejna chahte ho, toh usually Node Affinity/Node Selector + Toleration use karte ho.

Ek line mein yaad karo:

Taint = Node bolta hai “sabko entry nahi.”
Toleration = Pod bolta hai “mujhe entry allowed hai.”

3333333333333333333333333333333333333333333

affiety only related to pods only and taint relatred to node and toleration related to pods

Haan, almost correct, bas ek correction hai:

Concept Kahan lagta hai? Simple meaning
Node Affinity Pod Pod ko specific type ke Node par rakhna
Pod Affinity Pod Pod ko dusre Pod ke paas rakhna
Pod Anti-Affinity Pod Pod ko dusre Pod se door rakhna
Taint Node Node bolta hai “normal Pods yahan mat aao”
Toleration Pod Pod bolta hai “main taint wale Node par aa sakta hoon”

Bas ye yaad rakho 🧠 

AFFINITY
   ├── Node Affinity  → Pod → Node
   ├── Pod Affinity   → Pod → Pod ke paas
   └── Pod Anti       → Pod → Pod se door

TAINT
   ↓
Node → "Mere paas mat aao"

TOLERATION
   ↓
Pod → "Mujhe permission hai"
Enter fullscreen mode Exit fullscreen mode

So Affinity sirf pods ke beech nahi hai — Node Affinity bhi hoti hai, jo pod ko node select karne mein help karti hai.

Ye Kubernetes ka sabse common confusion hai. Service aur kube-proxy dono networking se related hain, lekin dono ka role alag hai.

Simple analogy

Socho ek company hai:

  • Service = Receptionist ☎️

    • Tumhe hamesha ek hi number deti hai.
    • Kaunse employee se connect karna hai, ye decide karti hai.

  • kube-proxy = Security Guard / Traffic Controller 🚦

    • Receptionist ne jis employee ko choose kiya, us tak call physically pahunchata hai.

Kubernetes mein

1. Service

Service ka kaam hai:

  • Pod ke liye stable IP aur DNS name dena.
  • Load balancing karna.
  • Pod change hone par bhi same endpoint dena.

Example:

Pod-1 (10.244.1.2)
Pod-2 (10.244.1.5)
Pod-3 (10.244.2.8)

Service
IP = 10.96.0.10
DNS = my-app.default.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

Application sirf Service ko call karti hai:

http://my-app
Enter fullscreen mode Exit fullscreen mode

Use Pod IP yaad nahi rakhni padti.

2. kube-proxy

kube-proxy har Worker Node par chalta hai.

Uska kaam:

  • Service ke rules ko Node par configure karna.
  • Incoming request ko kisi ek healthy Pod tak pahunchana.
  • iptables/IPVS ke through traffic forward karna.

Flow 

Client
   │
   ▼
Service (Stable IP/DNS)
   │
   ▼
kube-proxy
   │
   ▼
Pod-1
OR
Pod-2
OR
Pod-3
Enter fullscreen mode Exit fullscreen mode

Agar kube-proxy na ho

Service ke paas IP to hoga, lekin request Pod tak kaise jayegi?

Agar Service na ho

Tumhe har Pod ka IP manually use karna padega:

10.244.1.2
10.244.1.5
10.244.2.8
Enter fullscreen mode Exit fullscreen mode

Aur Pod restart hote hi IP badal jayega.

Interview Answer

Q. Service aur kube-proxy mein kya difference hai?

Answer:

Service Kubernetes ka logical abstraction hai jo Pods ke liye stable IP, DNS aur load balancing provide karta hai. kube-proxy har worker node par chalne wala network component hai jo Service ke rules ko implement karta hai aur traffic ko actual Pod tak forward karta hai.

Ek line mein yaad rakho

  • Service = "Kisko request bhejni hai?" (Stable endpoint + load balancing)

* kube-proxy = "Request ko us Pod tak kaise pahunchana hai?" (Traffic forwarding)

Q. Service aur kube-proxy mein kya difference hai?

Answer:

Service Kubernetes ka logical abstraction hai jo Pods ke liye stable IP, DNS aur load balancing provide karta hai. kube-proxy har worker node par chalne wala network component hai jo Service ke rules ko implement karta hai aur traffic ko actual Pod tak forward karta hai.

===================================

What is the role of a node?

In Kubernetes, a node serves as the fundamental foundation or worker machine (either a physical server or a virtual machine) within the cluster where your applications actually run.

Its primary roles include:

  • Hosting Applications: It provides the computing resources (CPU, RAM, and disk) necessary to execute containers.

  • Running Pods: The node hosts pods, which are the smallest deployable units in Kubernetes. These pods contain your application containers and run directly on the node.

  • Cluster Participation: By acting as a worker in the cluster, the node enables the Kubernetes control plane to manage, scale, and monitor the applications deployed across the environment.

What is a pod?

In Kubernetes, a pod is defined as the smallest deployable unit within the cluster (37:13, 2:02:45).

Key characteristics of a pod include:

  • Shared Space: It acts as a wrapper or "room" that houses one or more application containers (37:13, 38:01).
  • Container Hosting: While containers (like those created by Docker) hold your actual application code, they reside inside pods, which handle the networking and storage sharing between them (37:13, 2:03:07).
  • Lifecycle: If a pod fails, the Kubernetes control plane is responsible for managing its state and ensuring the desired number of replicas are running, effectively replacing or restarting it as needed (25:29, 25:45).

What is the difference between a pod and node?
In Kubernetes, understanding the distinction between a node and a pod is foundational to how the system manages applications:

  • Node: A node is the foundation or the physical/virtual worker machine within the cluster (1:37:13 - 1:38:24). You can think of it as the "house" that provides the necessary computing resources like CPU, RAM, and disk space to run your applications (1:37:36 - 1:38:05).
  • Pod: A pod is the smallest deployable unit in Kubernetes (37:13, 2:02:45). It functions as a wrapper or "room" inside the node, housing one or more application containers (37:13, 38:01).

Key Difference: While the node provides the infrastructure and resources, the pod is the object that Kubernetes actually schedules and manages to run your application code (1:38:15, 2:02:05).

Can a pod run without a node?
No, a pod cannot run without a node. In Kubernetes, a node acts as the foundation or the physical/virtual worker machine that provides the necessary CPU, RAM, and disk resources required to execute your applications (1:37:36 - 1:38:24).

A pod is the smallest deployable unit in Kubernetes (2:02:05), but it cannot exist in a vacuum; it must be scheduled and hosted on a node to function. The node is essentially the "house" where the "rooms" (pods) are built, and without the node's underlying infrastructure, the pod has no environment to run in (1:38:15 - 1:38:24).

How does a pod use node resources?

A pod consumes node resources (such as CPU, RAM, and disk space) by running as a process on the underlying worker machine (1:37:36 - 1:38:05). Here is how this relationship works:

  • Allocation: When a pod is scheduled, the Kubernetes scheduler assigns it to a node that has enough available capacity to meet the pod's requirements (1:38:09).
  • Sharing: Since a node can host multiple pods, the node's operating system manages the distribution of hardware resources among them, ensuring each pod has the resources needed to execute its containers (1:37:48).
  • Dependency: The pod is essentially a wrapper for containers, and it relies entirely on the node to provide the compute power to keep those containers running (37:13, 1:38:15).

What happens if a node runs out?

If a node runs out of resources (like CPU or RAM) or goes offline, the Kubernetes control plane detects the failure and intervenes to maintain the application's desired state (25:29, 1:39:09).

Key outcomes include:

  • Automatic Rescheduling: Since Kubernetes manages the replicas of your applications, it will automatically attempt to spin up new pods on healthy nodes within the cluster to replace those that were lost (25:45, 1:39:12).
  • Dependency Management: The control plane, specifically the controller manager, is responsible for observing these changes and taking corrective action to ensure the workload continues running (1:01:14).
  • Pending State: If there are no other healthy nodes with enough available resources to host the required pods, those pods will enter a 'Pending' state until sufficient infrastructure becomes available (2:32:01).

How does Kubernetes know a node failed?
In Kubernetes, the system detects a node failure through continuous communication between the control plane and the worker nodes. Specifically, the kubelet running on each node maintains a constant heartbeat or status update with the API Server (59:12, 2:04:15).

  • Heartbeat Mechanism: The node periodically reports its health status to the API Server. If the API Server stops receiving these status updates or signals from the node's kubelet for a predefined duration, it considers the node unreachable or failed (2:04:17 - 2:04:30).
  • Control Plane Intervention: Once the control plane (the 'receptionist' of the cluster) determines that communication is lost, it marks the node as unhealthy. It then takes action to maintain the desired state of the application by rescheduling the pods that were running on that node onto other available, healthy nodes in the cluster (25:29, 1:39:09).

What is the role of the kubelet?
The kubelet acts as the essential agent running on each worker node within a Kubernetes cluster (2:08:58 - 2:09:00). Its primary roles include:

  • Node-to-Control Plane Communication: It maintains a constant heartbeat with the API Server to report the health status of its specific node (59:12, 2:04:15).
  • Workload Management: It ensures that the containers described in the Pod specifications are actually running and healthy on the node (2:09:00, 2:09:48).
  • Execution Oversight: It interacts with the Container Runtime Interface (CRI) to manage the lifecycle of the containers, effectively bridging the gap between the desired state set by the control plane and the actual state on the worker machine (1:04:09 - 1:05:01).

What happens if the kubelet fails?
If the kubelet on a worker node fails, it loses the ability to report its health status to the API Server (2:04:15). Because the kubelet is responsible for the ongoing heartbeat signal, the Kubernetes control plane will eventually determine the node is unreachable or unhealthy (59:12, 2:04:17).

When this communication breakdown occurs:

  • Node Status Change: The cluster controller will mark the node as 'NotReady' (2:04:30).
  • Workload Rescheduling: To maintain the desired state of your applications, the control plane will initiate the process of rescheduling the pods that were running on the failed node onto other healthy nodes within the cluster (25:29, 1:39:09).
  • Operational Impact: While existing pods on other healthy nodes continue to run unaffected, the failed node can no longer receive new instructions, perform scaling, or manage local container lifecycles (2:05:14, 2:06:13).

Does control plane failure stop pods?

No, a control plane failure does not stop existing pods from running. The worker nodes and the pods they host continue to operate normally even if the control plane is unreachable (2:04:44 - 2:06:10).

Think of the control plane like a receptionist; if the receptionist is away, the work inside the building continues uninterrupted. However, you will be unable to:

  • Create or scale new resources or pods (2:05:32).
  • Restart or replace pods that crash or fail (2:05:24).
  • Manage cluster updates or configuration changes (2:05:43).

What components are in the control plane?
The Kubernetes control plane (often called the master node) acts as the "brain" of the cluster, responsible for managing the state and orchestration of your applications. Its key components include:

  • API Server: The central hub and the only component that communicates with all other parts of the cluster (59:05, 59:27). It handles authentication, authorization, and validation of all requests.
  • etcd: The cluster's "memory" or database, which stores all configuration data, state information, and records of cluster activity (1:07:37).
  • Scheduler: Responsible for watching for newly created pods and assigning them to an appropriate, healthy worker node based on resource availability (like CPU/memory) and affinity rules (1:07:15, 2:25:32).
  • Controller Manager: The "manager" that ensures the actual state of the cluster matches the desired state. It includes various controllers like the Deployment Controller and ReplicaSet Controller (1:01:30, 2:25:29).
  • Cloud Controller Manager: Used specifically in cloud environments (like AWS, GKE, or Azure), this component manages interactions with the cloud provider's APIs, such as provisioning load balancers or storage volumes (1:26:16, 1:29:58).

What is the role of etcd?
In a Kubernetes cluster, etcd acts as the crucial "brain" or central memory/database (1:07:37). Its primary roles include:

  • Storing State: It serves as the primary data store for all cluster configuration data, state information, and records of cluster activity (1:07:37, 2:33:07).
  • Maintaining Consistency: It ensures the cluster has a single source of truth regarding what is currently running and what the desired state of the applications should be (2:33:07).
  • Supporting Operations: It allows the API Server to record and retrieve data essential for cluster management and orchestration (59:15, 2:33:07).

Essentially, if the cluster's state changes, etcd is where that change is finalized and stored to ensure the system can recover or maintain its configuration.

Can etcd fail without stopping pods?

Yes, if etcd fails, existing pods continue to run. The speaker explains that the worker nodes and their running applications operate independently of the control plane components, meaning that even if the cluster's memory or database (etcd) becomes unreachable, the active workloads remain unaffected (2:04:44 - 2:06:10).

However, while existing pods stay active, a failure of etcd prevents the cluster from making any changes to the desired state. This means you would be unable to scale your applications, create new resources, or manage configuration updates until the control plane is restored (2:05:24 - 2:06:13).

What happens when etcd fails?
According to the speaker, an etcd failure has the following consequences on a Kubernetes cluster:

  • Existing pods remain unaffected: The speaker explains that worker nodes and their running applications operate independently from the control plane components. Therefore, if the cluster's memory or database (etcd) becomes unreachable, active workloads will continue to run without interruption (2:04:44 - 2:06:10).
  • Impact on cluster operations: While existing pods stay active, an etcd failure prevents the cluster from making any modifications to the desired state. This means you will be unable to scale applications, create new resources, or manage configuration updates until the control plane is restored (2:05:24 - 2:06:13).

Can the cluster recover from etcd failure?
The video explains that if an etcd failure occurs, it results in the loss of the cluster's "memory" or database, which prevents the cluster from managing the desired state (1:07:37). While existing pods will continue to run because worker nodes operate independently of the control plane (2:04:44 - 2:06:10), the cluster cannot automatically perform new operations, such as scaling, creating resources, or managing configuration updates (2:05:24 - 2:06:13).

The speaker notes that recovery depends on the environment. For managed services like EKS, the cloud provider handles the underlying infrastructure and control plane stability (1:13:17 - 1:13:31). For on-premise clusters, recovery requires manual intervention or a pre-established disaster recovery strategy, as users are responsible for the control plane and data persistence (1:16:20 - 1:16:49, 1:22:09 - 1:22:24).

How is cluster state stored?
The cluster state is stored within etcd, which acts as the central memory or database for the entire Kubernetes cluster (1:07:37).

Key functions of etcd include:

  • Single Source of Truth: It holds all configuration data, current status, and records of cluster activity, ensuring the system has a consistent view of the desired state versus the actual state (2:33:07).
  • Supporting Operations: The API Server relies on etcd to store and retrieve data whenever a change occurs or a new resource is requested (59:15, 2:33:07).
  • Consistency: By acting as the cluster's "brain," it finalizes any state changes, allowing the system to maintain or recover its configuration reliably (1:07:37).

Can etcd be backed up manually?
Whether you can manually back up etcd depends on your environment:

  • Managed Kubernetes (EKS, GKE, AKS): You typically do not have direct access to the etcd server to run manual snapshot commands (1:16:20-1:16:47). In these environments, the cloud provider manages the underlying etcd snapshots, though you can use tools like Velero to back up your cluster resources and application data to object storage like S3 (1:12:20-1:14:14).

  • On-Premises/Self-Managed Kubernetes: If you manage your own clusters, you generally have full access to the etcd server and can perform manual backups using snapshots, provided you follow the cluster's specific administrative procedures (1:07:37, 1:16:20).

In both cases, it is common practice to use third-party tools like Velero to automate and manage cluster-wide backups rather than relying on manual etcd snapshots alone (1:13:39-1:14:01).

Can I see my cluster's etcd data?
The video explains that in managed Kubernetes environments like EKS, GKE, or AKS, you generally do not have direct access to the etcd server or its underlying database files (1:16:20 - 1:16:47). Because the cloud provider manages these components as part of their service, users typically cannot perform manual snapshots or directly query the etcd data (1:16:49 - 1:17:04). However, for on-premise or self-managed clusters, the user maintains full administrative control over the infrastructure, which allows for direct access to the etcd server (1:16:20 - 1:16:35).

Who manages etcd in managed clusters?

In managed Kubernetes environments (such as EKS, GKE, or AKS), the cloud service provider is responsible for managing the etcd server (1:16:20 - 1:17:04).

Because the provider handles the maintenance, availability, and automated backups of the etcd data to ensure cluster stability, users do not have direct access to the etcd server (1:16:20 - 1:16:47). Consequently, you cannot perform manual snapshot commands or directly modify the underlying database.

How do I back up my cluster data?

The video explains that the approach to backing up your cluster data depends on your environment:

  • Managed Kubernetes (e.g., EKS, GKE, AKS): You typically do not have direct access to the etcd server to perform manual snapshot commands (1:16:20 - 1:16:47). In these cases, the cloud provider manages maintenance and backups of the etcd database. However, you can use third-party, open-source tools like Velero to back up your cluster resources and application data to cloud storage like S3 (1:12:20 - 1:14:14).

  • On-Premises / Self-Managed: If you manage your own cluster, you generally have full access to the etcd server and can perform manual backups using snapshots, as you are responsible for the infrastructure maintenance (1:07:37, 1:16:20).

Why don't I control etcd in cloud?
In managed Kubernetes environments like EKS, GKE, or AKS, the cloud service provider is responsible for managing the etcd server to ensure cluster stability and availability (1:16:20 - 1:17:04).

Users do not have direct access to the etcd server primarily because:

  • Managed Responsibility: The cloud provider handles all maintenance, uptime, and automated backups of the etcd data as part of the managed service agreement (1:16:20).
  • System Integrity: By restricting direct control, the provider prevents accidental misconfigurations or data corruption that could compromise the entire cluster's state or the

Can I access etcd on-premises?
Yes, if you are running an on-premises or self-managed Kubernetes cluster, you generally have full access to the etcd server (1:07:37). This allows you to perform manual operations, such as running snapshot commands for backups, because you are responsible for managing the underlying infrastructure and the database directly (1:16:20).

Is etcd different in cloud environments?
Yes, how you interact with etcd differs significantly between managed cloud environments and self-managed (on-premises) setups.

  • Managed Cloud Clusters (EKS, GKE, AKS): You do not have direct access to the etcd server (1:16:20-1:16:47). The cloud provider is responsible for managing, maintaining, and automatically backing up the database to ensure the cluster's state and availability (1:16:20-1:17:04). Because you lack direct access, you cannot run manual snapshot commands or modify the database directly.
  • On-Premises / Self-Managed: You generally have full access to the etcd server (1:07:37). You are responsible for managing the underlying infrastructure, which includes performing your own manual backups and snapshot operations when necessary (1:16:20).

Why restrict etcd access in cloud?
In managed cloud Kubernetes environments (such as EKS, GKE, or AKS), you do not have direct access to the etcd server primarily to ensure system integrity and cluster stability (1:16:20 - 1:17:04).

  • Managed Responsibility: The cloud service provider manages, maintains, and performs automated backups of etcd as part of the managed service agreement, taking the operational burden off the user (1:16:20).
  • Prevention of Corruption: By restricting access, the provider prevents users from accidentally misconfiguring or corrupting the underlying database, which could compromise the entire state of the Kubernetes cluster (1:16:20 - 1:16:56).

Because of this, users cannot execute manual snapshot commands, as the cloud provider handles these tasks automatically behind the scenes (1:16:40).

How are backups handled in EKS?

In managed Kubernetes services like EKS, the cloud provider handles the maintenance and automated backups of the etcd database to ensure cluster stability (1:16:20 - 1:17:04). Because you do not have direct access to the etcd server in a managed environment, you cannot perform manual snapshot commands or modify the database directly (1:16:20 - 1:16:47).

However, for backing up your application data and Kubernetes objects, organizations often use third-party tools like Velero (1:12:20 - 1:12:44). Velero can be used to take backups of your cluster resources and store them in an external destination, such as an S3 bucket (1:12:55 - 1:14:14).

what is role of node pod container cluster in diff each other

In Kubernetes, these components are nested in a hierarchy, each playing a specific role to manage your applications effectively:

  • Cluster: This is the entire environment or the "big picture." It consists of a set of machines (nodes) that work together to run your containerized applications (13:10, 52:00).
  • Node: These are the individual machines (virtual or physical) within the cluster. They provide the computing power (CPU and memory) needed to run your workloads (41:37, 52:29).
  • Pod: This is the smallest deployable unit in Kubernetes. A pod acts as a wrapper or a "shield" for your containers. You typically run one or more containers inside a pod, and they share the same network and storage (37:13, 37:46).
  • Container: This is where your actual application code runs. It packages the software, libraries, and dependencies needed for your app to function. You create containers using tools like Docker or other containerization engines (46:46, 50:28).

To visualize their relationship:
Think of a Cluster as a large apartment building. A Node is a specific room in that building. A Pod is like a person or a small group staying in that room, and the Containers are the tasks or activities that the person is performing (42:11-42:56).

node provider ya machine itself?

In the context of Kubernetes, a Node represents the machine itself—the physical server or virtual machine that provides the computing resources (CPU and memory) to run your applications (41:37, 52:29).

While a cloud provider (like AWS or Google Cloud) is responsible for provisioning or managing these machines (especially in managed services like EKS or GKE), the Node itself is the individual worker unit within the Kubernetes cluster that performs the actual tasks (52:41, 54:44). You can think of the node as the hardware foundation, whereas the cloud provider is the entity that supplies and hosts that hardware for you.

What is a control plane node?

A control plane node acts as the "brain" of your Kubernetes cluster (59:08). It is responsible for managing the state of the cluster, making global decisions, and handling events (59:12).

Key components that reside on the control plane node include:

  • API Server: The central hub that acts as a receptionist for all communications within the cluster (59:08-59:31).
  • etcd: The cluster's "brain" or database that stores the state and configuration of all objects (1:07:37-1:07:44).
  • Scheduler: Decides which work needs to be done and which nodes are suitable to host specific tasks (1:07:15).
  • Control Manager: Responsible for monitoring the state of the cluster and ensuring the actual state matches the desired configuration (1:02:04, 1:09:39).

How does the API server handle communication?
The API server acts as the central hub and the "receptionist" for a Kubernetes cluster (56:53, 59:08). All communications and commands—whether from users running kubectl commands or from internal components—must pass through it (55:36, 1:07:32).

When a request is received, the API server handles several critical steps:

  • Authentication: Verifying the identity of the requester (2:33:01).
  • Authorization: Checking if the user has the permissions to perform the requested action (2:33:02).
  • Validation: Ensuring the request follows the correct configuration format (2:33:03).
  • State Management: It interacts with etcd, the cluster's "brain" or database, to store the desired state of the cluster (2:33:06).

Essentially, no action occurs in the cluster without the API server first validating the request and recording the intent in etcd (2:33:00 - 2:33:10).

What is the role of the scheduler?

The Scheduler in Kubernetes is responsible for deciding which specific worker node (a machine or virtual server) should host a particular Pod (1:03:03-1:03:05).

Think of it as the person who determines exactly where each resource belongs. Once the Control Manager has determined that a new Pod needs to be created, the Scheduler evaluates the available nodes and applies various rules to ensure the Pod is placed on the most suitable machine based on resource availability and other constraints (1:03:37-1:04:00).

What happens if the API server fails?

If the API Server fails, the central communication hub of the Kubernetes cluster stops functioning. Since the API server is the "receptionist" for all commands (56:53, 59:08), its failure has significant consequences:

  • No new operations: You cannot use kubectl to deploy new applications, update existing ones, or change the cluster's state because these requests must pass through the API server first (55:36, 1:07:32).
  • Control plane isolation: Internal components like the Scheduler and Controller Manager lose their ability to interact with etcd (2:33:06), effectively halting the cluster's ability to maintain the desired state.
  • Existing workloads continue: Fortunately, applications (Pods) already running on your worker nodes will generally continue to function because they have already been scheduled and are being managed locally by the Kubelet (2:01:31).

Essentially, the cluster enters a read-only state where you cannot manage it until the API server is restored.

How does the scheduler pick a node?
The Scheduler picks a node by evaluating which available worker node (a virtual machine or server) is best suited to host a specific Pod (1:03:03-1:03:05).

It performs this task by applying a set of rules, such as:

  • Resource Availability: Checking if the node has enough CPU and memory to run the application (1:03:37).
  • Constraints and Policies: Evaluating specific placement rules or requirements to ensure the Pod is positioned on the most optimal machine (1:04:00).

Essentially, the Scheduler acts like a person deciding exactly which seat is best for a new worker based on the specific job requirements and the current capacity of the workspace.

What if no nodes are available?
If no worker nodes are available in your Kubernetes cluster to host a new application, the Pod will still be created, but it will remain in a pending state (2:32:01-2:32:06).

Because the Scheduler cannot find a machine that meets the required resource criteria, the Pod simply waits until a node with sufficient capacity becomes available (2:32:08).

Does the scheduler talk to nodes directly?

No, the Scheduler does not talk to the worker nodes directly. Following the central communication design of Kubernetes, every component and operation must pass through the API server (59:08, 1:07:32).

Think of the API server as the central receptionist (56:53). The Scheduler informs the API server of its decision regarding which node a Pod should be placed on, and then the API server coordinates with the Kubelet on that specific node to execute the deployment (1:05:26-1:05:40).

Can I manually choose a node?

Yes, while the Scheduler (1:03:03-1:04:30) is responsible for automatically deciding where a Pod should be placed based on resource availability and constraints, you can manually influence this process.

In Kubernetes, you can use Node Selectors or Node Affinity to guide the scheduler's decision, effectively letting you specify or restrict which nodes a particular application can be deployed to (1:42:00). This is useful when you have specific hardware requirements, such as needing to run a task on a specific machine with a GPU or a specific type of storage.

While the Scheduler still performs the final placement, it respects the constraints and labels you define for your nodes and pods.

Can the API server work offline?
The API Server relies on consistent connectivity with etcd (its database) to manage the cluster's state (1:15:30). While individual components like the Kubelet on worker nodes can continue running existing workloads if the connection to the control plane is temporarily lost (2:01:31), the API server itself requires active network and database access to function correctly and process new commands or maintain the cluster's desired state.

In essence, while the applications it manages can persist through transient outages, the Kubernetes control plane—anchored by the API server—is designed to operate as a cohesive, networked system rather than in an isolated, offline mode.

============================================

==============================================

How does node auto-scaling work in EKs?

In Amazon EKS, node auto-scaling is managed by Node Groups, which act as a blueprint for launching EC2 instances to handle your Kubernetes workloads. The scaling process functions as follows:

  • Launch Templates & Auto Scaling Groups: A Node Group configuration creates a Launch Template and an Auto Scaling Group (ASG) behind the scenes (2:30:46). This ASG manages the actual lifecycle of your EC2 instances.
  • Desired Capacity: You define a range—Minimum, Maximum, and Desired capacity—for your nodes. If your applications require more resources than available, the Auto Scaling Group triggers the creation of new EC2 instances to scale out based on these settings (2:12:12, 2:17:36).
  • Instance Management: When you update your node configuration (like changing the EC2 instance type), the Launch Template is updated. The ASG then manages the replacement of old nodes with new ones according to the updated template (2:30:46, 2:31:02).
  • Constraint Awareness: You can create separate Node Groups for specific application needs (e.g., CPU-intensive vs. RAM-intensive). By using Taints, Tolerations, and Labels/Selectors, you ensure your Pods are scheduled onto the appropriate Node Group (2:20:26, 2:43:31).

What are taints and tolerations?
The video explains that taints and tolerations are mechanisms used to define how Pods are scheduled onto specific Nodes within a cluster. They act as a filtering system: if a Node has a taint, it will repel any Pod that does not have a matching toleration to accept or "tolerate" that taint (2:43:31 - 2:44:00).

When should I use taints?

The video explains that taints are used to restrict pods from being scheduled on specific nodes unless the pods have a corresponding toleration. This mechanism is particularly useful when you want to dedicate nodes to specific types of workloads—for instance, if you have a node group with high-performance hardware that should only run CPU-intensive applications, you can apply a taint to those nodes so that only specifically configured pods can access them (2:43:31 - 2:44:00).

How do I add a toleration?

To schedule a Pod onto a node that has a specific taint, you must define a corresponding toleration in the Pod manifest. This effectively tells the Kubernetes scheduler that the Pod is allowed to "tolerate" the effect applied by the node's taint (2:43:31).

Key concepts for configuration:

  • Taint: Applied to a node to repel pods that do not have a matching toleration.
  • Toleration: A configuration within the Pod specification that matches the key, value, and effect defined by the taint.

When a node is "tainted" (e.g., to reserve it for specific workloads, like CPU-intensive tasks), any Pod without the correct matching toleration will be prevented from being scheduled on that node. By adding the toleration, you grant the Pod permission to ignore that specific taint and land on the node (2:43:31 - 2:44:00).

What are Kubernetes taints?

In Kubernetes, a taint is a setting applied to a node that effectively 'repels' pods. It marks the node as reserved or unsuitable for certain workloads, preventing pods from scheduling there unless they explicitly have a matching toleration (2:43:31).

Think of it like a specialized sorting system for your infrastructure:

  • Purpose: You use taints to ensure that specific, resource-intensive or specialized applications (like CPU-heavy tasks) land only on nodes equipped to handle them, keeping them away from nodes reserved for other types of work (2:20:26).
  • The Mechanism: A taint acts as a constraint. If a pod does not have the corresponding toleration defined in its manifest, the Kubernetes scheduler will refuse to place that pod on the tainted node (2:43:31).
  • Node Groups: When setting up multiple node groups—for example, one group optimized for memory and another for CPU—you define these constraints at the node group level to keep your clusters organized and efficient (2:43:31).

Can one node have many taints?

The provided video transcript explains that you can apply multiple taints to a node to set complex constraints for scheduling pods. By using combinations of taints and tolerations, you can effectively filter which workloads are allowed to run on specific nodes, ensuring that only pods with the corresponding matching tolerations can be scheduled there (2:43:31 - 2:44:00).

How do pods match multiple taints?

The video explains that to allow a Pod to be scheduled on a node with multiple constraints, you must define multiple tolerations within the Pod manifest. Each toleration must match the specific key, value, and effect of the corresponding taint applied to the node. This configuration informs the Kubernetes scheduler that the Pod is explicitly permitted to land on that node despite the applied taints (2:43:31 - 2:44:00).

What is the effect of a taint?

The provided video transcript introduces taints as a mechanism to reserve nodes for specific workloads by preventing pods from scheduling on them unless the pods possess a matching toleration (2:43:31 - 2:44:00). While the transcript explains the conceptual use of taints for grouping resources—such as dedicating high-performance nodes to CPU-intensive tasks—it does not explicitly detail the specific technical 'effects' (like NoSchedule, PreferNoSchedule, or NoExecute). The speaker focuses on the practical application of taints and tolerations as a way to control workload placement within an EKS environment.

Why use taints for resource management?
In Kubernetes, taints are essential for precise workload management and infrastructure control. They act as a repelling mechanism, ensuring that only specific Pods can be scheduled on certain Nodes (2:43:31).

Here is why they are critical for your cluster:

  • Workload Isolation: You can reserve specific nodes for high-demand tasks (e.g., CPU-intensive or memory-heavy applications) by tainting those nodes, effectively preventing generic workloads from utilizing those resources (2:20:26, 2:43:31).
  • Infrastructure Organization: When managing diverse node groups, taints help enforce clear boundaries. For example, if you have one node group optimized for a particular environment, taints ensure your pods land only on the nodes you intended for them (2:43:31).
  • Forced Compatibility: Taints create a gatekeeper system. Unless a Pod has a matching toleration defined in its manifest, the Kubernetes scheduler will refuse to place it on the tainted node, ensuring that only pods explicitly designed to handle the underlying infrastructure land there (2:43:31-2:44:00).

Can a pod ignore a node taint?

Yes, a Pod can ignore a Node taint by using a toleration (2:43:31). A taint acts as a barrier or repelling mechanism, preventing pods from being scheduled on a node unless they are specifically permitted to land there (2:43:31).

By defining a toleration in the Pod's configuration that matches the key, value, and effect of the node's taint, you grant the Pod permission to "tolerate" that taint, effectively allowing it to bypass the restriction and be scheduled onto the node anyway (2:43:31 - 2:44:00).

How do I create a node taint?

In Kubernetes, you create a node taint using the kubectl taint command. This command applies a restriction to a specific node, preventing pods from being scheduled there unless they have a corresponding toleration (2:43:31).

Basic Syntax:
kubectl taint nodes <node-name> key=value:<effect>

  • Key/Value: Defines the specific identifier for the taint.
  • Effect: Determines how the node handles pods that do not have a matching toleration. Common effects include:
    • NoSchedule: Prevents new pods from being scheduled on the node.
    • PreferNoSchedule: Avoids placing pods on the node if possible, but it is not a hard requirement.
    • NoExecute: Evicts existing pods from the node if they do not tolerate the taint.

By using this command, you can effectively isolate workloads and ensure that only specifically permitted applications run on your infrastructure (2:43:31 - 2:44:00).

How do I define a toleration?

To define a toleration in Kubernetes, you add a tolerations section to your Pod manifest (YAML file). This configuration allows the Pod to be scheduled onto a node that has a matching taint.

Standard Configuration:

You specify the key, operator, value, and effect that match the taint applied to the node (2:43:31).

yaml
tolerations:

  • key: "key-name" operator: "Equal" value: "value-name" effect: "NoSchedule"

Key components:

  • key/value: These must match the key and value assigned to the node's taint exactly.
  • operator: Usually set to Equal (the default) to match a specific value, or Exists if you want to tolerate a key regardless of its value.
  • effect: This dictates how the pod interacts with the taint (e.g., NoSchedule, PreferNoSchedule, or NoExecute) (2:43:31).

By including this in your manifest, you effectively grant the Pod permission to ignore the node's restriction and land on that infrastructure (2:43:31 - 2:44:00).

How do I check existing node taints?

To view the taints currently applied to your Kubernetes nodes, you can inspect the node's configuration using the kubectl command-line tool.

Command to list taints:

To see the taints for a specific node, use:
kubectl describe node <node-name> | grep Taints

To list the taints for all nodes in your cluster at once, you can run:
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

What to look for:

  • The output will display the Key, Value, and Effect for any applied taints.
  • If a node returns no output for taints, it means there are currently no restrictions preventing pods from being scheduled there (2:43:31).

Can I see taints in the dashboard?

Yes, you can manage and view node configurations, including taints, through the AWS Management Console for Amazon EKS.

In the video, the presenter demonstrates that when creating or managing a Node Group within your cluster, you can navigate to the Compute tab to see the configuration details for your worker nodes (2:23:48, 2:55:46).

While the console provides a dashboard interface for these settings, remember that taints, along with labels and tags, are explicitly defined and verified during the node group creation process (2:19:20). If you need to verify these details in real-time or perform advanced troubleshooting, using the kubectl CLI (e.g., kubectl describe node) remains the most direct and reliable method (2:24:57).

How do I add taints using the console?

=======================================================

  1. Namespace
  2. Labels & Selectors
  3. Pods
  4. ReplicaSet
  5. Deployment
  6. Services
  7. Service Discovery (DNS)
  8. Ingress
  9. Ingress Controller
  10. ConfigMap
  11. Secret
  12. Jobs
  13. CronJobs
  14. StatefulSet
  15. DaemonSet
  16. Networking
  17. Network Policies
  18. NGINX
  19. Istio

====================================
This is the right way to master Kubernetes.

Don't study these topics separately. Think of Kubernetes as a company.

Internet
   │
Ingress Controller (NGINX / Istio Gateway)
   │
Ingress
   │
Service (ClusterIP)
   │
Pods
   │
Deployment / StatefulSet / DaemonSet / Job
   │
Node
   │
Cluster
Enter fullscreen mode Exit fullscreen mode

Master Roadmap

Learn in this order.

1. Namespace
2. Labels & Selectors
3. Pods
4. ReplicaSet
5. Deployment
6. Services
7. Service Discovery (DNS)
8. Ingress
9. Ingress Controller
10. ConfigMap
11. Secret
12. Jobs
13. CronJobs
14. StatefulSet
15. DaemonSet
16. Networking
17. Network Policies
18. NGINX
19. Istio
Enter fullscreen mode Exit fullscreen mode

We start with ONLY ONE topic.

Topic 1 — Namespace (100% Interview Level)

What is Namespace?

A Namespace is a logical partition inside one Kubernetes Cluster.

Think of it like folders inside Windows.

Laptop

Projects
Photos
Movies
Music
Enter fullscreen mode Exit fullscreen mode

Similarly,

Cluster

default
dev
qa
uat
prod
monitoring
logging
Enter fullscreen mode Exit fullscreen mode

Each namespace isolates resources.

Why Namespace?

Suppose your company has

Backend Team

Frontend Team

DevOps Team

Data Team
Enter fullscreen mode Exit fullscreen mode

Without Namespace

Everyone creates pods.

pod1
pod2
pod3
pod4
Enter fullscreen mode Exit fullscreen mode

Very messy.

With Namespace

Backend Namespace

auth-service
payment-service
user-service
Enter fullscreen mode Exit fullscreen mode 
Frontend Namespace

react-ui
angular-ui
Enter fullscreen mode Exit fullscreen mode 
Monitoring Namespace

grafana
prometheus
Enter fullscreen mode Exit fullscreen mode

Everything stays organized.

Real Company Example

Amazon

Cluster

production

    payment
    orders
    shipping
    users
    monitoring
    logging
Enter fullscreen mode Exit fullscreen mode

Netflix

Cluster

recommendation

streaming

billing

analytics
Enter fullscreen mode Exit fullscreen mode

Google

Cluster

gmail

maps

photos

ads
Enter fullscreen mode Exit fullscreen mode

Default Namespaces

Every cluster already contains

default

kube-system

kube-public

kube-node-lease
Enter fullscreen mode Exit fullscreen mode

default

Used if you don't specify Namespace.

kubectl get pods
Enter fullscreen mode Exit fullscreen mode

Looks inside default namespace.

kube-system

Contains Kubernetes components.

CoreDNS

kube-proxy

scheduler

controller-manager

etcd
Enter fullscreen mode Exit fullscreen mode

Never delete.

Interview question.

kube-public

Public resources.

Rarely used.

kube-node-lease

Stores node heartbeat.

Used internally.

Commands

Create Namespace

kubectl create namespace dev
Enter fullscreen mode Exit fullscreen mode

OR

kubectl create ns dev
Enter fullscreen mode Exit fullscreen mode

See namespaces

kubectl get ns
Enter fullscreen mode Exit fullscreen mode

Delete namespace

kubectl delete ns dev
Enter fullscreen mode Exit fullscreen mode

Deletes EVERYTHING inside.

Interview favorite.

Create pod inside namespace

kubectl apply -f pod.yaml -n dev
Enter fullscreen mode Exit fullscreen mode

or

metadata:
  namespace: dev
Enter fullscreen mode Exit fullscreen mode

inside YAML.

See pods

kubectl get pods -n dev
Enter fullscreen mode Exit fullscreen mode

See all namespaces

kubectl get pods -A
Enter fullscreen mode Exit fullscreen mode

or

kubectl get pods --all-namespaces
Enter fullscreen mode Exit fullscreen mode

Real YAML 

apiVersion: v1

kind: Namespace

metadata:
  name: production
Enter fullscreen mode Exit fullscreen mode

Apply

kubectl apply -f namespace.yaml
Enter fullscreen mode Exit fullscreen mode

Can Pods communicate across Namespace?

Yes.

Nothing blocks communication.

Only DNS changes.

Example

payment pod

Namespace
payment
Enter fullscreen mode Exit fullscreen mode 
user pod

Namespace
users
Enter fullscreen mode Exit fullscreen mode

Can communicate.

Interview favorite.

DNS

Suppose Service

auth-service

Namespace

backend
Enter fullscreen mode Exit fullscreen mode

DNS becomes

auth-service.backend.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

Short name

auth-service
Enter fullscreen mode Exit fullscreen mode

works only inside same namespace.

Why Namespace is NOT Security

Many freshers say

Namespace provides security.

Wrong.

Namespace only separates resources.

Security comes from

RBAC

Network Policies

OPA

Service Accounts
Enter fullscreen mode Exit fullscreen mode

Very common interview trap.

Namespace vs Cluster 

Cluster

Namespaces

Pods

Services

Deployments
Enter fullscreen mode Exit fullscreen mode

Namespace is NOT another cluster.

It's inside cluster.

Can same Pod name exist?

Yes.

dev

nginx
Enter fullscreen mode Exit fullscreen mode 
prod

nginx
Enter fullscreen mode Exit fullscreen mode

Allowed.

Can same Service exist?

Yes.

dev/payment
Enter fullscreen mode Exit fullscreen mode 
prod/payment
Enter fullscreen mode Exit fullscreen mode

Allowed.

Can same Deployment exist?

Yes.

Different namespaces.

Resource Quotas

Namespace can limit

CPU

Memory

Pods

Storage

Example

Development

CPU

2 Core
Enter fullscreen mode Exit fullscreen mode

Production

CPU

100 Core
Enter fullscreen mode Exit fullscreen mode

Limit Range

Can force

Minimum CPU

Maximum CPU

Memory Limit
Enter fullscreen mode Exit fullscreen mode

per Pod.

Interview Cross Questions (with Answers)

Q1. Why use Namespace?

Answer: To logically isolate applications, organize resources, apply RBAC, quotas, and policies without creating separate clusters.

Q2. Does Namespace provide security?

Answer: No. Namespace is for logical isolation. Security is enforced through RBAC, Network Policies, Service Accounts, and admission controls.

Q3. Can Pods in different namespaces communicate?

Answer: Yes, by default they can, unless Network Policies restrict the traffic.

Q4. What happens if you delete a Namespace?

Answer: All namespaced resources (Pods, Services, Deployments, ConfigMaps, Secrets, etc.) inside that namespace are deleted.

Q5. Can two namespaces have the same Deployment name?

Answer: Yes. Resource names only need to be unique within the same namespace.

Q6. Which namespace contains CoreDNS?

Answer: kube-system.

Q7. Which resources are not inside a namespace?

Answer: Examples include Nodes, PersistentVolumes (PVs), Namespaces themselves, and StorageClasses—they are cluster-scoped.

Q8. Can a Pod belong to multiple namespaces?

Answer: No. A Pod belongs to exactly one namespace.

Q9. Is Namespace a physical isolation?

Answer: No. It's a logical partition within the same cluster.

Q10. Why not create separate clusters instead of namespaces?

Answer: Separate clusters increase cost, operational complexity, upgrades, and maintenance. Namespaces allow multiple environments or teams to share the same cluster efficiently.

Common Interview Scenario

Interviewer: Your company has Development, QA, UAT, and Production. Will you create four Kubernetes clusters?

Answer: Not necessarily. If workloads and security requirements allow, I would use one cluster with separate namespaces (dev, qa, uat, prod), along with RBAC, ResourceQuotas, LimitRanges, and Network Policies. Separate clusters are typically used when stronger isolation, compliance, or independent lifecycle management is required.

Next Topic

The next topic should be Labels & Selectors, because almost every Kubernetes object (Deployments, Services, ReplicaSets, Network Policies, etc.) depends on labels. Once you master Labels & Selectors, the rest of Kubernetes becomes much easier to understand.

===============================================
Excellent. This is the most important topic in Kubernetes.

If you don't understand Labels & Selectors, you will never fully understand Deployments, ReplicaSets, Services, Network Policies, or Istio. Almost every Kubernetes object uses them.

Topic 2 — Labels & Selectors (Master Level)

First understand the problem

Suppose your company has 10,000 Pods.

payment-v1-abc
payment-v1-def
payment-v2-xyz
order-v1-aaa
order-v2-bbb
user-v1-ccc
inventory-v1-ddd
inventory-v2-eee
...
Enter fullscreen mode Exit fullscreen mode

Now imagine a Service needs to send traffic only to payment Pods.

How will Kubernetes know which Pods belong to the payment application?

Not by Pod name.

It uses Labels.

What is a Label?

A Label is simply a key-value pair attached to a Kubernetes object.

Think of it like a tag.

Example:

metadata:
  labels:
    app: payment
    env: production
    version: v1
Enter fullscreen mode Exit fullscreen mode

Here,

app = payment
env = production
version = v1
Enter fullscreen mode Exit fullscreen mode

These labels identify the Pod.

Real-world analogy

Imagine an employee ID card.

Employee Name

Rahul
Enter fullscreen mode Exit fullscreen mode

This is not enough.

The company also stores attributes:

Department = Finance

Location = Bangalore

Role = Manager

Experience = 8 Years
Enter fullscreen mode Exit fullscreen mode

These are like Kubernetes labels.

Kubernetes Object with Labels 

apiVersion: v1
kind: Pod

metadata:
  name: payment

  labels:
    app: payment
    env: prod
    version: v1

spec:
  containers:
  - name: payment
    image: nginx
Enter fullscreen mode Exit fullscreen mode

The labels are just metadata. They do not change how the Pod runs, but other resources use them to find the Pod.

Can Labels be anything?

Yes.

Examples:

team=backend

team=frontend

app=payment

owner=devops

release=stable

country=india

version=v2
Enter fullscreen mode Exit fullscreen mode

Bad labels:

abc=123

xyz=qwerty
Enter fullscreen mode Exit fullscreen mode

These don't describe anything meaningful.

Why Labels?

Without labels,

Imagine 50,000 Pods.

A Service cannot identify which Pods belong to which application.

Labels solve this.

Service Example

Pods

payment-1

payment-2

payment-3

order-1

order-2
Enter fullscreen mode Exit fullscreen mode

Labels

payment-1

app=payment
Enter fullscreen mode Exit fullscreen mode 
payment-2

app=payment
Enter fullscreen mode Exit fullscreen mode 
payment-3

app=payment
Enter fullscreen mode Exit fullscreen mode 
order-1

app=order
Enter fullscreen mode Exit fullscreen mode 
order-2

app=order
Enter fullscreen mode Exit fullscreen mode

Now Service says

selector:
  app: payment
Enter fullscreen mode Exit fullscreen mode

Kubernetes automatically picks

payment-1

payment-2

payment-3
Enter fullscreen mode Exit fullscreen mode

What is Selector?

A Selector is a filter.

It searches objects based on labels.

Think SQL.

Table

Pod App
payment1 payment
payment2 payment
order1 order

Query

SELECT *

FROM Pods

WHERE app='payment'
Enter fullscreen mode Exit fullscreen mode

Result

payment1

payment2
Enter fullscreen mode Exit fullscreen mode

Selector works exactly like the WHERE clause.

Selector Example

Pod

metadata:
  labels:
    app: payment
Enter fullscreen mode Exit fullscreen mode

Service

selector:
  app: payment
Enter fullscreen mode Exit fullscreen mode

Result

Service

↓

payment Pods
Enter fullscreen mode Exit fullscreen mode

Multiple Labels

Pod

labels:
  app: payment
  version: v2
  env: production
Enter fullscreen mode Exit fullscreen mode

Selector

selector:
  app: payment
  version: v2
Enter fullscreen mode Exit fullscreen mode

Both conditions must match.

This is logical AND.

Real Company Example

Amazon

Payment Pods

app=payment

env=prod

version=v2

team=backend
Enter fullscreen mode Exit fullscreen mode

Order Pods

app=order

env=prod

version=v1

team=backend
Enter fullscreen mode Exit fullscreen mode

Monitoring Pods

app=grafana

env=prod

team=devops
Enter fullscreen mode Exit fullscreen mode

Now,

A Service for payment

selector:
  app: payment
Enter fullscreen mode Exit fullscreen mode

Only payment Pods receive traffic.

Label vs Pod Name

Wrong approach

payment-v1-asdf123
Enter fullscreen mode Exit fullscreen mode

Tomorrow after restart

payment-v1-jkhd872
Enter fullscreen mode Exit fullscreen mode

Pod names change frequently.

Labels remain consistent.

Never depend on Pod names.

Commands

View labels

kubectl get pods --show-labels
Enter fullscreen mode Exit fullscreen mode

View one Pod

kubectl describe pod payment
Enter fullscreen mode Exit fullscreen mode

Add label

kubectl label pod payment app=payment
Enter fullscreen mode Exit fullscreen mode

Update label

kubectl label pod payment version=v2 --overwrite
Enter fullscreen mode Exit fullscreen mode

Delete label

kubectl label pod payment version-
Enter fullscreen mode Exit fullscreen mode

Filter Pods

kubectl get pods -l app=payment
Enter fullscreen mode Exit fullscreen mode

Multiple labels

kubectl get pods -l app=payment,env=prod
Enter fullscreen mode Exit fullscreen mode

Equality-based Selector 

selector:
  app: payment
Enter fullscreen mode Exit fullscreen mode

Equivalent to:

app = payment
Enter fullscreen mode Exit fullscreen mode

Set-based Selector

Used for advanced filtering.

Example:

matchExpressions:

- key: env

  operator: In

  values:

  - prod

  - qa
Enter fullscreen mode Exit fullscreen mode

Meaning:

env IN (prod, qa)
Enter fullscreen mode Exit fullscreen mode

Another

operator: NotIn
Enter fullscreen mode Exit fullscreen mode

Means

NOT IN
Enter fullscreen mode Exit fullscreen mode

Exists

operator: Exists
Enter fullscreen mode Exit fullscreen mode

Means

Has this label.
Enter fullscreen mode Exit fullscreen mode

DoesNotExist

operator: DoesNotExist
Enter fullscreen mode Exit fullscreen mode

Means

This label should not exist.
Enter fullscreen mode Exit fullscreen mode

matchLabels vs matchExpressions

Deployment

selector:
  matchLabels:
    app: payment
Enter fullscreen mode Exit fullscreen mode

Simple equality.

Advanced

selector:

  matchExpressions:

  - key: env

    operator: In

    values:

    - prod

    - qa
Enter fullscreen mode Exit fullscreen mode

Who uses Selectors?

Almost every important Kubernetes resource:

  • ReplicaSet
  • Deployment
  • Service
  • NetworkPolicy
  • PodDisruptionBudget
  • HorizontalPodAutoscaler (indirectly targets workloads)
  • Some monitoring and service mesh tools also rely on labels

Very Important Rule

Deployment

selector:
  matchLabels:
    app: payment
Enter fullscreen mode Exit fullscreen mode

Pod template

labels:
  app: payment
Enter fullscreen mode Exit fullscreen mode

These must match.

If they don't,

The Deployment cannot manage its Pods correctly.

Common Mistake

Deployment

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

Pod

labels:

  app: order
Enter fullscreen mode Exit fullscreen mode

Deployment will not manage that Pod because the selector doesn't match.

Real Interview Scenario

Deployment

selector:
  matchLabels:
    app: payment
Enter fullscreen mode Exit fullscreen mode

Pod labels

app=order
Enter fullscreen mode Exit fullscreen mode

Question: What happens?

Answer: The Deployment (through its ReplicaSet) does not recognize or manage that Pod because the selector and labels don't match.

Cross Questions & Answers

Q1. What is a Label?

A key-value pair attached to a Kubernetes object for identification and grouping.

Q2. What is a Selector?

A filter that selects Kubernetes objects based on their labels.

Q3. Can two Pods have the same label?

Yes. In fact, that's the normal case. Multiple Pods belonging to the same application usually share the same labels.

Q4. Can a Pod have multiple labels?

Yes.

Example:

app=payment
env=prod
version=v2
team=backend
Enter fullscreen mode Exit fullscreen mode

Q5. Does Kubernetes use Pod names or labels for Services?

Labels.

Services select Pods using label selectors.

Q6. Can labels change after a Pod is created?

Yes. Labels are mutable, although changing them on running Pods should be done carefully because Services, ReplicaSets, and other resources may immediately change which Pods they manage.

Q7. What happens if a Service selector matches no Pods?

The Service still exists and gets a ClusterIP, but it has no endpoints, so traffic sent to it cannot reach any Pods.

Q8. Difference between Labels and Annotations?

Labels Annotations
Used for selection and grouping Used for additional metadata
Small, identifying information Can store larger descriptive information
Queried by selectors Not used by selectors

Q9. What are matchLabels and matchExpressions?

  • matchLabels is used for exact key-value matching.
  • matchExpressions supports advanced operators like In, NotIn, Exists, and DoesNotExist.

Q10. Why are labels considered the backbone of Kubernetes?

Because Deployments, ReplicaSets, Services, Network Policies, monitoring tools, and service meshes all use labels to identify and manage workloads.

Next Topic

The next logical topic is Pods. Once you understand Pods, we'll connect them to ReplicaSets, then Deployments, and you'll see how the entire Kubernetes workload model fits together.

Perfect. Now we reach the heart of Kubernetes.

Everything in Kubernetes is ultimately about managing Pods.

Important: In real companies, you almost never create Pods directly. You create Deployments, StatefulSets, Jobs, etc., and they create Pods for you. But to master Kubernetes, you must first master Pods.

Topic 3 — Pods (Master Level)

What is a Pod?

A Pod is the smallest deployable unit in Kubernetes.

Kubernetes does not deploy containers directly.
It deploys Pods, and Pods contain one or more containers.

Kubernetes
      │
      ▼
    Pod
      │
 ┌──────────┐
 │Container │
 └──────────┘
Enter fullscreen mode Exit fullscreen mode

Biggest Interview Mistake

❌ Wrong

Kubernetes runs Docker containers.

✅ Correct

Kubernetes schedules and manages Pods. Containers run inside Pods.

Why do we need Pods?

Suppose Kubernetes managed containers directly.

Node

Container1
Container2
Container3
Enter fullscreen mode Exit fullscreen mode

Now imagine one container needs:

  • Shared storage
  • Shared network
  • Shared lifecycle
  • Shared IP

Managing them separately becomes difficult.

So Kubernetes introduced Pods.

Think of a Pod as a House

A container is like a person.

A Pod is like a house.

House (Pod)

Father (Container)

Mother (Container)

Child (Container)
Enter fullscreen mode Exit fullscreen mode

They all share:

  • Same address
  • Same Wi-Fi
  • Same electricity
  • Same storage (if configured)

Similarly, containers inside a Pod share:

  • IP address
  • Network namespace
  • Volumes
  • Lifecycle

Pod Architecture 

Cluster

 Node

   Pod

      Container

      Container

      Volume
Enter fullscreen mode Exit fullscreen mode

Can a Pod contain multiple containers?

Yes.

Example:

Pod

Payment Application

Logging Sidecar

Monitoring Sidecar
Enter fullscreen mode Exit fullscreen mode

This is called a multi-container Pod.

Single Container Pod

Most common.

Pod

Spring Boot
Enter fullscreen mode Exit fullscreen mode

Multi-container Pod 

Pod

Spring Boot

Fluent Bit (logs)

Envoy Proxy (Istio)
Enter fullscreen mode Exit fullscreen mode

These containers work together as one unit.

Why multiple containers?

Example

Spring Boot Application

↓

Writes logs

↓

Fluent Bit

↓

Elasticsearch
Enter fullscreen mode Exit fullscreen mode

Instead of putting logging code into your application, a sidecar container collects and forwards logs.

Other examples:

  • Istio Envoy sidecar
  • Log shippers
  • Security agents

Every Pod Gets One IP

Suppose

Node

Pod1

Pod2

Pod3
Enter fullscreen mode Exit fullscreen mode

IPs

Pod1 → 10.244.1.2

Pod2 → 10.244.1.3

Pod3 → 10.244.1.4
Enter fullscreen mode Exit fullscreen mode

Notice:

Containers do NOT get separate IPs.

The Pod gets one IP.

Containers inside a Pod 

Pod IP

10.244.1.2

Container A

Container B
Enter fullscreen mode Exit fullscreen mode

Both containers use the same Pod IP.

Communication inside Pod

Container A

↓

localhost
Enter fullscreen mode Exit fullscreen mode

↓

Container B

Why?

Because they share the same network namespace.

This is a favorite interview question.

Pod-to-Pod Communication 

Pod A

10.244.1.2

↓

Pod B

10.244.2.5
Enter fullscreen mode Exit fullscreen mode

Pods communicate directly using Pod IPs.

However, applications should usually communicate through Services, because Pod IPs change when Pods are recreated.

Pod Lifecycle 

Pending

↓

Running

↓

Succeeded

↓

Failed

↓

Unknown
Enter fullscreen mode Exit fullscreen mode

Pending

Pod accepted.

Still downloading image or waiting to be scheduled.

Running

Container started successfully.

Succeeded

Job completed successfully.

Example

Backup completed.
Enter fullscreen mode Exit fullscreen mode

Failed

Container exited with error.

Unknown

Node lost communication.

Pod Restart Policy

Three policies:

Always

OnFailure

Never
Enter fullscreen mode Exit fullscreen mode

Default

Always
Enter fullscreen mode Exit fullscreen mode

Pod YAML 

apiVersion: v1

kind: Pod

metadata:
  name: payment

  labels:
    app: payment

spec:

  containers:

  - name: payment

    image: nginx

    ports:

    - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Create Pod 

kubectl apply -f pod.yaml
Enter fullscreen mode Exit fullscreen mode

Get Pods 

kubectl get pods
Enter fullscreen mode Exit fullscreen mode

Detailed Information 

kubectl describe pod payment
Enter fullscreen mode Exit fullscreen mode

Pod Logs 

kubectl logs payment
Enter fullscreen mode Exit fullscreen mode

Multi-container Pod

kubectl logs payment -c fluentbit
Enter fullscreen mode Exit fullscreen mode

Execute inside Pod 

kubectl exec -it payment -- bash
Enter fullscreen mode Exit fullscreen mode

or

kubectl exec -it payment -- sh
Enter fullscreen mode Exit fullscreen mode

Delete Pod 

kubectl delete pod payment
Enter fullscreen mode Exit fullscreen mode

What happens after deleting a Pod?

Case 1: Standalone Pod 

Pod

↓

Delete

↓

Gone forever
Enter fullscreen mode Exit fullscreen mode

Case 2: Deployment created Pod 

Deployment

↓

ReplicaSet

↓

Pod

↓

Delete Pod

↓

ReplicaSet creates a new Pod automatically
Enter fullscreen mode Exit fullscreen mode

This is one of the most common interview questions.

Init Containers

Run before application containers.

Example:

Init Container

↓

Download configuration

↓

Exit

↓

Spring Boot starts
Enter fullscreen mode Exit fullscreen mode

Useful for setup tasks like waiting for a database or preparing files.

Sidecar Container

Runs alongside the main application.

Spring Boot

+

Fluent Bit
Enter fullscreen mode Exit fullscreen mode

OR

Spring Boot

+

Envoy Proxy
Enter fullscreen mode Exit fullscreen mode

Ephemeral Containers

Used mainly for debugging.

Example:

kubectl debug
Enter fullscreen mode Exit fullscreen mode

Creates a temporary container to inspect a running Pod without modifying the application container.

Pod Networking

Every Pod can talk to every other Pod by default (unless restricted by Network Policies).

Payment

↓

Orders

↓

Users
Enter fullscreen mode Exit fullscreen mode

All can communicate.

Pod Storage

Without volumes:

Restart

↓

All files lost
Enter fullscreen mode Exit fullscreen mode

Because the container filesystem is ephemeral.

With a Volume:

Restart

↓

Data remains (depending on volume type)
Enter fullscreen mode Exit fullscreen mode

Important Interview Concept

Pods are ephemeral.

If a Pod dies,

Kubernetes creates a new Pod, not repairs the old one.

The new Pod:

  • Gets a new UID
  • May get a new IP
  • May run on a different node

This is why Services are used instead of Pod IPs.

Pod vs Container

Pod Container
Kubernetes object Runtime process
Can contain multiple containers Single application/process
Gets an IP Shares Pod IP
Managed by Kubernetes Managed by container runtime (containerd/CRI-O)

Pod vs VM

Pod VM
Shares host OS kernel Own guest OS
Starts in seconds Takes longer to boot
Lightweight Heavier
Lower resource usage Higher resource usage

Real Company Example 

Amazon Checkout

Deployment

↓

Pods

↓

Spring Boot

↓

Istio Envoy Sidecar

↓

Fluent Bit Sidecar
Enter fullscreen mode Exit fullscreen mode

One Pod may contain:

  • Main application container
  • Service mesh proxy
  • Logging sidecar

Common Interview Questions & Answers

Q1. What is a Pod?

The smallest deployable unit in Kubernetes. It contains one or more containers that share networking and storage.

Q2. Can a Pod have multiple containers?

Yes. Containers inside the same Pod share the network namespace, IP address, and can share volumes.

Q3. Does every container get an IP?

No. The Pod gets one IP, and all containers inside the Pod share it.

Q4. How do containers inside the same Pod communicate?

Using localhost, because they share the same network namespace.

Q5. Should applications communicate using Pod IPs?

No. Pod IPs are temporary. Applications should communicate using Kubernetes Services.

Q6. What happens if a Pod created by a Deployment is deleted?

The ReplicaSet created by the Deployment detects that the desired number of replicas is lower than expected and creates a replacement Pod.

Q7. Are Pods permanent?

No. Pods are ephemeral and can be recreated with new identities and IPs.

Q8. What is an Init Container?

A container that runs to completion before the application containers start.

Q9. What is a Sidecar Container?

A helper container that runs alongside the main application, commonly used for logging, proxies, or monitoring.

Q10. Why doesn't Kubernetes deploy containers directly?

Pods provide a shared execution environment (network, storage, lifecycle) and are the abstraction Kubernetes uses for scheduling and management.

What's Next?

The next topic is ReplicaSet.

This answers one of the most important questions in Kubernetes:

If a Pod dies, who creates the new Pod?

Understanding ReplicaSets is the foundation for understanding Deployments, rolling updates, self-healing, and high availability.

Excellent. Now we're entering the part that interviewers love.

Topic 4 — ReplicaSet (Master Level)

If someone asks only one Kubernetes question in an interview, there's a high chance it will involve ReplicaSets or Deployments.

The Problem ReplicaSet Solves

Imagine you have one Pod.

Node

┌─────────────┐
│ payment-pod │
└─────────────┘
Enter fullscreen mode Exit fullscreen mode

Everything is fine.

Now suddenly,

Server Crash

OR

Node Failure

OR

OOMKilled

OR

Someone runs

kubectl delete pod payment-pod
Enter fullscreen mode Exit fullscreen mode

The Pod is gone.

Node

❌ No Pod
Enter fullscreen mode Exit fullscreen mode

Question:

Who creates the new Pod?

Answer:

ReplicaSet

What is a ReplicaSet?

A ReplicaSet ensures that the desired number of Pod replicas are always running.

Example

Desired replicas

3
Enter fullscreen mode Exit fullscreen mode

Current Pods

payment-1

payment-2

payment-3
Enter fullscreen mode Exit fullscreen mode

Everything is healthy.

One Pod crashes.

payment-1

payment-2

❌ payment-3
Enter fullscreen mode Exit fullscreen mode

ReplicaSet notices:

Desired = 3
Current = 2

Immediately it creates a new Pod.

payment-1

payment-2

payment-4
Enter fullscreen mode Exit fullscreen mode

Notice:

The new Pod is not payment-3.

It's a completely new Pod with a new name, UID, and usually a new IP.

Real Company Example

Suppose Amazon Checkout Service.

Desired replicas:

50 Pods
Enter fullscreen mode Exit fullscreen mode

Current:

49 Running
Enter fullscreen mode Exit fullscreen mode

ReplicaSet immediately creates:

checkout-50
Enter fullscreen mode Exit fullscreen mode

Users never notice because Kubernetes heals itself.

This is called Self-Healing.

ReplicaSet Architecture 

Deployment
      │
      ▼
 ReplicaSet
      │
      ▼
 Pods
Enter fullscreen mode Exit fullscreen mode

Important:

In production,

You almost never create ReplicaSets directly.

Deployments create ReplicaSets automatically.

ReplicaSet YAML 

apiVersion: apps/v1

kind: ReplicaSet

metadata:
  name: payment-rs

spec:

  replicas: 3

  selector:
    matchLabels:
      app: payment

  template:

    metadata:
      labels:
        app: payment

    spec:

      containers:

      - name: payment

        image: nginx
Enter fullscreen mode Exit fullscreen mode

Understanding Every Field

replicas 

replicas: 3
Enter fullscreen mode Exit fullscreen mode

Meaning:

"I always want 3 Pods."

selector 

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

ReplicaSet looks for Pods having

app=payment
Enter fullscreen mode Exit fullscreen mode

template

The template is the blueprint.

Whenever ReplicaSet needs a new Pod,

It uses this template.

Think of it as a photocopy machine.

Original

↓

Copy

↓

New Pod

Self-Healing Demo

Initial

ReplicaSet

Desired = 3

payment1

payment2

payment3
Enter fullscreen mode Exit fullscreen mode

Delete Pod

kubectl delete pod payment1
Enter fullscreen mode Exit fullscreen mode

Immediately

ReplicaSet

payment2

payment3

payment4
Enter fullscreen mode Exit fullscreen mode

No manual work.

Scaling

Current

replicas: 3
Enter fullscreen mode Exit fullscreen mode

Update

replicas: 6
Enter fullscreen mode Exit fullscreen mode

ReplicaSet creates

payment1

payment2

payment3

payment4

payment5

payment6
Enter fullscreen mode Exit fullscreen mode

Decrease

replicas: 2
Enter fullscreen mode Exit fullscreen mode

ReplicaSet deletes extra Pods.

Commands

Create

kubectl apply -f replicaset.yaml
Enter fullscreen mode Exit fullscreen mode

View

kubectl get rs
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe rs payment-rs
Enter fullscreen mode Exit fullscreen mode

Delete

kubectl delete rs payment-rs
Enter fullscreen mode Exit fullscreen mode

Scale

kubectl scale rs payment-rs --replicas=5
Enter fullscreen mode Exit fullscreen mode

ReplicaSet Uses Labels

Pods

payment1

app=payment
Enter fullscreen mode Exit fullscreen mode 
payment2

app=payment
Enter fullscreen mode Exit fullscreen mode

ReplicaSet

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

ReplicaSet owns these Pods.

Dangerous Situation

Suppose

ReplicaSet

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

Someone manually creates another Pod

labels:

  app: payment
Enter fullscreen mode Exit fullscreen mode

ReplicaSet thinks

"This Pod belongs to me."

It may adopt the Pod if the labels match and no other controller owns it.

What Happens if Labels Don't Match?

ReplicaSet

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

Pod

labels:

  app: order
Enter fullscreen mode Exit fullscreen mode

ReplicaSet ignores it.

ReplicaSet vs ReplicationController

Older Kubernetes used

ReplicationController
Enter fullscreen mode Exit fullscreen mode

Now

ReplicaSet
Enter fullscreen mode Exit fullscreen mode

ReplicaSet supports more advanced selectors (matchExpressions) and is the recommended controller.

Interview answer:

ReplicaSet replaced ReplicationController because it supports richer label selection and integrates with Deployments.

ReplicaSet vs Deployment

ReplicaSet

✅ Keeps Pods alive

Deployment

✅ Creates ReplicaSet

✅ Rolling Update

✅ Rollback

✅ Version History

✅ Zero Downtime Deployment

Deployment is a higher-level controller that manages ReplicaSets.

ReplicaSet Lifecycle 

ReplicaSet

↓

Creates Pods

↓

Pod dies

↓

Creates new Pod

↓

Pod dies

↓

Creates new Pod
Enter fullscreen mode Exit fullscreen mode

This continues as long as the ReplicaSet exists.

Does ReplicaSet Monitor Container Health?

Not directly.

ReplicaSet watches the Pod count, not application health.

Application health is usually checked using:

  • Liveness Probe
  • Readiness Probe
  • Startup Probe

These can cause Pods to restart or be replaced, and ReplicaSet ensures the desired number of Pods still exist.

Real Production Example

Netflix

Recommendation Service

ReplicaSet

Desired = 500 Pods

Current = 499

↓

Automatically creates one more Pod

↓

500 Running
Enter fullscreen mode Exit fullscreen mode

No engineer needs to log in and start a Pod manually.

Interview Scenario

Interviewer:

"I deleted one Pod."

kubectl delete pod payment-xyz
Enter fullscreen mode Exit fullscreen mode

Question:

Who creates the new Pod?

Correct answer:

If the Pod is managed by a ReplicaSet (usually through a Deployment), the ReplicaSet detects the missing replica and creates a replacement Pod from its Pod template.

Common Interview Questions

Q1. What is ReplicaSet?

A Kubernetes controller that ensures the specified number of Pod replicas are running.

Q2. Can ReplicaSet create Pods?

Yes.

It creates Pods using the Pod template defined in its specification.

Q3. Can ReplicaSet update Pods?

No.

ReplicaSet is primarily responsible for maintaining the desired number of Pods. Rolling updates and version management are handled by Deployments.

Q4. What happens if a Pod crashes?

ReplicaSet detects that the actual number of Pods is less than the desired number and creates a replacement Pod.

Q5. What happens if a Node crashes?

The Pods on that node are lost. Kubernetes eventually recognizes they're gone, and the ReplicaSet creates replacement Pods on healthy nodes (assuming cluster capacity is available).

Q6. Does ReplicaSet use Pod names?

No.

It identifies Pods using label selectors.

Q7. Can two ReplicaSets manage the same Pod?

Ideally, no.

Overlapping selectors can cause conflicts, so selectors should be designed to avoid managing the same Pods.

Q8. Can we create ReplicaSet directly?

Yes.

But in production, it's uncommon. Deployments are the standard way because they provide updates, rollbacks, and revision history.

Q9. Is ReplicaSet responsible for load balancing?

No.

Load balancing is handled by a Service. ReplicaSet only maintains the desired number of Pods.

Q10. Why doesn't ReplicaSet perform rolling updates?

Because that's the responsibility of the Deployment controller, which manages ReplicaSets and coordinates safe updates.

Flow So Far 

Namespace
      │
Labels
      │
Pods
      │
ReplicaSet
Enter fullscreen mode Exit fullscreen mode

The next step is Deployment, which sits above ReplicaSets and introduces rolling updates, rollbacks, scaling, and zero-downtime application releases.

Once you master Deployments, you'll understand how production Kubernetes applications are actually managed.

Excellent. Now we reach one of the most important networking topics in Kubernetes.

If you don't understand Services, you cannot understand Ingress, Istio, Service Discovery, or Kubernetes Networking.

Topic 6 — Services (Master Level)

First Understand the Problem

Suppose you have a Deployment.

Deployment
     │
ReplicaSet
     │
Pods

payment-abc123   IP:10.244.1.2
payment-def456   IP:10.244.1.3
payment-ghi789   IP:10.244.1.4
Enter fullscreen mode Exit fullscreen mode

Everything works.

Now one Pod crashes.

ReplicaSet creates another Pod.

Old Pod

payment-def456

IP = 10.244.1.3

↓

Deleted

↓

New Pod

payment-xyz111

IP = 10.244.2.7
Enter fullscreen mode Exit fullscreen mode

Question:

If another application was calling

10.244.1.3
Enter fullscreen mode Exit fullscreen mode

What happens?

❌ Communication breaks.

Because Pod IPs are not permanent.

Why Services Exist

A Service provides

  • Stable IP
  • Stable DNS name
  • Load Balancing
  • Service Discovery

Instead of talking to Pods,

Applications talk to the Service.

Real Company Example

Amazon

Order Service

↓

Payment Service

↓

Inventory Service
Enter fullscreen mode Exit fullscreen mode

Order Service NEVER calls

10.244.5.9
Enter fullscreen mode Exit fullscreen mode

Instead

payment-service
Enter fullscreen mode Exit fullscreen mode

This always works.

What is a Service?

A Service is a Kubernetes object that provides a stable network endpoint for a group of Pods.

Think of it like a receptionist.

Customers don't call employees directly.

They call reception.

Reception forwards the call.

Architecture

Without Service

Order Pod

↓

Payment Pod

10.244.1.3
Enter fullscreen mode Exit fullscreen mode

Pod dies.

Communication breaks.

With Service

Order Pod

↓

Payment Service

↓

Payment Pod1

Payment Pod2

Payment Pod3
Enter fullscreen mode Exit fullscreen mode

Pods can change.

Service never changes.

Service Uses Labels

Pods

labels:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Service

selector:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Service automatically finds all matching Pods.

Service YAML 

apiVersion: v1

kind: Service

metadata:

  name: payment-service

spec:

  selector:

    app: payment

  ports:

  - port: 80

    targetPort: 8080

  type: ClusterIP
Enter fullscreen mode Exit fullscreen mode

Understanding Every Field

selector 

selector:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Find Pods having

app=payment
Enter fullscreen mode Exit fullscreen mode

port 

port: 80
Enter fullscreen mode Exit fullscreen mode

Service listens on

80
Enter fullscreen mode Exit fullscreen mode

targetPort 

targetPort: 8080
Enter fullscreen mode Exit fullscreen mode

Forward traffic to

Container Port

8080
Enter fullscreen mode Exit fullscreen mode

Flow

Client

↓

Service Port

80

↓

Container Port

8080
Enter fullscreen mode Exit fullscreen mode

Important Interview Question

Difference

port
Enter fullscreen mode Exit fullscreen mode

vs

targetPort
Enter fullscreen mode Exit fullscreen mode

Answer

port

→ Service Port

targetPort

→ Container Port

Service Flow 

Order Pod

↓

payment-service

↓

Pod1

↓

Container:8080
Enter fullscreen mode Exit fullscreen mode

Does Service Send Traffic To One Pod?

No.

It load balances.

Example

3 Pods

payment1

payment2

payment3
Enter fullscreen mode Exit fullscreen mode

Requests

Req1 → payment1

Req2 → payment2

Req3 → payment3

Req4 → payment1
Enter fullscreen mode Exit fullscreen mode

The exact algorithm depends on the networking implementation (for example, kube-proxy with iptables/IPVS), but traffic is distributed across healthy endpoints.

ClusterIP

Default Service.

type: ClusterIP
Enter fullscreen mode Exit fullscreen mode

Accessible only inside cluster.

Example

Payment

↓

Inventory

↓

Orders
Enter fullscreen mode Exit fullscreen mode

Microservices communicate.

Users cannot access it directly.

Architecture

Internet

❌

ClusterIP

↓

Pods
Enter fullscreen mode Exit fullscreen mode

NodePort

Expose Service on every Node.

Example

type: NodePort
Enter fullscreen mode Exit fullscreen mode

Port

30000-32767
Enter fullscreen mode Exit fullscreen mode

Access

NodeIP:30080
Enter fullscreen mode Exit fullscreen mode

Example

http://35.10.10.10:30080
Enter fullscreen mode Exit fullscreen mode

Useful for testing, but not the preferred production entry point.

Architecture

Internet

↓

NodeIP:30080

↓

Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

LoadBalancer

Cloud Providers

AWS

Azure

GCP

YAML

type: LoadBalancer
Enter fullscreen mode Exit fullscreen mode

Kubernetes asks cloud provider

↓

Create

AWS ELB / NLB

↓

Traffic

↓

Pods

Architecture

Internet

↓

AWS Load Balancer

↓

Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

ExternalName

Very important interview topic.

Suppose

Application

↓

Needs

database.company.com
Enter fullscreen mode Exit fullscreen mode

Instead of hardcoding,

Create

type: ExternalName
Enter fullscreen mode Exit fullscreen mode

Maps

mysql-service

↓

database.company.com
Enter fullscreen mode Exit fullscreen mode

No proxy is created; Kubernetes returns a DNS CNAME record pointing to the external hostname.

Headless Service (Bonus) 

clusterIP: None
Enter fullscreen mode Exit fullscreen mode

No Cluster IP.

Returns Pod IPs directly.

Used by

  • StatefulSets
  • Databases
  • Kafka
  • Cassandra
  • ZooKeeper

Service Types Summary

Type Accessible From Typical Use
ClusterIP Inside cluster Microservice communication
NodePort Node IP + Port Testing, simple external access
LoadBalancer Internet (via cloud LB) Production external traffic
ExternalName External DNS External services
Headless Direct Pod DNS Stateful applications

Commands

Create

kubectl apply -f service.yaml
Enter fullscreen mode Exit fullscreen mode

List

kubectl get svc
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe svc payment-service
Enter fullscreen mode Exit fullscreen mode

Delete

kubectl delete svc payment-service
Enter fullscreen mode Exit fullscreen mode

How Does Service Find Pods?

Labels.

Pods

app=payment
Enter fullscreen mode Exit fullscreen mode

Service

selector:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Service automatically tracks matching Pods.

What if New Pod Comes?

Deployment

↓

Creates new Pod

↓

Label

app=payment
Enter fullscreen mode Exit fullscreen mode

↓

Service immediately starts sending traffic to it.

No manual work.

What if Pod Dies?

ReplicaSet

↓

Creates new Pod

↓

Same Label

↓

Service automatically includes it.

Can Service Exist Without Pods?

Yes.

Example

Service

↓

No Matching Pods
Enter fullscreen mode Exit fullscreen mode

Service exists.

But requests fail because there are no endpoints.

You can check this with:

kubectl get endpoints payment-service
Enter fullscreen mode Exit fullscreen mode

(or kubectl get endpointslices in newer clusters).

Service vs Deployment

Deployment

Creates Pods.

Service

Provides networking to Pods.

Service vs Pod

Pod

Temporary

IP changes

Service

Permanent

Stable IP

Stable DNS

Service vs Ingress

Service

Works inside cluster (and can expose traffic depending on its type).

Ingress

Routes external HTTP/HTTPS traffic to one or more Services.

Ingress never sends traffic directly to Pods.

Real Production Example

Netflix

Internet

↓

AWS ALB

↓

Ingress

↓

payment-service

↓

10 Pods
Enter fullscreen mode Exit fullscreen mode

Pods keep changing.

Users never notice because the Service provides a stable endpoint.

Common Interview Questions

Q1. Why do we need Services?

Because Pods are ephemeral and their IP addresses change. Services provide a stable IP, DNS name, and load balancing.

Q2. Does a Service create Pods?

No.

Deployments/ReplicaSets create Pods.

Services only provide networking to Pods.

Q3. How does a Service identify Pods?

Using label selectors.

Q4. Difference between port and targetPort?

  • port: The port exposed by the Service.
  • targetPort: The port on the container where traffic is forwarded.

Q5. What is the default Service type?

ClusterIP.

Q6. Which Service type is used in AWS Production?

Usually a LoadBalancer Service behind a cloud load balancer, often together with an Ingress Controller for HTTP/HTTPS routing.

Q7. Can one Service send traffic to multiple Pods?

Yes.

It load balances across all matching healthy Pods.

Q8. Can multiple Services point to the same Pods?

Yes.

If they use selectors that match the same Pods, multiple Services can expose those Pods differently.

Q9. Can a Service work without selectors?

Yes.

You can create a Service without a selector and manually define an Endpoints or EndpointSlice resource. This is often used to represent external or non-Kubernetes backends.

Q10. Why don't applications call Pod IPs directly?

Because Pod IPs change whenever Pods are recreated. Services provide a stable network identity.

Full Architecture So Far 

Namespace
      │
Labels
      │
Deployment
      │
ReplicaSet
      │
Pods
      │
Service
Enter fullscreen mode Exit fullscreen mode

Next Topic (Very Important)

The next topic is Service Discovery & DNS, where you'll learn:

  • How payment-service automatically becomes a DNS name.
  • What CoreDNS does.
  • Why applications never hardcode IP addresses.
  • How cross-namespace communication works.
  • How Kubernetes resolves names like: 
payment-service.default.svc.cluster.local
Enter fullscreen mode Exit fullscreen mode

Once you understand Service Discovery, Ingress, Istio, and Kubernetes Networking become much easier to master.

Excellent. Now we are entering one of the most asked Kubernetes interview topics.

If you're interviewing for DevOps, SRE, Platform Engineer, Backend Engineer (Spring Boot), or Cloud Engineer, expect multiple questions about Ingress.

Topic 8 — Ingress & Ingress Controller (Master Level)

First Understand the Problem

Suppose your company has three applications.

Payment Service

Order Service

User Service
Enter fullscreen mode Exit fullscreen mode

Each has its own Service.

payment-service

order-service

user-service
Enter fullscreen mode Exit fullscreen mode

Suppose you expose all of them using LoadBalancer.

Internet

↓

AWS Load Balancer

↓

payment-service
Enter fullscreen mode Exit fullscreen mode 
Internet

↓

AWS Load Balancer

↓

order-service
Enter fullscreen mode Exit fullscreen mode 
Internet

↓

AWS Load Balancer

↓

user-service
Enter fullscreen mode Exit fullscreen mode

Question:

How many AWS Load Balancers?

Answer:

3
Enter fullscreen mode Exit fullscreen mode

Suppose company has

200 Services
Enter fullscreen mode Exit fullscreen mode

Need

200 Load Balancers
Enter fullscreen mode Exit fullscreen mode

Very expensive.

Why Ingress?

Ingress allows one external entry point for many Services.

Instead of

Internet

↓

200 Load Balancers
Enter fullscreen mode Exit fullscreen mode

Use

Internet

↓

1 Load Balancer

↓

Ingress Controller

↓

200 Services
Enter fullscreen mode Exit fullscreen mode

Huge cost savings.

What is Ingress?

Ingress is a Kubernetes object that defines HTTP/HTTPS routing rules.

Example

/api/payment

↓

payment-service
Enter fullscreen mode Exit fullscreen mode 
/api/order

↓

order-service
Enter fullscreen mode Exit fullscreen mode 
/api/user

↓

user-service
Enter fullscreen mode Exit fullscreen mode

Ingress itself does not process traffic.

It only stores routing rules.

Biggest Interview Trap

Question: Does Ingress receive traffic?

❌ Wrong

"Yes"

✅ Correct

Ingress is only a configuration object.

The Ingress Controller receives and processes traffic.

What is an Ingress Controller?

The Ingress Controller is the software that reads Ingress rules and routes traffic.

Popular controllers:

  • NGINX Ingress Controller
  • AWS Load Balancer Controller
  • HAProxy Ingress
  • Traefik
  • Kong

Think of it like this:

Ingress

↓

Configuration

↓

NGINX Ingress Controller

↓

Actual Traffic Routing
Enter fullscreen mode Exit fullscreen mode

Architecture 

Internet
     │
     ▼
AWS Load Balancer
     │
     ▼
NGINX Ingress Controller
     │
     ▼
Ingress Rules
     │
 ┌───────────────┬───────────────┬───────────────┐
 ▼               ▼               ▼
payment-service order-service user-service
Enter fullscreen mode Exit fullscreen mode

Real Company Example

Amazon

amazon.com/pay
Enter fullscreen mode Exit fullscreen mode

↓

Payment Service

amazon.com/orders
Enter fullscreen mode Exit fullscreen mode

↓

Order Service

amazon.com/users
Enter fullscreen mode Exit fullscreen mode

↓

User Service

One Load Balancer.

One Ingress Controller.

Many Services.

Ingress YAML 

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:
  name: ecommerce-ingress

spec:

  rules:

  - host: shop.company.com

    http:

      paths:

      - path: /payment

        pathType: Prefix

        backend:

          service:

            name: payment-service

            port:

              number: 80
Enter fullscreen mode Exit fullscreen mode

Understanding Every Field

host 

host: shop.company.com
Enter fullscreen mode Exit fullscreen mode

Only requests for

shop.company.com
Enter fullscreen mode Exit fullscreen mode

match.

path 

path: /payment
Enter fullscreen mode Exit fullscreen mode

Only URLs beginning with

/payment
Enter fullscreen mode Exit fullscreen mode

match.

backend 

backend

↓

payment-service

↓

80
Enter fullscreen mode Exit fullscreen mode

Traffic goes there.

Path-Based Routing

Example

shop.company.com/payment

↓

payment-service
Enter fullscreen mode Exit fullscreen mode 
shop.company.com/order

↓

order-service
Enter fullscreen mode Exit fullscreen mode 
shop.company.com/user

↓

user-service
Enter fullscreen mode Exit fullscreen mode

One domain.

Different paths.

Host-Based Routing

Example

payment.company.com

↓

payment-service
Enter fullscreen mode Exit fullscreen mode 
order.company.com

↓

order-service
Enter fullscreen mode Exit fullscreen mode 
user.company.com

↓

user-service
Enter fullscreen mode Exit fullscreen mode

Different domains.

Different Services.

PathType

Three options:

Exact

Prefix

ImplementationSpecific
Enter fullscreen mode Exit fullscreen mode

Most common

pathType: Prefix
Enter fullscreen mode Exit fullscreen mode

Example

/payment
Enter fullscreen mode Exit fullscreen mode

Matches

/payment

/payment/123

/payment/create
Enter fullscreen mode Exit fullscreen mode

TLS

Ingress supports HTTPS.

Example

tls:

- hosts:

  - shop.company.com

  secretName: tls-secret
Enter fullscreen mode Exit fullscreen mode

Certificate stored in Secret.

Controller terminates HTTPS.

Request Flow

User

↓

shop.company.com/payment
Enter fullscreen mode Exit fullscreen mode

↓

AWS Load Balancer

↓

NGINX Ingress Controller

↓

Ingress Rule

↓

payment-service

↓

Payment Pods

Without Ingress 

Internet

↓

LB1

↓

payment
Enter fullscreen mode Exit fullscreen mode 
Internet

↓

LB2

↓

order
Enter fullscreen mode Exit fullscreen mode 
Internet

↓

LB3

↓

user
Enter fullscreen mode Exit fullscreen mode

With Ingress 

Internet

↓

One Load Balancer

↓

NGINX Ingress

↓

Payment

↓

Order

↓

User
Enter fullscreen mode Exit fullscreen mode

Does Ingress Talk to Pods?

No.

Flow

Ingress Controller

↓

Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

Never

Ingress

↓

Pods
Enter fullscreen mode Exit fullscreen mode

Difference

Service

Connects

Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

Ingress

Connects

Internet

↓

Service
Enter fullscreen mode Exit fullscreen mode

Real AWS Production 

Internet

↓

Route53

↓

AWS ALB

↓

NGINX Ingress Controller

↓

Ingress

↓

Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

Commands

Create

kubectl apply -f ingress.yaml
Enter fullscreen mode Exit fullscreen mode

List

kubectl get ingress
Enter fullscreen mode Exit fullscreen mode

Short

kubectl get ing
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe ingress ecommerce-ingress
Enter fullscreen mode Exit fullscreen mode

Delete

kubectl delete ingress ecommerce-ingress
Enter fullscreen mode Exit fullscreen mode

Common Mistakes

Mistake 1

Thinking Ingress replaces Service.

Wrong.

Ingress routes to Services.

Services route to Pods.

Mistake 2

Thinking Ingress itself handles traffic.

Wrong.

Ingress Controller handles traffic.

Mistake 3

Creating Ingress without an Ingress Controller.

Nothing works.

Ingress rules exist, but no component reads them.

NGINX Ingress Controller

NGINX runs inside Kubernetes.

Responsibilities:

  • Watches Ingress resources
  • Generates NGINX configuration
  • Reloads NGINX when rules change
  • Routes HTTP/HTTPS requests
  • Terminates TLS
  • Supports rewrites, redirects, rate limiting, etc.

Ingress vs LoadBalancer

Feature Ingress LoadBalancer
L4/L7 L7 (HTTP/HTTPS) Usually L4 (TCP/UDP); some cloud LBs also support L7
One IP for many apps ✅ ❌ Usually one LB per Service
Path routing ✅ ❌
Host routing ✅ ❌
TLS termination ✅ Depends on cloud/load balancer configuration
Cost Lower for many services Higher with many Services

Ingress vs NodePort

Ingress NodePort
Production Mostly testing/simple exposure
Domain support No
HTTPS No native TLS termination
Path routing No
Host routing No

NodePort simply exposes a port on every node.

Ingress vs API Gateway

This is asked in senior interviews.

Ingress API Gateway
Routes HTTP traffic Routes + authentication + rate limiting + quotas + transformations
Kubernetes-native Application/API management layer
Basic routing Advanced API policies

Examples of API Gateways:

  • Kong
  • Apigee
  • AWS API Gateway
  • Azure API Management

A common architecture is:

Internet
      │
AWS API Gateway
      │
NGINX Ingress
      │
Services
      │
Pods
Enter fullscreen mode Exit fullscreen mode

Common Interview Questions

Q1. What is Ingress?

A Kubernetes API resource that defines HTTP/HTTPS routing rules for external traffic.

Q2. Does Ingress receive traffic?

No.

The Ingress Controller receives traffic and applies the Ingress rules.

Q3. Why do we need an Ingress Controller?

Because Ingress is only a configuration object. Without a controller, the rules are never enforced.

Q4. Can Ingress route directly to Pods?

No.

It routes to Services, and Services route to Pods.

Q5. Difference between Service and Ingress?

  • Service: Exposes Pods inside (or optionally outside) the cluster.
  • Ingress: Provides HTTP/HTTPS routing from external clients to Services.

Q6. Why not expose every Service with a LoadBalancer?

Each LoadBalancer typically provisions separate cloud infrastructure, increasing cost and management overhead. Ingress allows many Services to share one external entry point.

Q7. Can Ingress handle HTTPS?

Yes.

TLS certificates are typically stored in Kubernetes Secrets and used by the Ingress Controller.

Q8. What is path-based routing?

Different URL paths are routed to different backend Services.

Example:

  • /payment → payment-service
  • /orders → order-service

Q9. What is host-based routing?

Different hostnames route to different Services.

Example:

  • pay.company.com → payment-service
  • orders.company.com → order-service

Q10. What is the production request flow? 

Internet
    │
Route53 / DNS
    │
Cloud Load Balancer (e.g., ALB)
    │
Ingress Controller
    │
Ingress Rules
    │
Service
    │
Pods
Enter fullscreen mode Exit fullscreen mode

Kubernetes Architecture So Far 

Namespace
      │
Labels
      │
Deployment
      │
ReplicaSet
      │
Pods
      │
Service
      │
CoreDNS
      │
Ingress
      │
Ingress Controller
Enter fullscreen mode Exit fullscreen mode

What's Next?

The next topic should be StatefulSet, because it explains why databases like MySQL, PostgreSQL, MongoDB, Kafka, Cassandra, Redis Cluster, and ZooKeeper are not typically deployed with a Deployment, and how Kubernetes provides stable identities and storage for stateful applications.

Excellent. Now we move to one of the most misunderstood Kubernetes topics.

Senior interview question:
"Why can't we run MySQL using a Deployment?"

If you answer this properly, the interviewer immediately knows you understand Kubernetes architecture.

Topic 9 — StatefulSet (Master Level)

First Understand the Problem

Suppose you deploy MySQL using a Deployment.

Deployment
      │
ReplicaSet
      │
mysql-pod-abc123
Enter fullscreen mode Exit fullscreen mode

Everything is working.

Now the Pod crashes.

ReplicaSet creates another Pod.

Old Pod

mysql-pod-abc123

↓

Deleted

↓

New Pod

mysql-pod-xyz789
Enter fullscreen mode Exit fullscreen mode

Looks okay.

But...

The Problem

The new Pod has

  • New Name
  • New IP
  • New Identity

For a Spring Boot application, that's fine.

For MySQL?

❌ Not fine.

Databases need a stable identity.

Why?

Suppose you have MySQL Replication.

Master

↓

Replica1

↓

Replica2
Enter fullscreen mode Exit fullscreen mode

Replica1 knows the Master as

mysql-0
Enter fullscreen mode Exit fullscreen mode

If the Master suddenly becomes

mysql-abc123
Enter fullscreen mode Exit fullscreen mode

Replication breaks.

Deployment vs StatefulSet

Deployment

payment-abc123

payment-def456

payment-ghi789
Enter fullscreen mode Exit fullscreen mode

Random names.

StatefulSet

mysql-0

mysql-1

mysql-2
Enter fullscreen mode Exit fullscreen mode

Stable names.

Always.

What is StatefulSet?

A StatefulSet is a Kubernetes controller used for applications that require:

  • Stable Pod names
  • Stable storage
  • Ordered deployment
  • Ordered scaling
  • Ordered termination

Examples

  • MySQL
  • PostgreSQL
  • MongoDB Replica Set
  • Cassandra
  • Kafka
  • ZooKeeper
  • Elasticsearch (often)
  • Redis Cluster

Biggest Interview Difference

Deployment

Pods are replaceable.

StatefulSet

Pods have identity.

Stable Pod Name

Deployment

payment-asd987
Enter fullscreen mode Exit fullscreen mode

Restart

payment-hjk456
Enter fullscreen mode Exit fullscreen mode

StatefulSet

mysql-0
Enter fullscreen mode Exit fullscreen mode

Restart

mysql-0
Enter fullscreen mode Exit fullscreen mode

Same name.

Stable DNS

Deployment

payment-service
Enter fullscreen mode Exit fullscreen mode

One Service.

StatefulSet

mysql-0.mysql

mysql-1.mysql

mysql-2.mysql
Enter fullscreen mode Exit fullscreen mode

Each Pod gets its own DNS name.

Stable Storage

Deployment

Pod Dies

↓

Volume may be replaced depending on configuration
Enter fullscreen mode Exit fullscreen mode

StatefulSet

mysql-0

↓

PVC

↓

Persistent Volume
Enter fullscreen mode Exit fullscreen mode

Restart

↓

Same PVC

↓

Same Data

Architecture 

StatefulSet

↓

Headless Service

↓

mysql-0

mysql-1

mysql-2

↓

Persistent Volume Claims

↓

Persistent Volumes
Enter fullscreen mode Exit fullscreen mode

Notice:

StatefulSets almost always use a Headless Service.

Why Headless Service?

Normal Service

payment-service

↓

10.96.10.5
Enter fullscreen mode Exit fullscreen mode

One virtual IP.

Headless Service

clusterIP: None
Enter fullscreen mode Exit fullscreen mode

Returns

mysql-0.mysql

mysql-1.mysql

mysql-2.mysql
Enter fullscreen mode Exit fullscreen mode

Each Pod individually.

Databases need this.

Ordered Deployment

Deployment

Creates Pods

1

2

3
Enter fullscreen mode Exit fullscreen mode

No guaranteed order.

StatefulSet

Creates

mysql-0

↓

mysql-1

↓

mysql-2
Enter fullscreen mode Exit fullscreen mode

Sequential.

Ordered Deletion

Delete StatefulSet.

Pods terminate

mysql-2

↓

mysql-1

↓

mysql-0
Enter fullscreen mode Exit fullscreen mode

Reverse order.

Useful for clustered databases.

Ordered Scaling

Current

mysql-0

mysql-1
Enter fullscreen mode Exit fullscreen mode

Scale to

3
Enter fullscreen mode Exit fullscreen mode

Creates

mysql-2
Enter fullscreen mode Exit fullscreen mode

Only after previous Pods are ready.

StatefulSet YAML 

apiVersion: apps/v1

kind: StatefulSet

metadata:
  name: mysql

spec:

  serviceName: mysql

  replicas: 3

  selector:

    matchLabels:

      app: mysql

  template:

    metadata:

      labels:

        app: mysql

    spec:

      containers:

      - name: mysql

        image: mysql:8
Enter fullscreen mode Exit fullscreen mode

Very Important Field 

serviceName: mysql
Enter fullscreen mode Exit fullscreen mode

Not optional.

StatefulSet uses it to create stable DNS names.

Persistent Volume Claims

Each Pod gets its own PVC.

mysql-0

↓

mysql-pvc-0
Enter fullscreen mode Exit fullscreen mode 
mysql-1

↓

mysql-pvc-1
Enter fullscreen mode Exit fullscreen mode 
mysql-2

↓

mysql-pvc-2
Enter fullscreen mode Exit fullscreen mode

Each Pod owns its own storage.

Pod Restart

Pod crashes.

Deployment

payment-abc123

↓

payment-xyz111
Enter fullscreen mode Exit fullscreen mode

Different identity.

StatefulSet

mysql-0

↓

mysql-0
Enter fullscreen mode Exit fullscreen mode

Same identity.

Same storage.

Scaling

Current

mysql-0

mysql-1
Enter fullscreen mode Exit fullscreen mode

Scale

replicas: 5
Enter fullscreen mode Exit fullscreen mode

Creates

mysql-2

mysql-3

mysql-4
Enter fullscreen mode Exit fullscreen mode

One at a time.

Can StatefulSet Load Balance?

Usually

Applications use

Headless Service

↓

Individual Pods.

Sometimes another normal Service is added for client traffic.

Real Production Example

Kafka Cluster

kafka-0

↓

Broker1
Enter fullscreen mode Exit fullscreen mode 
kafka-1

↓

Broker2
Enter fullscreen mode Exit fullscreen mode 
kafka-2

↓

Broker3
Enter fullscreen mode Exit fullscreen mode

Every broker has

  • Stable hostname
  • Stable storage
  • Stable identity

Exactly why StatefulSet exists.

MySQL Example 

mysql-0

Master
Enter fullscreen mode Exit fullscreen mode 
mysql-1

Replica
Enter fullscreen mode Exit fullscreen mode 
mysql-2

Replica
Enter fullscreen mode Exit fullscreen mode

Replication depends on stable identities.

StatefulSet vs Deployment

Feature Deployment StatefulSet
Pod Names Random suffix Stable ordinal (app-0, app-1)
Pod Identity Temporary Stable
Storage Often shared or recreated depending on setup Dedicated PVC per Pod
Ordered Start ❌ ✅
Ordered Delete ❌ ✅
Headless Service Not required Usually required
Databases ❌ Usually not ideal ✅

StatefulSet vs ReplicaSet

ReplicaSet

Keeps Pod count.

StatefulSet

Keeps

  • Pod count
  • Pod identity
  • Storage
  • Ordering

Interview Scenario

Interviewer

Why don't we deploy MySQL using Deployment?

Correct Answer

Because MySQL requires stable identities, stable storage, and predictable networking. Deployments recreate Pods with new identities, whereas StatefulSets preserve Pod names, dedicated storage, and ordered operations, which are essential for stateful workloads.

Commands

Create

kubectl apply -f statefulset.yaml
Enter fullscreen mode Exit fullscreen mode

View

kubectl get statefulsets
Enter fullscreen mode Exit fullscreen mode

Short

kubectl get sts
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe sts mysql
Enter fullscreen mode Exit fullscreen mode

Scale

kubectl scale sts mysql --replicas=5
Enter fullscreen mode Exit fullscreen mode

Delete

kubectl delete sts mysql
Enter fullscreen mode Exit fullscreen mode

Common Interview Questions

Q1. What is StatefulSet?

A Kubernetes controller for stateful applications requiring stable identities, storage, and ordered operations.

Q2. Why use StatefulSet instead of Deployment?

Because stateful applications need stable Pod names, stable storage, and ordered startup/shutdown.

Q3. Does StatefulSet require a Headless Service?

Typically yes. A Headless Service provides stable DNS names for each Pod.

Q4. What is a Headless Service?

A Service with:

clusterIP: None
Enter fullscreen mode Exit fullscreen mode

It doesn't allocate a virtual ClusterIP. Instead, DNS resolves directly to the individual Pod IPs.

Q5. Why is ordered startup important?

Applications like Kafka or database clusters may require one node to be ready before another joins the cluster.

Q6. What happens if mysql-1 crashes?

Kubernetes recreates it as mysql-1 and reattaches its dedicated PersistentVolumeClaim.

Q7. Does each StatefulSet Pod get its own PVC?

Yes. Each Pod receives a separate PersistentVolumeClaim, typically created from a volumeClaimTemplates section.

Q8. Can StatefulSet perform rolling updates?

Yes. StatefulSets support rolling updates while respecting Pod ordering and identity.

Q9. Which applications commonly use StatefulSets?

  • MySQL
  • PostgreSQL
  • MongoDB
  • Kafka
  • Cassandra
  • ZooKeeper
  • Redis Cluster

Q10. Can we run Spring Boot applications using StatefulSet?

Technically yes, but stateless Spring Boot applications are normally deployed using Deployments because they don't require stable identities or dedicated storage.

Complete Kubernetes Architecture So Far 

Namespace
      │
Labels
      │
Deployment ─────► Stateless Apps
      │
ReplicaSet
      │
Pods
      │
Service
      │
CoreDNS
      │
Ingress
      │
Ingress Controller

StatefulSet ────► Databases / Kafka / ZooKeeper
Enter fullscreen mode Exit fullscreen mode

Real Production Architecture 

Internet
      │
Route53
      │
AWS ALB
      │
NGINX Ingress Controller
      │
Ingress
      │
Services
      │
├── Deployment
│      │
│   ReplicaSet
│      │
│   Spring Boot Pods
│
└── StatefulSet
       │
   MySQL-0
   MySQL-1
   MySQL-2
       │
 Persistent Volumes
Enter fullscreen mode Exit fullscreen mode

Next Topic

The next topic should be DaemonSet, because it answers another classic interview question:

"How does Prometheus Node Exporter, Fluent Bit, Filebeat, or Datadog Agent automatically run on every Kubernetes node?"

DaemonSets are the standard solution for running one Pod per node across the cluster.

Excellent. Now we reach another very frequently asked interview topic.

Almost every DevOps interview includes this question:

"How does Fluent Bit, Filebeat, Datadog Agent, Node Exporter, or Falco automatically run on every Kubernetes node?"

The answer is DaemonSet.

Topic 10 — DaemonSet (Master Level)

First Understand the Problem

Suppose your Kubernetes cluster has

Cluster

Node-1

Node-2

Node-3
Enter fullscreen mode Exit fullscreen mode

You install Fluent Bit to collect logs.

Question:

Should you manually create

Fluent Bit

Node-1

Fluent Bit

Node-2

Fluent Bit

Node-3
Enter fullscreen mode Exit fullscreen mode

No.

Imagine a cluster with

500 Nodes
Enter fullscreen mode Exit fullscreen mode

Impossible.

The Solution

DaemonSet.

DaemonSet automatically ensures

Exactly one Pod runs on every eligible Node.

What is DaemonSet?

A DaemonSet is a Kubernetes controller that ensures a copy of a Pod runs on every eligible Node.

Whenever

  • New Node joins
  • Node removed
  • Node restarted

DaemonSet automatically adjusts Pods.

Real Company Example

Amazon EKS Cluster

Cluster

Node-1

Node-2

Node-3

Node-4
Enter fullscreen mode Exit fullscreen mode

DaemonSet

↓

Creates

Node-1

Fluent Bit
Enter fullscreen mode Exit fullscreen mode 
Node-2

Fluent Bit
Enter fullscreen mode Exit fullscreen mode 
Node-3

Fluent Bit
Enter fullscreen mode Exit fullscreen mode 
Node-4

Fluent Bit
Enter fullscreen mode Exit fullscreen mode

One Pod per Node.

Architecture 

Cluster

├── Node-1
│      └── Fluent Bit
│
├── Node-2
│      └── Fluent Bit
│
├── Node-3
│      └── Fluent Bit
│
└── Node-4
       └── Fluent Bit
Enter fullscreen mode Exit fullscreen mode

Why Not Deployment?

Deployment

replicas: 3
Enter fullscreen mode Exit fullscreen mode

Suppose

Cluster

10 Nodes
Enter fullscreen mode Exit fullscreen mode

Deployment

↓

Creates only

3 Pods
Enter fullscreen mode Exit fullscreen mode

Not enough.

Some Nodes have no logging agent.

DaemonSet

10 Nodes

↓

10 Pods
Enter fullscreen mode Exit fullscreen mode

Perfect.

What Happens When New Node Joins?

Current

Node1

Node2

Node3
Enter fullscreen mode Exit fullscreen mode

DaemonSet

↓

FluentBit

FluentBit

FluentBit
Enter fullscreen mode Exit fullscreen mode

Now

New Node

Node4
Enter fullscreen mode Exit fullscreen mode

Immediately

DaemonSet creates

FluentBit
Enter fullscreen mode Exit fullscreen mode

on Node4.

No manual work.

What Happens If Node Removed?

Current

Node1

Node2

Node3
Enter fullscreen mode Exit fullscreen mode

Node3 deleted.

DaemonSet removes Pod automatically because the Node no longer exists.

DaemonSet YAML 

apiVersion: apps/v1

kind: DaemonSet

metadata:
  name: fluent-bit

spec:

  selector:

    matchLabels:

      app: fluent-bit

  template:

    metadata:

      labels:

        app: fluent-bit

    spec:

      containers:

      - name: fluent-bit

        image: fluent/fluent-bit
Enter fullscreen mode Exit fullscreen mode

Notice:

No

replicas:
Enter fullscreen mode Exit fullscreen mode

Why?

Because DaemonSet decides the number of Pods based on the number of eligible Nodes.

Real Production Example

Node

Node1

Pods

Spring Boot

Redis

Kafka
Enter fullscreen mode Exit fullscreen mode

DaemonSet Pod

Fluent Bit
Enter fullscreen mode Exit fullscreen mode

Collects logs

↓

ElasticSearch

Monitoring Example

Prometheus

Uses

Node Exporter
Enter fullscreen mode Exit fullscreen mode

Need

One per Node
Enter fullscreen mode Exit fullscreen mode

DaemonSet

↓

Perfect.

Security Example

Falco

↓

Needs

Every Node
Enter fullscreen mode Exit fullscreen mode

DaemonSet.

Antivirus Example

CrowdStrike Agent

↓

Every Node

DaemonSet.

Networking Example

Many Kubernetes CNI plugins (such as Calico and Cilium agents) run a DaemonSet so that each node has the required networking components.

Can DaemonSet Run on Master Nodes?

Normally

No.

Control plane nodes are often tainted to prevent ordinary workloads.

If needed

Use

tolerations:
Enter fullscreen mode Exit fullscreen mode

to allow the DaemonSet to run there.

Node Selector

Suppose

GPU Nodes

Node1

GPU=true
Enter fullscreen mode Exit fullscreen mode 
Node2

GPU=true
Enter fullscreen mode Exit fullscreen mode 
Node3

GPU=false
Enter fullscreen mode Exit fullscreen mode

DaemonSet

nodeSelector:

  gpu: "true"
Enter fullscreen mode Exit fullscreen mode

Runs only on GPU nodes.

Taints & Tolerations

Suppose

Master Node

Has taint

NoSchedule
Enter fullscreen mode Exit fullscreen mode

DaemonSet won't run.

Need

tolerations:
Enter fullscreen mode Exit fullscreen mode

Then it runs.

DaemonSet Update

Suppose

Current

FluentBit:v1
Enter fullscreen mode Exit fullscreen mode

Update

FluentBit:v2
Enter fullscreen mode Exit fullscreen mode

DaemonSet performs a rolling update by default, updating Pods on nodes in a controlled manner.

Commands

Create

kubectl apply -f daemonset.yaml
Enter fullscreen mode Exit fullscreen mode

View

kubectl get daemonsets
Enter fullscreen mode Exit fullscreen mode

Short

kubectl get ds
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe ds fluent-bit
Enter fullscreen mode Exit fullscreen mode

Delete

kubectl delete ds fluent-bit
Enter fullscreen mode Exit fullscreen mode

Deployment vs DaemonSet

Feature Deployment DaemonSet
Replica Count Fixed One Pod per eligible Node
New Node Nothing happens automatically New Pod created automatically
Use Case Applications Node-level agents
Replicas Field Yes No

DaemonSet vs StatefulSet

DaemonSet StatefulSet
One Pod per Node Stable identity per Pod
Node-based scheduling Identity-based scheduling
Logging, Monitoring Databases, Kafka

DaemonSet vs ReplicaSet

ReplicaSet

Need

5 Pods
Enter fullscreen mode Exit fullscreen mode

DaemonSet

Need

Every Node
Enter fullscreen mode Exit fullscreen mode

Completely different goals.

Real AWS Architecture 

EKS Cluster

Node1

Spring Boot

Redis

Fluent Bit

Node Exporter

Datadog Agent

--------------------------------

Node2

Spring Boot

Kafka

Fluent Bit

Node Exporter

Datadog Agent

--------------------------------

Node3

MySQL

Fluent Bit

Node Exporter

Datadog Agent
Enter fullscreen mode Exit fullscreen mode

Notice

Monitoring Pods

Every Node.

Common Interview Questions

Q1. What is DaemonSet?

A Kubernetes controller that ensures one Pod runs on every eligible Node.

Q2. Does DaemonSet have replicas?

No.

The number of Pods is determined by the number of eligible Nodes.

Q3. What happens when a new Node joins?

DaemonSet automatically schedules its Pod onto the new eligible Node.

Q4. Why use DaemonSet instead of Deployment?

Because node-level agents (logging, monitoring, networking, security) must run on every Node, not just a fixed number of replicas.

Q5. Can DaemonSet run on master/control-plane nodes?

Yes, if the DaemonSet tolerates the control-plane node taints.

Q6. Name some real-world DaemonSet applications.

  • Fluent Bit / Fluentd
  • Filebeat
  • Prometheus Node Exporter
  • Datadog Agent
  • Falco
  • Calico Node
  • Cilium Agent

Q7. What happens if a Node is deleted?

The DaemonSet Pod on that Node is removed because the Node no longer exists.

Q8. Can DaemonSet use rolling updates?

Yes. DaemonSets support rolling updates by default.

Q9. Can DaemonSet run only on specific Nodes?

Yes.

Using:

  • nodeSelector
  • nodeAffinity
  • tolerations

Q10. Can multiple DaemonSets run on one Node?

Yes.

Example:

Node

↓

Fluent Bit

↓

Node Exporter

↓

Datadog Agent

↓

Falco
Enter fullscreen mode Exit fullscreen mode

Each DaemonSet manages its own Pod.

Memory Trick

Controller Think Of
Deployment "Run N application Pods"
ReplicaSet "Keep N Pods alive"
StatefulSet "Stable identity & storage"
DaemonSet "One Pod per Node"
Job "Run once and finish" (next topic)
CronJob "Run on a schedule" (after Job)

Kubernetes Architecture So Far 

Namespace
      │
Labels
      │
Deployment ─────────► Spring Boot Apps
      │
ReplicaSet
      │
Pods
      │
Service
      │
CoreDNS
      │
Ingress
      │
Ingress Controller
      │
StatefulSet ────────► MySQL, Kafka
      │
DaemonSet ──────────► Fluent Bit, Node Exporter
Enter fullscreen mode Exit fullscreen mode

Next Topic

The next topic is Jobs & CronJobs, where you'll learn:

  • Why not every workload should run forever.
  • How Kubernetes executes one-time tasks.
  • How scheduled jobs (like backups and reports) work.
  • The differences between Deployment vs Job vs CronJob.

* Real production examples such as database backups, report generation, ETL jobs, and cleanup tasks.

Excellent. Now we move to another topic that is very common in real production.

Interview Question:

"Would you deploy a database backup script using a Deployment?"

Correct Answer: No. Use a Job or CronJob.

This topic is extremely important because many beginners misuse Deployments for one-time tasks.

Topic 11 — Jobs & CronJobs (Master Level)

First Understand the Problem

Suppose your company needs to:

  • Take a MySQL backup
  • Generate a monthly report
  • Send salary emails
  • Run an ETL pipeline
  • Clean temporary files

Question:

Should these applications run forever?

Example

Database Backup

↓

Finished
Enter fullscreen mode Exit fullscreen mode

Should Kubernetes restart it forever?

No.

Deployment is the wrong choice.

Why Deployment is Wrong

Deployment assumes

Application

↓

Should always be Running
Enter fullscreen mode Exit fullscreen mode

If container exits,

ReplicaSet creates another Pod.

Again

Again

Again

Forever.

Suppose

Backup completed successfully.

Container exits.

Deployment thinks

Pod Died

↓

Create New Pod
Enter fullscreen mode Exit fullscreen mode

Backup runs again.

Wrong.

Solution

Use

Job
Enter fullscreen mode Exit fullscreen mode

What is a Job?

A Job is a Kubernetes controller that runs a task until it completes successfully.

Once completed,

Kubernetes considers the Job successful and does not restart it (unless retry policies require it).

Architecture 

Job

↓

Pod

↓

Run Script

↓

Exit

↓

Completed
Enter fullscreen mode Exit fullscreen mode

Real Company Example

Nightly Database Backup

Job

↓

Backup MySQL

↓

Upload to S3

↓

Exit
Enter fullscreen mode Exit fullscreen mode

Finished.

Job YAML 

apiVersion: batch/v1

kind: Job

metadata:
  name: mysql-backup

spec:

  template:

    spec:

      restartPolicy: Never

      containers:

      - name: backup

        image: mysql-backup:latest
Enter fullscreen mode Exit fullscreen mode

Notice

restartPolicy: Never
Enter fullscreen mode Exit fullscreen mode

The Pod won't restart itself. If the Pod fails, the Job controller decides whether to create a replacement Pod based on settings like backoffLimit.

Job Lifecycle 

Job

↓

Pod Created

↓

Script Executes

↓

Success

↓

Completed
Enter fullscreen mode Exit fullscreen mode

Done.

What If Job Fails?

Suppose

Backup failed.

Exit Code = 1
Enter fullscreen mode Exit fullscreen mode

Job retries.

Default retry behavior is controlled by backoffLimit.

Example

backoffLimit: 4
Enter fullscreen mode Exit fullscreen mode

Meaning:

Retry up to 4 times before marking the Job as failed.

Job Commands

Create

kubectl apply -f job.yaml
Enter fullscreen mode Exit fullscreen mode

View

kubectl get jobs
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe job mysql-backup
Enter fullscreen mode Exit fullscreen mode

Logs

kubectl logs job/mysql-backup
Enter fullscreen mode Exit fullscreen mode

Delete

kubectl delete job mysql-backup
Enter fullscreen mode Exit fullscreen mode

Parallel Jobs

Suppose

Need

100 Images

↓

Resize
Enter fullscreen mode Exit fullscreen mode

One Pod

Too slow.

Use

parallelism: 10

completions: 100
Enter fullscreen mode Exit fullscreen mode

Meaning

10 Pods run simultaneously.

Need 100 successful completions.

Completion Mode

Suppose

completions: 5
Enter fullscreen mode Exit fullscreen mode

Need

5 successful runs.

Even if some Pods fail,

Job continues until

5 successful completions occur or it exceeds retry limits.

Real Example

ETL Pipeline

Read CSV

↓

Transform

↓

Load Database

↓

Finished
Enter fullscreen mode Exit fullscreen mode

Perfect Job.

What is CronJob?

Suppose

Need backup

Every day

2 AM.

Should engineer wake up daily?

No.

Use

CronJob
Enter fullscreen mode Exit fullscreen mode

CronJob = Scheduler

CronJob creates Jobs according to a schedule.

Architecture

CronJob

↓

Job

↓

Pod

↓

Finished
Enter fullscreen mode Exit fullscreen mode

Real Company Example

Amazon

Every Night

2 AM

↓

Backup Database

↓

Upload S3
Enter fullscreen mode Exit fullscreen mode

CronJob.

CronJob YAML 

apiVersion: batch/v1

kind: CronJob

metadata:

  name: backup

spec:

  schedule: "0 2 * * *"

  jobTemplate:

    spec:

      template:

        spec:

          restartPolicy: Never

          containers:

          - name: backup

            image: backup-image
Enter fullscreen mode Exit fullscreen mode

Cron Schedule 

* * * * *

│ │ │ │ │

│ │ │ │ Day of Week

│ │ │ Month

│ │ Day of Month

│ Hour

Minute
Enter fullscreen mode Exit fullscreen mode

Examples

Every Minute

* * * * *
Enter fullscreen mode Exit fullscreen mode

Every Hour

0 * * * *
Enter fullscreen mode Exit fullscreen mode

Daily 2 AM

0 2 * * *
Enter fullscreen mode Exit fullscreen mode

Every Sunday

0 0 * * 0
Enter fullscreen mode Exit fullscreen mode

Every Monday 9 AM

0 9 * * 1
Enter fullscreen mode Exit fullscreen mode

Production Examples

Backup 

Daily 2 AM
Enter fullscreen mode Exit fullscreen mode

Report Generation 

Monthly
Enter fullscreen mode Exit fullscreen mode

Cleanup Logs 

Every Midnight
Enter fullscreen mode Exit fullscreen mode

Delete Temp Files 

Every Hour
Enter fullscreen mode Exit fullscreen mode

Send Salary Emails 

1st of Every Month
Enter fullscreen mode Exit fullscreen mode

Job vs CronJob

Job

Run Once
Enter fullscreen mode Exit fullscreen mode

CronJob

Run Repeatedly
Enter fullscreen mode Exit fullscreen mode

Simple.

Deployment vs Job

Deployment

Run Forever
Enter fullscreen mode Exit fullscreen mode

Job

Run Once

↓

Exit
Enter fullscreen mode Exit fullscreen mode

Job vs StatefulSet

StatefulSet

Database

Runs Forever
Enter fullscreen mode Exit fullscreen mode

Job

Backup Database

Runs Once
Enter fullscreen mode Exit fullscreen mode

CronJob Flow 

2 AM

↓

CronJob

↓

Job

↓

Pod

↓

Backup

↓

Exit
Enter fullscreen mode Exit fullscreen mode

Next day

Again.

Useful Fields

successfulJobsHistoryLimit

Keep only a certain number of successful Jobs.

Example

successfulJobsHistoryLimit: 3
Enter fullscreen mode Exit fullscreen mode

failedJobsHistoryLimit

Keep only recent failed Jobs.

concurrencyPolicy

Controls overlapping runs.

Allow (default)

New Job starts even if previous one is still running.

Forbid

If previous Job is running,

Don't start another.

Useful for backups.

Replace

Stop old Job.

Start new Job.

Common Interview Questions

Q1. What is Job?

A Kubernetes controller that runs a task until it completes successfully.

Q2. Difference between Deployment and Job?

Deployment keeps Pods running continuously.

Job runs until completion and then stops.

Q3. Difference between Job and CronJob?

Job executes once.

CronJob schedules Jobs repeatedly based on a cron expression.

Q4. Can Job retry after failure?

Yes.

Controlled by

backoffLimit
Enter fullscreen mode Exit fullscreen mode

Q5. What is parallelism?

The number of Pods that can run simultaneously for a Job.

Q6. What is completions?

The total number of successful Pod completions required before the Job is considered complete.

Q7. What is restartPolicy in a Job?

Usually Never or OnFailure. Always is not supported for Job Pods.

Q8. Give real examples of Jobs.

  • Database backup
  • Data migration
  • ETL processing
  • Report generation
  • Image processing
  • Batch import/export

Q9. Give real examples of CronJobs.

  • Daily backup
  • Weekly cleanup
  • Monthly billing
  • Certificate renewal
  • Log rotation
  • Scheduled reports

Q10. What happens if a CronJob triggers while the previous run is still executing?

It depends on concurrencyPolicy:

  • Allow: Both run.
  • Forbid: Skip the new run.
  • Replace: Stop the old Job and start a new one.

Deployment vs StatefulSet vs DaemonSet vs Job vs CronJob

Feature Deployment StatefulSet DaemonSet Job CronJob
Runs Forever ✅ ✅ ✅ ❌ ❌
One-Time Task ❌ ❌ ❌ ✅ ❌
Scheduled Task ❌ ❌ ❌ ❌ ✅
Stable Identity ❌ ✅ ❌ ❌ ❌
One Pod Per Node ❌ ❌ ✅ ❌ ❌
Typical Use Web Apps Databases Node Agents Backup/Migration Scheduled Backup

Real Production Architecture 

Internet
     │
ALB
     │
Ingress
     │
Service
     │
Deployment
     │
ReplicaSet
     │
Pods

StatefulSet
     │
MySQL

DaemonSet
     │
Fluent Bit

CronJob
     │
Nightly Backup Job
     │
Backup Pod
Enter fullscreen mode Exit fullscreen mode

Kubernetes Controllers Covered So Far 

Deployment   → Stateless applications
ReplicaSet   → Maintain desired Pod count
StatefulSet  → Databases & stateful workloads
DaemonSet    → One Pod per Node
Job          → Run once
CronJob      → Run on a schedule
Enter fullscreen mode Exit fullscreen mode

What Comes Next?

The next topic should be ConfigMaps & Secrets.

This is another top interview topic because every real-world application needs configuration such as:

  • Spring Boot application.yml
  • Database URLs
  • Redis host
  • Kafka brokers
  • API keys
  • JWT secrets
  • AWS credentials

You'll learn:

  • Why configuration should never be hardcoded.
  • ConfigMap vs Secret.
  • How applications consume them as environment variables or mounted files.
  • Real Spring Boot production examples.

* Common interview traps around security and configuration management.

next
Excellent. This is one of the most important production topics in Kubernetes.

Every real company uses ConfigMaps and Secrets.

If you're working with Spring Boot + Kubernetes + AWS, you'll use them every day.

A common senior interview question is:

"Where do you store your database password in Kubernetes?"

If your answer is:

application.yml
Enter fullscreen mode Exit fullscreen mode

❌ Wrong.

The correct answer is Kubernetes Secrets.

Topic 12 — ConfigMaps & Secrets (Master Level)

First Understand the Problem

Suppose you have a Spring Boot application.

spring:
  datasource:
    url: jdbc:mysql://mysql:3306/ecommerce
    username: root
    password: root123
Enter fullscreen mode Exit fullscreen mode

Looks fine.

But imagine your code is pushed to GitHub.

Now everyone can see

password=root123
Enter fullscreen mode Exit fullscreen mode

This is a security risk.

Another Problem

Suppose today the database URL is

mysql-dev
Enter fullscreen mode Exit fullscreen mode

Tomorrow

mysql-prod
Enter fullscreen mode Exit fullscreen mode

Should developers rebuild Docker images every time?

No.

Configuration should be external.

Solution

Kubernetes provides two objects.

ConfigMap

Secret
Enter fullscreen mode Exit fullscreen mode

Difference

ConfigMap

Stores

  • Configuration
  • URLs
  • Hostnames
  • Ports
  • Feature flags

Examples

APP_NAME

REDIS_HOST

KAFKA_BROKERS

LOG_LEVEL
Enter fullscreen mode Exit fullscreen mode

Secret

Stores

  • Passwords
  • API Keys
  • Tokens
  • Certificates
  • JWT Secret
  • AWS Credentials

Biggest Interview Question

ConfigMap vs Secret

ConfigMap

↓

Non-sensitive configuration.

Secret

↓

Sensitive information.

Real Production Example

Spring Boot

Needs

Database URL

Redis Host

Kafka Broker

JWT Secret

Database Password
Enter fullscreen mode Exit fullscreen mode

Store

ConfigMap

↓

Database URL

Redis Host

Kafka Broker
Enter fullscreen mode Exit fullscreen mode

Store

Secret

↓

Password

JWT Secret

AWS Keys
Enter fullscreen mode Exit fullscreen mode

Architecture 

Spring Boot Pod

↓

ConfigMap

↓

Database URL

Redis Host

Kafka Host

-----------------------

Secret

↓

Password

JWT Secret
Enter fullscreen mode Exit fullscreen mode

ConfigMap YAML 

apiVersion: v1

kind: ConfigMap

metadata:

  name: app-config

data:

  DB_HOST: mysql

  DB_PORT: "3306"

  REDIS_HOST: redis

  LOG_LEVEL: INFO
Enter fullscreen mode Exit fullscreen mode

Secret YAML 

apiVersion: v1

kind: Secret

metadata:

  name: app-secret

type: Opaque

data:

  DB_PASSWORD: cm9vdDEyMw==

  JWT_SECRET: c2VjcmV0MTIz
Enter fullscreen mode Exit fullscreen mode

Notice

Values are

Base64 Encoded
Enter fullscreen mode Exit fullscreen mode

Biggest Interview Trap

Question

Are Kubernetes Secrets encrypted?

Many beginners answer

"Yes"

Wrong.

By default,

Secrets are Base64 encoded, not encrypted.

Whether they are encrypted at rest depends on whether the cluster administrator has enabled encryption at rest in the Kubernetes API server.

Why Base64?

Example

Password

root123
Enter fullscreen mode Exit fullscreen mode

Encoded

cm9vdDEyMw==
Enter fullscreen mode Exit fullscreen mode

Anyone can decode it.

So Base64 is not security.

Better Production Security

Companies use

  • AWS Secrets Manager
  • HashiCorp Vault
  • Azure Key Vault
  • Google Secret Manager

instead of storing all secrets directly in Kubernetes.

Using ConfigMap as Environment Variables

Example

env:

- name: DB_HOST

  valueFrom:

    configMapKeyRef:

      name: app-config

      key: DB_HOST
Enter fullscreen mode Exit fullscreen mode

Spring Boot

Reads

DB_HOST=mysql
Enter fullscreen mode Exit fullscreen mode

Using Secret as Environment Variable 

env:

- name: DB_PASSWORD

  valueFrom:

    secretKeyRef:

      name: app-secret

      key: DB_PASSWORD
Enter fullscreen mode Exit fullscreen mode

Application gets

root123
Enter fullscreen mode Exit fullscreen mode

after Kubernetes decodes the Base64 value before injecting it.

Mount ConfigMap as File

Sometimes

Instead of Environment Variables

Need file.

Example

application.yml
Enter fullscreen mode Exit fullscreen mode

ConfigMap

↓

Mounted

/etc/config/application.yml
Enter fullscreen mode Exit fullscreen mode

Useful for large configuration files.

Mount Secret as File

TLS Certificates

tls.crt

tls.key
Enter fullscreen mode Exit fullscreen mode

Mounted

/etc/tls/
Enter fullscreen mode Exit fullscreen mode

NGINX Ingress

Reads certificates from mounted Secret files.

Spring Boot Example

ConfigMap

SPRING_DATASOURCE_URL

SPRING_REDIS_HOST

SPRING_KAFKA_BOOTSTRAP_SERVERS
Enter fullscreen mode Exit fullscreen mode

Secret

SPRING_DATASOURCE_PASSWORD

JWT_SECRET

AWS_ACCESS_KEY
Enter fullscreen mode Exit fullscreen mode

Spring Boot automatically maps these environment variables to configuration properties (especially when using relaxed binding).

Updating ConfigMap

Suppose

Old

LOG_LEVEL=INFO
Enter fullscreen mode Exit fullscreen mode

New

LOG_LEVEL=DEBUG
Enter fullscreen mode Exit fullscreen mode

Update

kubectl apply -f configmap.yaml
Enter fullscreen mode Exit fullscreen mode

Pods may not automatically pick up the new value.

  • Environment variables require the Pod to restart.
  • Mounted ConfigMap volumes are updated automatically after a short delay, but the application may need to reload the file.

Updating Secret

Same concept.

Applications may need restart depending on how they consume it.

Commands

Create ConfigMap

kubectl apply -f configmap.yaml
Enter fullscreen mode Exit fullscreen mode

View

kubectl get configmaps
Enter fullscreen mode Exit fullscreen mode

Short

kubectl get cm
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe cm app-config
Enter fullscreen mode Exit fullscreen mode

Secrets

View

kubectl get secrets
Enter fullscreen mode Exit fullscreen mode

Describe

kubectl describe secret app-secret
Enter fullscreen mode Exit fullscreen mode

Decode

kubectl get secret app-secret \
-o jsonpath="{.data.DB_PASSWORD}" | base64 -d
Enter fullscreen mode Exit fullscreen mode

ConfigMap vs Secret

Feature ConfigMap Secret
Sensitive Data ❌ ✅
Password ❌ ✅
API Key ❌ ✅
JWT Secret ❌ ✅
Database URL ✅ ❌
Log Level ✅ ❌

Environment Variables vs Files

Environment Variable Mounted File
Simple values Large configs
Database URL application.yml
Redis Host TLS Certificates
Kafka Broker JSON/XML configs

Production Example 

Spring Boot

↓

ConfigMap

↓

application.yml values

↓

Secret

↓

Database Password

↓

JWT Secret

↓

AWS Credentials
Enter fullscreen mode Exit fullscreen mode

Real AWS Example 

Spring Boot Pod

↓

AWS Secrets Manager

↓

Database Password

↓

RDS
Enter fullscreen mode Exit fullscreen mode

Sometimes Kubernetes Secrets are synchronized from AWS Secrets Manager using tools like the Secrets Store CSI Driver or External Secrets Operator.

Common Interview Questions

Q1. What is ConfigMap?

A Kubernetes object for storing non-sensitive configuration.

Q2. What is Secret?

A Kubernetes object for storing sensitive information such as passwords, API keys, and certificates.

Q3. Difference between ConfigMap and Secret?

ConfigMap stores configuration.

Secret stores confidential data.

Q4. Are Kubernetes Secrets encrypted?

By default, they are Base64 encoded.

Encryption at rest must be explicitly enabled.

Q5. Can applications read ConfigMaps as environment variables?

Yes.

Q6. Can applications read Secrets as files?

Yes.

Secrets can be mounted as volumes.

Q7. Should database passwords go into ConfigMaps?

No.

Use Secrets.

Q8. Can ConfigMaps be updated?

Yes.

Applications may require reloads or Pod restarts depending on how the data is consumed.

Q9. What are real examples of ConfigMaps?

  • Database host
  • Redis host
  • Kafka brokers
  • Log level
  • Feature flags

Q10. What are real examples of Secrets?

  • Database password
  • JWT secret
  • OAuth client secret
  • TLS certificate
  • AWS credentials
  • API tokens

Kubernetes Controllers & Resources Covered So Far 

Deployment   → Stateless Apps
ReplicaSet   → Desired Pod Count
StatefulSet  → Databases
DaemonSet    → One Pod Per Node
Job          → One-Time Task
CronJob      → Scheduled Task

Service       → Stable Networking
CoreDNS       → Service Discovery
Ingress       → External HTTP Routing

ConfigMap     → Configuration
Secret        → Sensitive Data
Enter fullscreen mode Exit fullscreen mode

Complete Production Architecture 

Internet
      │
Route53
      │
ALB
      │
Ingress Controller
      │
Ingress
      │
Service
      │
Deployment
      │
Pods
      │
├── ConfigMap
│      ├── DB_HOST
│      ├── REDIS_HOST
│      └── LOG_LEVEL
│
└── Secret
       ├── DB_PASSWORD
       ├── JWT_SECRET
       └── TLS_CERT
Enter fullscreen mode Exit fullscreen mode

Next Topic (Very Important)

The next topic is Labels & Selectors.

This is one of the most fundamental Kubernetes concepts because almost every resource depends on it:

  • Deployment → ReplicaSet
  • ReplicaSet → Pods
  • Service → Pods
  • NetworkPolicy → Pods
  • Monitoring → Pods

Without understanding Labels & Selectors, it's impossible to fully understand how Kubernetes resources are connected.

Excellent. Now we reach the foundation of Kubernetes.

If I ask you:

How does a Service know which Pods belong to it?

How does a Deployment know which Pods it owns?

How does a NetworkPolicy know which Pods to allow?

The answer to all three is:

Labels & Selectors

This is one of the most important interview topics because almost every Kubernetes object depends on it.

Topic 13 — Labels & Selectors (Master Level)

First Understand the Problem

Suppose your cluster has 500 Pods.

payment-7d8f9

payment-8h7j2

payment-4k5l1

order-2a4d7

order-6t9m8

redis-abc

mysql-xyz
Enter fullscreen mode Exit fullscreen mode

Now suppose a Service needs to send traffic only to the Payment Pods.

How will Kubernetes know?

By Pod names?

No.

Pod names change.

By IP?

No.

IPs change.

Solution

Labels.

Every Pod can have metadata.

Example

metadata:
  labels:
    app: payment
Enter fullscreen mode Exit fullscreen mode

Another Pod

metadata:
  labels:
    app: order
Enter fullscreen mode Exit fullscreen mode

Now Kubernetes can identify them.

What is a Label?

A Label is a key-value pair attached to a Kubernetes object.

Example

labels:
  app: payment
Enter fullscreen mode Exit fullscreen mode

Key

app
Enter fullscreen mode Exit fullscreen mode

Value

payment
Enter fullscreen mode Exit fullscreen mode

Real Company Example

Amazon

Payment Team

↓

app=payment
Enter fullscreen mode Exit fullscreen mode

Order Team

↓

app=order
Enter fullscreen mode Exit fullscreen mode

Redis

↓

app=redis
Enter fullscreen mode Exit fullscreen mode

Everything becomes easy to identify.

Labels are NOT only for Pods

Labels can be added to

  • Pods
  • Deployments
  • Services
  • Nodes
  • Namespaces
  • ConfigMaps
  • PersistentVolumes
  • Almost every Kubernetes object

Common Labels 

labels:
  app: payment
  env: prod
  tier: backend
  version: v1
  team: payments
Enter fullscreen mode Exit fullscreen mode

Meaning

app = Which application?

env = Which environment?

tier = Frontend or Backend?

version = Application version?

team = Owning team?
Enter fullscreen mode Exit fullscreen mode

Example 

labels:

  app: payment

  env: production

  version: v2

  region: ap-south-1

  team: backend
Enter fullscreen mode Exit fullscreen mode

What is a Selector?

A Selector is a query used to find objects based on labels.

Example

selector:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Meaning

Find

app=payment
Enter fullscreen mode Exit fullscreen mode

Pods.

Architecture 

Pods

Pod1

app=payment

Pod2

app=payment

Pod3

app=order

↓

Service Selector

↓

app=payment

↓

Pod1

Pod2
Enter fullscreen mode Exit fullscreen mode

Pod3 ignored.

Service Example

Pods

labels:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Service

selector:

  app: payment
Enter fullscreen mode Exit fullscreen mode

Automatically connects.

Deployment Example

Deployment

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

Deployment only manages Pods having

app=payment
Enter fullscreen mode Exit fullscreen mode

ReplicaSet Example

ReplicaSet

↓

Selector

↓

Pods

Everything is connected through labels.

Node Labels

Nodes also have labels.

Example

node1

↓

gpu=true
Enter fullscreen mode Exit fullscreen mode

DaemonSet

nodeSelector:

  gpu: "true"
Enter fullscreen mode Exit fullscreen mode

Runs only there.

MatchLabels

Most common selector.

selector:

  matchLabels:

    app: payment
Enter fullscreen mode Exit fullscreen mode

Meaning

Exactly

app=payment
Enter fullscreen mode Exit fullscreen mode

MatchExpressions

More powerful.

Example

matchExpressions:

- key: env

  operator: In

  values:

  - prod

  - stage
Enter fullscreen mode Exit fullscreen mode

Meaning

Accept

env=prod
Enter fullscreen mode Exit fullscreen mode

or

env=stage
Enter fullscreen mode Exit fullscreen mode

Operators

In 

env In (prod,stage)
Enter fullscreen mode Exit fullscreen mode

NotIn 

env NotIn (dev)
Enter fullscreen mode Exit fullscreen mode

Exists 

team Exists
Enter fullscreen mode Exit fullscreen mode

Any Pod having the team label matches.

DoesNotExist 

debug DoesNotExist
Enter fullscreen mode Exit fullscreen mode

Pods without a debug label match.

Real Example

Pods

payment

env=prod
Enter fullscreen mode Exit fullscreen mode 
order

env=dev
Enter fullscreen mode Exit fullscreen mode

Selector

matchExpressions:

- key: env

  operator: In

  values:

  - prod
Enter fullscreen mode Exit fullscreen mode

Only Payment Pod selected.

Commands

Show Labels

kubectl get pods --show-labels
Enter fullscreen mode Exit fullscreen mode

Filter

kubectl get pods -l app=payment
Enter fullscreen mode Exit fullscreen mode

Multiple Labels

kubectl get pods -l app=payment,env=prod
Enter fullscreen mode Exit fullscreen mode

Add Label

kubectl label pod payment-abc version=v2
Enter fullscreen mode Exit fullscreen mode

Remove Label

kubectl label pod payment-abc version-
Enter fullscreen mode Exit fullscreen mode

Why Labels Matter

Without labels

Service

↓

???

↓

500 Pods
Enter fullscreen mode Exit fullscreen mode

Impossible.

With labels

Service

↓

app=payment

↓

Only Payment Pods
Enter fullscreen mode Exit fullscreen mode

Real Production Example

Spring Boot

payment

↓

labels

app=payment

env=prod

version=v2
Enter fullscreen mode Exit fullscreen mode

Service

↓

app=payment
Enter fullscreen mode Exit fullscreen mode

NetworkPolicy

↓

app=payment
Enter fullscreen mode Exit fullscreen mode

Prometheus

↓

app=payment
Enter fullscreen mode Exit fullscreen mode

Everything works because of labels.

Labels vs Names

Pod Name

payment-6d8f79c4b-jvksl
Enter fullscreen mode Exit fullscreen mode

Changes after recreation.

Label

app=payment
Enter fullscreen mode Exit fullscreen mode

Doesn't change unless you change it.

Best Practices

Good labels

labels:
  app: payment
  env: prod
  version: v1
  tier: backend
  team: payments
Enter fullscreen mode Exit fullscreen mode

Avoid using changing values (like timestamps) as labels because labels are meant for grouping and selection.

Common Interview Questions

Q1. What is a Label?

A key-value pair attached to a Kubernetes object for identification and organization.

Q2. What is a Selector?

A mechanism to select Kubernetes objects based on their labels.

Q3. Why do Services use labels?

Services use label selectors to discover and route traffic to the correct Pods.

Q4. Can Deployments use selectors?

Yes.

Deployments use selectors to identify the Pods they manage.

Q5. Difference between Labels and Selectors?

  • Label: Metadata attached to an object.
  • Selector: A query used to find objects with matching labels.

Q6. What is matchLabels?

An exact label match.

Example:

matchLabels:
  app: payment
Enter fullscreen mode Exit fullscreen mode

Q7. What is matchExpressions?

A more flexible selector supporting operators like In, NotIn, Exists, and DoesNotExist.

Q8. Can one Pod have multiple labels?

Yes.

Example:

labels:
  app: payment
  env: prod
  version: v2
  team: backend
Enter fullscreen mode Exit fullscreen mode

Q9. Can two Pods have the same label?

Yes.

In fact, that's the common pattern. A Service usually selects many Pods that share the same label.

Q10. Give a real-world example.

A Payment Service might use:

selector:
  app: payment
Enter fullscreen mode Exit fullscreen mode

to route requests to every Payment Pod, regardless of their individual names or IP addresses.

Where Labels Are Used

Kubernetes Resource Uses Labels?
Deployment ✅
ReplicaSet ✅
Service ✅
StatefulSet ✅
DaemonSet ✅
Job ✅
CronJob ✅
NetworkPolicy ✅
PodAffinity / AntiAffinity ✅
Monitoring (Prometheus) ✅

Complete Production Flow 

Deployment
      │
      ▼
Selector (app=payment)
      │
      ▼
Pods
      │
      ▼
Service (selector: app=payment)
      │
      ▼
Ingress
      │
      ▼
Internet
Enter fullscreen mode Exit fullscreen mode

Notice something important:

Labels are the glue that connects Kubernetes resources together.

Without labels, Services wouldn't know which Pods to route to, Deployments wouldn't know which Pods to manage, and many other Kubernetes features would stop working.

Next Topic (One of the Hardest Interview Topics)

The next topic should be Networking (Pod-to-Pod Communication, CNI, ClusterIP, kube-proxy, Network Policies).

This is one of the deepest Kubernetes topics and is commonly asked in senior DevOps and platform engineering interviews because it explains:

  • How Pods on different nodes communicate.
  • Why every Pod gets its own IP.
  • What CNI plugins (Calico, Cilium, Flannel) do.
  • How kube-proxy routes Service traffic.
  • How NetworkPolicies secure Pod communication.

Once you master Kubernetes networking, you'll understand the core of how a cluster actually works.

Excellent. This is the topic that separates beginner Kubernetes engineers from experienced DevOps engineers.

Most people know how to create a Pod.

Very few know how a packet travels from one Pod to another.

Senior interviewers often ask questions like:

  • How does Pod A communicate with Pod B on another node?
  • Who assigns Pod IPs?
  • What is CNI?
  • What does kube-proxy do?
  • Why does every Pod have a unique IP?
  • How do Services load balance traffic?
  • How do NetworkPolicies block traffic?

If you master this topic, you'll understand the networking foundation of Kubernetes.

Topic 14 — Kubernetes Networking (Master Level)

Kubernetes Networking Rules

Every Kubernetes cluster follows these fundamental rules:

Rule 1

Every Pod gets its own unique IP address.

Example

payment-1

10.244.1.5
Enter fullscreen mode Exit fullscreen mode 
payment-2

10.244.1.6
Enter fullscreen mode Exit fullscreen mode

No two Pods share the same IP.

Rule 2

Pods can communicate directly with each other.

Example

Pod A

↓

Pod B
Enter fullscreen mode Exit fullscreen mode

No NAT is required for Pod-to-Pod communication.

Rule 3

Pods on different Nodes can also communicate directly.

Example

Node-1

Pod A

↓

↓

Node-2

Pod B
Enter fullscreen mode Exit fullscreen mode

Even on different nodes, communication should work.

Rule 4

Services provide a stable virtual IP (ClusterIP) for a group of Pods.

Applications usually talk to Services instead of Pod IPs.

Real Production Example

Suppose you have:

Order Service

↓

Payment Service

↓

Inventory Service
Enter fullscreen mode Exit fullscreen mode

Pods

Order Pod

10.244.1.10
Enter fullscreen mode Exit fullscreen mode 
Payment Pod

10.244.2.20
Enter fullscreen mode Exit fullscreen mode

Different Nodes.

Still communicate successfully.

Question

Who gives Pods their IP addresses?

Answer:

The CNI Plugin

What is CNI?

CNI stands for

Container Network Interface
Enter fullscreen mode Exit fullscreen mode

It is the networking standard used by Kubernetes to connect Pods to the network.

The kubelet calls the CNI plugin whenever a Pod is created or deleted.

Responsibilities of CNI

When a Pod starts:

  • Create a network interface
  • Assign a Pod IP
  • Connect Pod to the cluster network
  • Configure routes
  • Configure networking rules

Without a CNI plugin, Pods cannot communicate.

Popular CNI Plugins

Plugin Highlights
Calico Routing + NetworkPolicy support
Cilium eBPF-based, high performance, advanced security
Flannel Simple overlay networking
Weave Net Overlay networking
AWS VPC CNI Uses VPC IPs directly for Pods in EKS

Architecture 

Node-1

Pod A

10.244.1.5

↓

CNI

↓

Network

↓

Node-2

Pod B

10.244.2.6
Enter fullscreen mode Exit fullscreen mode

The CNI plugin makes this communication possible.

Pod-to-Pod Communication

Example

Spring Boot Pod

↓

HTTP Request

↓

Redis Pod
Enter fullscreen mode Exit fullscreen mode

Traffic

10.244.1.5

↓

10.244.2.6
Enter fullscreen mode Exit fullscreen mode

Direct communication.

Different Nodes 

Node-1

Order Pod

10.244.1.3
Enter fullscreen mode Exit fullscreen mode

↓

↓

Node-2

Payment Pod

10.244.2.8
Enter fullscreen mode Exit fullscreen mode

CNI handles routing between nodes.

Who Creates Pod IP?

Flow

Scheduler

↓

Node Selected

↓

Kubelet

↓

CNI Plugin

↓

Assign Pod IP

↓

Pod Starts
Enter fullscreen mode Exit fullscreen mode

What is ClusterIP?

Suppose

Three Payment Pods

payment-1

10.244.1.5
Enter fullscreen mode Exit fullscreen mode 
payment-2

10.244.1.6
Enter fullscreen mode Exit fullscreen mode 
payment-3

10.244.2.7
Enter fullscreen mode Exit fullscreen mode

Service

payment-service

↓

10.96.0.15
Enter fullscreen mode Exit fullscreen mode

Applications call

payment-service
Enter fullscreen mode Exit fullscreen mode

instead of individual Pod IPs.

Traffic Flow 

Order Pod

↓

payment-service

↓

ClusterIP

↓

Payment Pods
Enter fullscreen mode Exit fullscreen mode

What is kube-proxy?

One of the most asked interview questions.

kube-proxy runs on every Node.

Responsibilities:

  • Watches Service and Endpoint/EndpointSlice changes
  • Programs networking rules (iptables, IPVS, or nftables depending on mode and platform)
  • Routes Service traffic to backend Pods

It does not create Pods or assign Pod IPs.

Architecture 

Order Pod

↓

ClusterIP

↓

kube-proxy

↓

Payment Pod
Enter fullscreen mode Exit fullscreen mode

Does kube-proxy Load Balance?

Yes.

Suppose

Payment1

Payment2

Payment3
Enter fullscreen mode Exit fullscreen mode

Request 1

↓

Payment1

Request 2

↓

Payment2

Request 3

↓

Payment3

The exact distribution depends on the kube-proxy mode (iptables/IPVS) and connection behavior.

Endpoints

Service

↓

Needs Pod IPs.

Endpoints (or EndpointSlices in modern Kubernetes) contain those backend addresses.

Example

payment-service

↓

Endpoints

↓

10.244.1.5

10.244.1.6

10.244.2.7
Enter fullscreen mode Exit fullscreen mode

EndpointSlice

Modern Kubernetes uses EndpointSlices to scale better than the older Endpoints object.

Interview tip:

If asked what replaces Endpoints for large clusters:

Answer:

EndpointSlices

DNS Flow 

Order Pod

↓

payment-service

↓

CoreDNS

↓

ClusterIP

↓

kube-proxy

↓

Payment Pod
Enter fullscreen mode Exit fullscreen mode

Notice how multiple Kubernetes components work together.

Pod-to-Pod Communication Flow 

Spring Boot

↓

DNS Lookup

↓

CoreDNS

↓

ClusterIP

↓

kube-proxy

↓

CNI Network

↓

Payment Pod
Enter fullscreen mode Exit fullscreen mode

Overlay Network

Many CNI plugins create an overlay network.

Example:

Node-1

Pod

10.244.1.5
Enter fullscreen mode Exit fullscreen mode

↓

Overlay

↓

Node-2

Pod

10.244.2.7
Enter fullscreen mode Exit fullscreen mode

Applications don't need to know which Node the destination Pod is running on.

Note: Not every CNI uses an overlay. For example, the AWS VPC CNI assigns VPC IPs directly instead of building an overlay.

AWS EKS Example

In Amazon EKS

Most commonly

AWS VPC CNI
Enter fullscreen mode Exit fullscreen mode

Pod gets a VPC IP address.

No overlay network is required.

This improves integration with AWS networking.

NetworkPolicy

By default, many Kubernetes installations allow Pods to communicate freely unless a NetworkPolicy is enforced (behavior also depends on the CNI plugin).

Suppose

Payment

↓

MySQL
Enter fullscreen mode Exit fullscreen mode

Allowed.

Now

Frontend

↓

MySQL
Enter fullscreen mode Exit fullscreen mode

Should be blocked.

Use

NetworkPolicy
Enter fullscreen mode Exit fullscreen mode

NetworkPolicy Example

Allow only

podSelector:
  matchLabels:
    app: mysql
Enter fullscreen mode Exit fullscreen mode

and permit ingress only from Pods matching:

from:
- podSelector:
    matchLabels:
      app: payment
Enter fullscreen mode Exit fullscreen mode

Now only Payment Pods can reach MySQL.

Real Production Example 

Internet

↓

Ingress

↓

Frontend

↓

Payment

↓

MySQL
Enter fullscreen mode Exit fullscreen mode

Allowed

Frontend

↓

MySQL

Blocked.

Commands

View Pods

kubectl get pods -o wide
Enter fullscreen mode Exit fullscreen mode

Shows Pod IPs.

View Services

kubectl get svc
Enter fullscreen mode Exit fullscreen mode

View Endpoints

kubectl get endpoints
Enter fullscreen mode Exit fullscreen mode

or

kubectl get endpointslices
Enter fullscreen mode Exit fullscreen mode

View NetworkPolicies

kubectl get networkpolicy
Enter fullscreen mode Exit fullscreen mode

Common Interview Questions

Q1. What are the Kubernetes networking rules?

  • Every Pod gets a unique IP.
  • Pods can communicate directly.
  • Pods on different Nodes can communicate.
  • Services provide stable virtual IPs.

Q2. What is CNI?

The Container Network Interface standard and its plugins provide Pod networking by assigning IPs and configuring connectivity.

Q3. Name popular CNI plugins.

  • Calico
  • Cilium
  • Flannel
  • Weave Net
  • AWS VPC CNI

Q4. Who assigns Pod IPs?

The CNI plugin, invoked by the kubelet.

Q5. What is kube-proxy?

A component running on each Node that implements Service networking by programming routing/load-balancing rules.

Q6. Does kube-proxy assign Pod IPs?

No.

The CNI plugin assigns Pod IPs.

Q7. What is ClusterIP?

The default Service type that provides a stable virtual IP for internal communication.

Q8. What is an Endpoint?

A representation of the backend Pods behind a Service. Modern Kubernetes primarily uses EndpointSlices.

Q9. What is a NetworkPolicy?

A resource that controls allowed network traffic between Pods (and optionally namespaces/IP blocks), provided the CNI plugin supports NetworkPolicies.

Q10. How does Pod A communicate with Pod B? 

Pod A
   │
DNS lookup (CoreDNS)
   │
ClusterIP Service
   │
kube-proxy
   │
CNI network
   │
Pod B
Enter fullscreen mode Exit fullscreen mode

If Pod A already knows Pod B's IP (for example, via a headless Service), it may communicate directly without going through a Service.

Component Responsibilities (Very Important)

Component Responsibility
CoreDNS Resolve Service names to IP addresses
Service Stable virtual endpoint
EndpointSlice List backend Pod IPs
kube-proxy Route/load-balance Service traffic
CNI Plugin Assign Pod IPs and connect Pods to the network
NetworkPolicy Control allowed network communication

Complete Request Flow (Spring Boot → Payment) 

Spring Boot Pod
        │
        ▼
http://payment-service
        │
        ▼
CoreDNS
        │
        ▼
ClusterIP
        │
        ▼
kube-proxy
        │
        ▼
EndpointSlice
        │
        ▼
CNI Network
        │
        ▼
Payment Pod
Enter fullscreen mode Exit fullscreen mode

Master Interview Scenario

Interviewer: Explain how a request from the Order Service reaches the Payment Service.

Strong answer:

The Order Service sends a request to the Service DNS name, such as payment-service. CoreDNS resolves that name to the Service's ClusterIP. kube-proxy uses the Service's EndpointSlices to select one of the healthy backend Pods and forwards the traffic. The CNI plugin provides the underlying Pod-to-Pod connectivity, even if the Pods are on different Nodes.

What Should We Cover Next?

The next advanced networking topic is:

NGINX vs Istio (Service Mesh)

This includes:

  • What problems Istio solves that Services and Ingress don't.
  • NGINX vs Ingress Controller vs Istio.
  • Sidecar proxies.
  • Envoy architecture.
  • mTLS.
  • Traffic splitting (90% v1 / 10% v2).
  • Circuit breaking.
  • Retries.
  • Observability.
  • Zero-trust networking.

This is a senior-level Kubernetes and microservices interview topic and is especially valuable if you're targeting backend, DevOps, or platform engineering roles.

Perfect. This is one of the highest-level Kubernetes interview topics.

If you understand this topic, you can answer questions asked in Amazon, Microsoft, Walmart, Flipkart, Adobe, Oracle, VMware, Cisco, and many product companies.

Many engineers confuse:

  • NGINX
  • Ingress
  • Ingress Controller
  • API Gateway
  • Service Mesh
  • Istio
  • Envoy

After this, you won't.

Topic 15 — NGINX vs Ingress vs Istio (Master Level)

First Understand the Evolution

Suppose you have one application.

Internet
    │
Spring Boot
Enter fullscreen mode Exit fullscreen mode

Simple.

Now company grows.

Internet
      │
Frontend

Payment

Order

Inventory

User

Notification

Auth

Shipping
Enter fullscreen mode Exit fullscreen mode

Now routing becomes difficult.

Need something smarter.

Stage 1 — NGINX

Initially companies had

Internet

↓

NGINX

↓

Spring Boot
Enter fullscreen mode Exit fullscreen mode

NGINX acts as

  • Reverse Proxy
  • Load Balancer
  • SSL Termination

Example

Client

↓

NGINX

↓

Spring Boot
Enter fullscreen mode Exit fullscreen mode

What is Reverse Proxy?

Client

Browser
Enter fullscreen mode Exit fullscreen mode

doesn't know backend.

Instead

Browser

↓

NGINX

↓

Backend
Enter fullscreen mode Exit fullscreen mode

NGINX hides backend servers.

Why Use NGINX?

Suppose

5 Spring Boot servers.

Spring1

Spring2

Spring3

Spring4

Spring5
Enter fullscreen mode Exit fullscreen mode

NGINX

↓

Load balances.

SSL Termination

Without NGINX

HTTPS

↓

Spring Boot
Enter fullscreen mode Exit fullscreen mode

Every application handles SSL.

Instead

HTTPS

↓

NGINX

↓

HTTP

↓

Spring Boot
Enter fullscreen mode Exit fullscreen mode

Much easier.

Then Kubernetes Came

Now

Pods keep changing.

payment-a12

↓

Deleted
Enter fullscreen mode Exit fullscreen mode

New Pod

payment-z45
Enter fullscreen mode Exit fullscreen mode

NGINX cannot manually track every Pod.

Need Kubernetes integration.

Solution

Ingress.

What is Ingress?

Ingress is not software.

It is a Kubernetes API resource that defines HTTP/HTTPS routing rules.

Example

host: amazon.com

↓

payment-service
Enter fullscreen mode Exit fullscreen mode

Important Interview Trap

Question

Is Ingress a Load Balancer?

No.

Ingress is only a configuration object.

Something must read it.

Who Reads Ingress?

Ingress Controller.

What is Ingress Controller?

Real software.

Examples

  • NGINX Ingress Controller
  • AWS Load Balancer Controller
  • Traefik
  • HAProxy
  • Kong

It watches Ingress resources and configures routing.

Architecture 

Internet

↓

NGINX Ingress Controller

↓

Ingress Rules

↓

Services

↓

Pods
Enter fullscreen mode Exit fullscreen mode

Example

Ingress

/api/payment

↓

payment-service
Enter fullscreen mode Exit fullscreen mode 
/api/order

↓

order-service
Enter fullscreen mode Exit fullscreen mode

Browser

/api/payment
Enter fullscreen mode Exit fullscreen mode

↓

Payment Service.

Host Based Routing 

payment.company.com

↓

Payment
Enter fullscreen mode Exit fullscreen mode 
order.company.com

↓

Order
Enter fullscreen mode Exit fullscreen mode

Same Ingress Controller.

Different Services.

Path Based Routing 

/api/payment

↓

Payment
Enter fullscreen mode Exit fullscreen mode 
/api/order

↓

Order
Enter fullscreen mode Exit fullscreen mode

Can Ingress Load Balance?

Indirectly.

Flow

Ingress

↓

Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

The Service performs load balancing to Pods (with kube-proxy or the underlying dataplane).

Real Production Flow 

Internet

↓

AWS ALB

↓

NGINX Ingress Controller

↓

Ingress

↓

ClusterIP Service

↓

Pods
Enter fullscreen mode Exit fullscreen mode

Where Does Istio Come?

Suppose

100 Microservices.

Payment

↓

Order

↓

Inventory

↓

Shipping

↓

Email

↓

Redis

↓

Kafka
Enter fullscreen mode Exit fullscreen mode

Every service talks to every other service.

Need

  • Security
  • Retry
  • Circuit Breaker
  • Metrics
  • mTLS
  • Traffic Control

Can Ingress do this?

No.

Service Mesh

Istio is a Service Mesh.

It manages service-to-service communication inside the cluster.

Biggest Difference

Ingress

↓

North-South Traffic

(Internet → Cluster)

Istio

↓

East-West Traffic

(Service → Service)

North-South 

Internet

↓

Cluster
Enter fullscreen mode Exit fullscreen mode

East-West 

Payment

↓

Inventory

↓

Shipping

↓

User

↓

Redis
Enter fullscreen mode Exit fullscreen mode

Internal communication.

How Istio Works

Istio injects an Envoy sidecar proxy into each Pod.

Instead of

Spring Boot

↓

Spring Boot
Enter fullscreen mode Exit fullscreen mode

Traffic becomes

Spring

↓

Envoy

↓

Envoy

↓

Spring
Enter fullscreen mode Exit fullscreen mode

Applications don't need to implement these networking features themselves.

Sidecar

Payment Pod

Spring Boot

+

Envoy
Enter fullscreen mode Exit fullscreen mode

Order Pod

Spring Boot

+

Envoy
Enter fullscreen mode Exit fullscreen mode

Every Pod gets Envoy (when sidecar injection is enabled).

Why Envoy?

Envoy provides

  • Routing
  • Retry
  • Timeout
  • Metrics
  • mTLS
  • Load balancing
  • Circuit breaking
  • Observability

Retry

Without Istio

Spring Boot code

RetryTemplate
Enter fullscreen mode Exit fullscreen mode

With Istio

Retry

↓

Configured in Istio
Enter fullscreen mode Exit fullscreen mode

No code changes.

Circuit Breaker

Payment Service

↓

Down.

Without Istio

Every request waits and eventually times out.

With Istio

Circuit opens.

Requests fail fast until the service recovers.

mTLS

Without Istio

Payment

↓

HTTP

↓

Inventory
Enter fullscreen mode Exit fullscreen mode

Traffic may be unencrypted inside the cluster.

With Istio

Payment

↓

Encrypted (mTLS)

↓

Inventory
Enter fullscreen mode Exit fullscreen mode

Both services authenticate each other and encrypt traffic.

Traffic Splitting

Suppose

New Version

Payment v2
Enter fullscreen mode Exit fullscreen mode

Need

10%

traffic.

Istio

90%

↓

v1

10%

↓

v2
Enter fullscreen mode Exit fullscreen mode

Perfect for Canary Deployment.

Blue Green

Istio can shift

100%

↓

Blue
Enter fullscreen mode Exit fullscreen mode

to

100%

↓

Green
Enter fullscreen mode Exit fullscreen mode

without changing application code.

Observability

Istio automatically collects

  • Latency
  • Error Rate
  • Request Count
  • Success Rate

No application changes required.

Architecture 

Internet

↓

ALB

↓

NGINX Ingress Controller

↓

Payment Pod

Spring Boot

+

Envoy

↓

Inventory Pod

Spring Boot

+

Envoy
Enter fullscreen mode Exit fullscreen mode

NGINX vs Ingress vs Istio

Feature NGINX Ingress Istio
Software ✅ ❌ (API Resource) ✅
Reverse Proxy ✅ ❌ Via Envoy
External Routing ✅ Defines rules Limited (through Gateway)
Internal Routing ❌ ❌ ✅
mTLS ❌ ❌ ✅
Traffic Splitting Limited ❌ ✅
Circuit Breaker ❌ ❌ ✅
Retries ❌ ❌ ✅
Observability Basic ❌ Rich telemetry
Sidecar Proxy ❌ ❌ ✅ (Envoy)

Interview Questions

Q1. What is Ingress?

A Kubernetes API resource that defines HTTP/HTTPS routing rules into the cluster.

Q2. Is Ingress a Load Balancer?

No.

It only defines routing rules.

An Ingress Controller implements those rules.

Q3. What is an Ingress Controller?

A controller (such as NGINX Ingress Controller or Traefik) that watches Ingress resources and configures routing.

Q4. Difference between NGINX and Ingress?

NGINX is software.

Ingress is a Kubernetes resource.

NGINX Ingress Controller is software that implements Ingress.

Q5. What is Istio?

A service mesh that manages service-to-service communication using Envoy proxies.

Q6. What problem does Istio solve?

It provides:

  • mTLS
  • Retries
  • Timeouts
  • Circuit breaking
  • Traffic management
  • Observability
  • Policy enforcement

without requiring application code changes.

Q7. What is a Sidecar?

An additional container running in the same Pod as the application.

In Istio, the sidecar is typically an Envoy proxy.

Q8. What is East-West traffic?

Communication between services inside the cluster.

Q9. What is North-South traffic?

Traffic entering or leaving the cluster (for example, users accessing your application).

Q10. Can Istio replace Ingress?

Not exactly.

Istio has its own Gateway for external traffic, but many production environments still use an external load balancer and sometimes an Ingress Controller depending on architecture and operational preferences.

Real Production Architecture 

                    Internet
                        │
                 AWS Route53
                        │
                 AWS ALB (Load Balancer)
                        │
               NGINX Ingress Controller
                        │
                  Ingress Rules
                        │
              ┌─────────┴─────────┐
              │                   │
      payment-service      order-service
              │                   │
      ┌───────┘                   └───────┐
      │                                   │
+------------------+             +------------------+
| Payment Pod      |             | Order Pod        |
| Spring Boot      |             | Spring Boot      |
| Envoy Sidecar    |◄──────────► | Envoy Sidecar    |
+------------------+   mTLS      +------------------+
             │
             ▼
     inventory-service
             │
+----------------------+
| Inventory Pod        |
| Spring Boot          |
| Envoy Sidecar        |
+----------------------+
Enter fullscreen mode Exit fullscreen mode

Complete Kubernetes Roadmap So Far 

Namespace
    │
Labels
    │
Deployment
    │
ReplicaSet
    │
Pods
    │
Service
    │
CoreDNS
    │
Ingress
    │
Ingress Controller
    │
ConfigMap
    │
Secrets
    │
StatefulSet
    │
DaemonSet
    │
Job
    │
CronJob
    │
Networking
    │
CNI
    │
kube-proxy
    │
NetworkPolicy
    │
NGINX
    │
Ingress
    │
Istio
Enter fullscreen mode Exit fullscreen mode

Senior Interview Tip

One of the strongest answers you can give is to clearly distinguish the responsibilities:

  • NGINX: Reverse proxy and web server.
  • Ingress: Kubernetes routing configuration.
  • Ingress Controller: Software that enforces Ingress rules.
  • Service: Internal stable endpoint for Pods.
  • Istio: Service mesh for secure, observable, and controlled service-to-service communication.
  • Envoy: Sidecar proxy that carries out Istio's traffic management policies.

Understanding where each component fits in the request path is what interviewers are usually looking for.

Top comments (0)