Kubernetes Pods Explained: Lifecycle, Probes, Init Containers, Sidecars, and Resources

Kubernetes Pods Explained: Lifecycle, Probes, Init Containers, Sidecars, and Resources

A Pod is Kubernetes' smallest deployable compute unit. It usually runs one main application container, but tightly coupled helper containers can share the same Pod, network namespace, and volumes.

Pods Are Ephemeral

Pods are replaceable. If a Deployment recreates a Pod, the new Pod gets a new identity/IP. Do not build application logic around one specific Pod surviving forever.

Normally you create Pods through controllers such as Deployments, StatefulSets, Jobs, or DaemonSets rather than managing bare Pods manually.

Resource Requests and Limits

Requests help the scheduler decide where a Pod can fit. Limits constrain resource usage at runtime.

resources:
  requests:
    cpu: 200m
    memory: 256Mi
  limits:
    memory: 512Mi

Bad requests lead to poor scheduling and misleading autoscaling. Overly tight memory limits can create OOM kills.

Probes Have Different Jobs

• Startup probe — gives slow applications time to initialize.
• Readiness probe — decides whether the Pod should receive Service traffic.
• Liveness probe — decides when Kubernetes should restart a stuck container.

Do not make liveness fail simply because one downstream dependency is temporarily unavailable; that can create restart storms.

Init Containers

Init containers run to completion before normal app containers start. Use them for setup work such as generating config, preparing files, or waiting for a required condition.

Keep initialization deterministic and bounded. A permanently failing init container prevents the Pod from starting.

Sidecars

Native sidecar containers are stable in current Kubernetes. They run alongside the main app and are useful for tightly coupled helpers such as local proxies or log/data synchronization.

Do not add a sidecar for every platform feature. Every sidecar consumes resources and shares the Pod's lifecycle/failure boundary.

Graceful Termination

When a Pod terminates, Kubernetes removes it from normal Service traffic and sends termination signals to containers. Set terminationGracePeriodSeconds and application shutdown behavior so in-flight work can finish where required.

Final Takeaway

A Pod is a shared lifecycle and scheduling boundary. Put containers together only when they truly need to share that boundary, define realistic resources, use probes for the right purposes, and let higher-level controllers replace Pods when they fail.

References

• Kubernetes Pods
• Pod Lifecycle
• Resource Management
• Sidecar Containers