# Kubernetes Pod Mastery - Module 2 Notes
## Process Lifecycle, Restart Policies, Command & Args

------------------------------------------------------------
1. CONTAINER PROCESS LIFECYCLE
------------------------------------------------------------

Every container has ONE main process (PID 1).

The lifecycle of the container depends on this process.

• If the main process is running
  → Container = Running

• If the main process exits with Exit Code 0
  → Container = Completed

• If the main process exits with a non-zero Exit Code
  → Container = Error

Examples:

sleep 300
→ Running

echo "Hello Kubernetes"
→ Completed (Exit Code 0)

false
→ Error (Exit Code 1)

------------------------------------------------------------
2. RESTART POLICIES
------------------------------------------------------------

The kubelet monitors the main process of every container.

When the process exits, kubelet checks the Pod's restartPolicy before deciding whether to create a new container.

There are three restart policies.

A) restartPolicy: Never

• Never restart the container.

Exit Code 0
→ Completed

Exit Code 1
→ Error

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

B) restartPolicy: OnFailure

• Restart only when the process exits with a non-zero Exit Code.

Exit Code 0
→ No Restart

Exit Code 1
→ Restart

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

C) restartPolicy: Always

• Restart the container regardless of whether it exits successfully or fails.

Exit Code 0
→ Restart

Exit Code 1
→ Restart

------------------------------------------------------------
3. CrashLoopBackOff
------------------------------------------------------------

CrashLoopBackOff is NOT a restart policy.

It is a waiting state where kubelet repeatedly restarts a container and applies an exponential backoff delay before trying again.

CrashLoopBackOff can occur when:

• Application exits with Exit Code 1 repeatedly.

OR

• Application exits successfully (Exit Code 0) very quickly (for example sleep 2) while restartPolicy is Always.

The kubelet gradually increases the delay between restart attempts.

------------------------------------------------------------
4. COMMAND AND ARGS
------------------------------------------------------------

Kubernetes uses:

command
→ Executable

args
→ Arguments passed to the executable

Final execution is conceptually:

command[] + args[]

Example:

command:
- echo
- hello

args:
- kubernetes

Final execution:

echo hello kubernetes

The first element of command is the executable.

The remaining elements of command become arguments.

The args array is appended after those arguments.

------------------------------------------------------------
5. Docker ENTRYPOINT and CMD
------------------------------------------------------------

Docker images contain default startup information.

Docker ENTRYPOINT
=
Kubernetes command

Docker CMD
=
Kubernetes args

Images also store metadata like:

• ENTRYPOINT
• CMD
• ENV
• USER
• WORKDIR
• EXPOSE
• LABEL
etc.

------------------------------------------------------------
6. OVERRIDE RULES
------------------------------------------------------------

Case 1

No command
No args

Result:

Use Image ENTRYPOINT
+
Use Image CMD

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

Case 2

Only args

Result:

Use Image ENTRYPOINT

Replace Image CMD with Pod args

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

Case 3

Only command

Result:

Use Pod command

Ignore Image ENTRYPOINT

Ignore Image CMD

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

Case 4

command + args

Result:

Use Pod command

Use Pod args

Ignore Image ENTRYPOINT

Ignore Image CMD

------------------------------------------------------------
7. HOW KUBERNETES STARTS A CONTAINER
------------------------------------------------------------

kubectl apply
        |
        V
API Server
        |
        V
Scheduler
        |
        V
Kubelet
        |
        V
Container Runtime (containerd / CRI-O)
        |
        V
OCI Runtime (runc)
        |
        V
Linux execve()
        |
        V
Container Starts

------------------------------------------------------------
8. INTERNAL FLOW
------------------------------------------------------------

The image is NEVER modified.

The image already contains metadata:

• ENTRYPOINT
• CMD
• ENV
• USER
• WORKDIR

Containerd pulls the image and reads this metadata.

Kubelet reads the Pod specification.

Kubelet sends any overrides such as:

• command
• args
• environment variables
• volume mounts
• security settings

Containerd combines:

Image defaults
+
Pod overrides

Containerd generates the OCI Runtime Specification.

Finally, runc executes the Linux process using execve().

------------------------------------------------------------
9. IMPORTANT CKA POINTS
------------------------------------------------------------

✓ Every container has one main process.

✓ Exit Code 0 = Completed.

✓ Exit Code non-zero = Error.

✓ Kubelet decides whether to restart a container.

✓ CrashLoopBackOff is a restart backoff state, not a restart policy.

✓ command specifies the executable.

✓ args specifies arguments.

✓ command overrides the image ENTRYPOINT.

✓ args overrides the image CMD.

✓ Images are read-only; Kubernetes never modifies an image.

✓ Containerd reads image metadata and combines it with kubelet's Pod configuration before starting the container.

------------------------------------------------------------
10. MY MENTAL MODEL
------------------------------------------------------------

Whenever I troubleshoot a Pod, I ask these questions:

1. What is the main process?

2. Is the process still running?

3. If it exited:
   - What is the Exit Code?

4. What is the restartPolicy?

5. Is kubelet restarting the container?

6. Is the container in CrashLoopBackOff?

7. What executable (command) is Kubernetes starting?

8. What arguments (args) are being passed?

If I can answer these questions, I can usually determine why a Pod is in Running, Completed, Error, or CrashLoopBackOff.