AKS Pod Lifecycle: From kubectl to Running

1️⃣ kubectl apply -f pod.yaml

You apply the pod definition file.

2️⃣ 🧠 kubectl talks to the API Server

• kubectl sends a REST request to the Kubernetes API Server (kube-apiserver).
• This request contains the pod specs you defined (metadata, containers, image, etc.).

3️⃣ 📦 API Server stores pod data in etcd

• The API Server validates the request.
• If valid, it stores the pod’s desired state in the etcd database (Kubernetes’ source of truth).

4️⃣ 👀 Scheduler checks for new unscheduled pods

• The Kube Scheduler sees that the new pod doesn’t have a nodeName.
• It selects the best node to run the pod (based on resources, taints, etc.).
• It updates the pod’s spec with the chosen node.

5️⃣ 📬 Kubelet on the selected node is notified

• The Kubelet (agent running on every node) watches the API Server for assigned pods.
• It sees the new pod assigned to its node.

6️⃣ 📥 Kubelet pulls container image & starts pod

• Kubelet pulls the container image from the registry (like Docker Hub or ACR).
• It creates the pod via the container runtime (like containerd or Docker).

7️⃣ 🔍 Readiness/Liveness Probes (Optional)

• If configured, Kubelet runs liveness and readiness probes to ensure the pod is healthy and ready to receive traffic.

8️⃣ ✅ Pod is now Running

• Pod status is updated in etcd as Running.
• Services (if any) can now route traffic to it.

Summary in Flow Format:

kubectl → API Server → etcd (store state)
↓
Scheduler (assigns node)
↓
Kubelet (on assigned node)
↓
Pull image & start container
↓
Health checks → Pod Running

After this it also go through other cycle

kubectl apply → API Server → etcd
↓
Scheduler assigns node
↓
Kubelet sees new pod
↓
Pull image
↓
➡️ [1] Run init containers (sequentially)
↓
➡️ [2] Run main containers (in parallel)
↓
➡️ [3] Start probes (health checks)
↓
Pod status: Running ✅

Pod Lifecycle After Scheduling – Detailed Flow

Once the Kubelet pulls the image and prepares to start the pod:

---

1️⃣ Init Containers Run First (if defined)

• Init containers are special containers that run one after another before any main container starts.
• Each must succeed (exit 0) for the next to run.
• Their jobs can be:
  • Copying config files
  • Checking dependencies
  • Setting permissions
• If any init container fails, it is retried until it succeeds or the pod is marked failed.

🔸 Note: Init containers do not run in parallel and do not restart after success.

---

2️⃣ Main Containers Start

• Once all init containers are done, main containers start in parallel.
• These are the core app containers (e.g. nginx, node, python apps).
• They stay alive until:
  • They exit (gracefully or crash)
  • You delete the pod
  • The node fails

---

3️⃣ Liveness and Readiness Probes Begin (if defined)

✅ Readiness Probe

• Tells when the container is ready to receive traffic.
• Example: HTTP request to /healthz endpoint.
• If it fails, the container is removed from service endpoints, but not restarted.

❤️ Liveness Probe

• Tells if the container is healthy/alive.
• If it fails, Kubernetes restarts the container.

These checks start only after the main containers are running.