Kubernetes Pod Concepts in Action: Real-World Use Cases

As Kubernetes adoption grows, understanding some advanced pod-related concepts can help you build more resilient, secure, and observable workloads. In this article, we break down four such concepts and provide real-world use cases where they shine.

---

1. Sidecar Containers: Your App's Personal Assistant

Official Docs

What It Is:

A sidecar container is a secondary container that runs in the same pod as your main application container. It shares the pod’s network and volumes and often provides supporting capabilities — acting like a helper process.

Why It Matters:

It allows modular and reusable components without modifying your main app. Think log collectors, proxy agents, or synchronizers.

Real-World Use Cases:

Centralized Logging (Observability):
A fintech company needed better visibility into distributed logs across clusters. They deployed Fluentd as a sidecar to each app pod. Fluentd tailed application logs from a shared volume and shipped them to an ELK stack for real-time analysis.

TLS Certificate Management:
In secure environments, managing certs manually is painful. Cert-manager runs a sidecar injector that automatically renews and mounts TLS certs into pods, helping with HTTPS services.

Config Syncing from Git:
GitOps tools like ArgoCD can use a sidecar (git-sync) to regularly pull updated config files or manifests from a Git repo without restarting the main application.

API Proxy for Security:
Enterprises deploy Envoy or Istio sidecars to enforce traffic policies, authentication, and observability. This isolates networking concerns from the application code.

Pro Tip: Sidecars scale with your app, are loosely coupled, and can be reused across multiple workloads.

---

2. Pod QoS Classes

Official Docs

What It Is:

Kubernetes assigns a QoS (Quality of Service) class to pods based on their CPU and memory resource requests/limits: Guaranteed, Burstable, or BestEffort.

Guaranteed - have both CPU and Memory limits specified

Burstable - Either the CPU or Memory limit specified

Best Effort - No limit specified

You can create a YAML file of kind: LimitRange, where you can specify the limit at namespace level so that any container/pod created will adhere to that limit.

If the node runs out of resources, the eviction order is → Best Effort - Burstable - Guaranteed

If Memory → over limit → OOM Kills

If CPU → over limit → throttling

Real-World Use Case:

Avoiding Pod Evictions During Resource Pressure:
In high-load environments, a guaranteed QoS class ensures that critical system or database pods are not evicted when nodes are under memory or CPU pressure.

Cost Optimization:
You can run low-priority background jobs using BestEffort QoS so they don’t hog resources or cost you extra.

---

3. User Namespaces

Official Docs

What It Is:

User namespaces allow containers to run as root inside the container, but map to an unprivileged user on the host, improving security.

Real-World Use Case:

Securing Legacy Applications:
Some older applications require root inside the container. With user namespaces, you can run them safely without giving them root access on the host node.

Multi-tenant Clusters:
Helps isolate users in a shared cluster by preventing them from having elevated privileges on the host.

---

4. Downward API

Official Docs

What It Is:

The Downward API lets containers access metadata about their own pod, such as labels, annotations, and resource limits.

Real-World Use Case:

Dynamic Config Loading:
Applications can consume their own labels (like env=prod) and adjust behavior dynamically.

Metrics and Logging Tags:
You can tag logs with pod name, namespace, or limits using environment variables injected via the Downward API.

---

5. Pod Disruptions – Simplified

   In Kubernetes, disruptions are events that cause your pods to stop running, even temporarily. Some of these are expected and planned, and others are unexpected.

   Types of Disruptions

   1. Voluntary Disruptions – These are intentional actions like:

      • Node upgrades

      • Cluster scaling

      • Node drains for maintenance

   2. Involuntary Disruptions – These happen unexpectedly due to:

      • Node crashes

      • Hardware failures

      • OOM (Out of Memory) terminations

This guide focuses on voluntary disruptions, because those are the ones you can plan for and control.

Why Disruptions Matter

Imagine you have a web application running across 5 pods. During a maintenance event, Kubernetes could evict pods and restart them one by one. If all 5 get disrupted at once, your app becomes unavailable—even for a few seconds. This can impact users and business operations.

To prevent this, Kubernetes provides PodDisruptionBudgets (PDBs).

What is a PodDisruptionBudget (PDB)?

A PodDisruptionBudget defines the minimum availability of pods during voluntary disruptions. It tells Kubernetes:

"You can perform maintenance, but I need at least a specific number of pods running."

You define the PDB using one of the following:

• minAvailable: The minimum number of pods that must stay available.

• maxUnavailable: The maximum number of pods that can be disrupted at a time.

How to Calculate It (with Examples)

Let’s say your deployment has 10 pods.

Using minAvailable:

    minAvailable: 8

This means at least 8 pods must be running during any disruption. Only 2 pods can be disrupted at the same time.

Using maxUnavailable:

    maxUnavailable: 30%

This means at most 30% of pods (in this case, 3 pods) can be unavailable. At least 7 pods must stay available.

Both options help Kubernetes decide when it's safe to evict a pod during planned events.

What Happens During a Disruption?

When you perform maintenance like draining a node:

• Kubernetes checks the PDB.

• If evicting a pod would violate the PDB, the eviction is blocked.

• Kubernetes waits until enough pods are available before continuing.

This mechanism protects your application from downtime.

Real-World Scenario

A payment application runs with 6 pods. During scheduled updates, the company wants at least 4 pods running at all times to avoid service interruption. They apply this PDB:

    minAvailable: 4

Now, Kubernetes ensures that no more than 2 pods are disrupted at a time, maintaining service availability.

---

Conclusion

Understanding these Kubernetes pod features can elevate your deployment architecture by making it more secure, observable, and resilient. Whether you're fine-tuning performance with QoS classes or injecting metadata via the Downward API, these tools are key to successful Kubernetes operations.

---

Credits: Saiyam Pathak’s K8s BootCamp

Happy Learning!