Ten Kubernetes Design Patterns: Probes, Sidecars, Init Containers and Operators

Kubernetes gives you a lot of verbs and very little advice. The patterns below are the advice: ten recurring shapes that the platform was built to support, and what each protects you from.

Foundational: let the platform manage you

1. 1. Health probes

   Expose endpoints the platform can ask. Liveness decides when to restart a stuck container. Readiness decides whether to send traffic. Startup protects slow-starting apps from being killed too soon.

2. 2. Predictable demands

   Declare CPU and memory requests and limits, and dependencies like config and volumes. The scheduler cannot place what it cannot size.

3. 3. Automated placement

   Describe where Pods may or must run (node selectors, affinity, taints and tolerations, topology spread) and let the scheduler do the rest. Spread replicas across zones so one failure does not take them all.

containers:
  - name: api
    image: example/api:1.4.2
    resources:
      requests: { cpu: "250m", memory: "256Mi" }
      limits:   { memory: "512Mi" }
    readinessProbe:
      httpGet: { path: /ready, port: 8080 }
      periodSeconds: 5
    livenessProbe:
      httpGet: { path: /healthz, port: 8080 }
      periodSeconds: 10
      failureThreshold: 3

Structural: organising containers in a Pod

The rule of thumb: if the helper must share localhost or a volume with the app and share its lifecycle, it is a sidecar. If it is a separate service with its own scaling, it is a separate Deployment.

Behavioural: matching the workload

Higher-level: encoding operations

1. 9. Controller

   Kubernetes is a set of control loops. You declare the desired state, a controller watches actual state and acts until they match. This reconcile loop is why a crashed Pod simply comes back. Understanding it explains most “why did it do that” moments.

2. 10. Operator

   A custom controller plus a custom resource that captures a human operator’s knowledge: how to deploy a database cluster, take a backup, promote a replica, upgrade without data loss. You declare “a three-node Postgres, version 16” and the operator makes and keeps it so.

Operators are powerful and costly to write. Adopt an existing, well-maintained one for stateful software before building your own, and do not build one for a stateless service that a Deployment already handles.

Which pattern for which problem

Takeaway

The ten patterns are really one idea at four levels: tell the platform enough about your workload (probes, demands, placement), organise containers by lifecycle (init, sidecar), match the controller to the workload type (job, stateful, service), and encode repeated operations as controllers. Start at the first level and move up only when a real problem demands it.