Kubernetes Patterns - Part 2

Init Container, Sidecar, Ambassador, Adapter, Controller, Operator

Let’s look into a few more crucial patterns every Kubernetes practitioner should know in this Part 2.

1. Singleton Application

Some applications require that only one instance is active at a time, with others remaining in a passive or standby state.

Use cases: Leader-election apps, primary-replica DBs

Implementation approach:

Use Kubernetes Lease API (coordination.k8s.io/v1) for leader election

Store lock state in etcd/Zookeeper to prevent split-brain scenarios

Define PodAntiAffinity to distribute instances across nodes

2. Batch Job

Batch workloads are non continuous tasks that run to completion. Kubernetes provides Jobs and CronJobs to manage these workloads by ensuring execution, retries, and cleanup.

Use cases: Data processing, ETL, backups

Implementation approach:

Use Job (batch/v1) for one-time execution

Use CronJob (batch/v1) for scheduled tasks

Set backoffLimit to control retry attempts

Use ttlSecondsAfterFinished for automatic cleanup

3. Service Discovery

Microservices running in Kubernetes need a reliable way to communicate with each other. Kubernetes Service objects provide built-in discovery mechanisms for internal and external traffic routing.

Use cases: Microservices, backend APIs

Implementation approach:

Use ClusterIP Service for internal traffic (cluster.local DNS resolution)

Use Headless Service (clusterIP: None) for pod-to-pod direct communication

Deploy an Ingress Controller (NGINX, Traefik) for external routing

4. Stateful Service

Unlike stateless applications, stateful workloads require persistent storage and stable network identities. Kubernetes StatefulSet ensures ordered deployment, unique pod names, and persistent storage attachments.

Use cases: Databases (PostgreSQL, MongoDB), Kafka

Implementation approach:

Deploy StatefulSets (apps/v1) for ordered scaling and stable pod names

Use PersistentVolumes (PVs) with volumeClaimTemplates for per-pod storage

Define Headless Services for direct pod addressing

5. Self Healing Systems

Kubernetes continuously monitors the state of pods and ensures they match the declared state by replacing failed instances automatically.

Use cases: High-availability applications, Multi replica workloads

Implementation approach:

Define Liveness Probes to restart stuck containers

Use Readiness Probes to ensure traffic is routed only to healthy pods

Leverage ReplicaSets and Deployments for automated recovery

Configure PodDisruptionBudgets (PDBs) to limit voluntary disruptions

6. Health Probe

Determines pod health and take corrective actions such as restarting or removing it from service endpoints.

Use cases: Prevent routing to failing pods

Implementation approach:

Use Liveness Probe (/health) to restart unresponsive containers

Use Readiness Probe (/ready) to control traffic exposure

Use Startup Probe for applications with long boot times

These patterns provide structured approaches to solving common challenges in distributed systems.