Understanding Pause Containers and Pod Disruptions in Kubernetes

About Pause container

• It is a process in Kubernetes that is associated with the container, a namespace holder, and a process manager that facilitates signal handling of the resources.

• It holds the pod network namespace.

• It is useful for pod lifecycle management.

• If the container within the pod restarts the pod IP will remain the same.

• Signal forwarding from one container to another container inside the pod.

• The pod will be active even if its container is not because the pause container was running.

About Pod disruptions

It was broadly divided into two categories:

1. Voluntary disruption:
   It is the intentional termination of pods on nodes by application owners or cluster administrators.
   Example:
   - Updating a deployment's pod template
   - Deleting deployment
   - Draining node for repair or upgrade
   - Deployment draining, etc.

2. Involuntary disruption:
   When pods on nodes are terminated due to unintentional events or failures.
   Example:
   - Node crashes
   - Hardware failure
   - A pod is evicted because the node is out of resources
   - Kernel panic
   - VM delete, etc.

Mitigation for involuntary disruption

1. Specify pod requests

2. More replicas for HA

3. Replicas with Anti-affinity

Pod disruption budget (PDB)

It helps maintain pod availability during voluntary disruptions by limiting the number of pods that can be down simultaneously.

Example: We have a deployment with 3 replicas with the PDB of 2 pods.

Case1:

Here, if we drain server A, then, as per the PDB, it will allow the eviction of 1 pod; hence, it will create pod(P1) either in Server B or C, depending upon the node capacity.

Case2:

Here, Server A was already drained, and Server C is running at full capacity, now if we drain Server B then as per the PDB it will evict only one pod but Server B has two, hence it will hold the node draining.

Sample configuration:

Github: https://github.com/minex970/kubernetes-overview/tree/main/pdb