Kubernetes Is Not Your Architecture

A scheduler can run almost any topology. That does not make the topology coherent, resilient, or easy to own.

Model the service first

Define ownership, contracts, data responsibility, scaling behavior, and failure expectations before choosing pods, probes, or autoscaling policy.

Make operations boring

Standardize telemetry, health semantics, safe rollout policy, resource envelopes, and incident runbooks so teams can focus on business behavior.

Align failure domains

A deployment boundary should reflect how the product fails and who responds. Splitting one transaction across many independently deployed services increases coordination and recovery cost; combining unrelated scaling profiles creates noisy-neighbor risk. Use those tradeoffs, not fashion, to draw boundaries.

Keep platform policy paved

Golden paths should package secure base images, identity, telemetry, rollout defaults, and cost labels while leaving domain logic to the product team. The platform becomes leverage when the safe choice is also the shortest path to production.

1. 1

   Model the workload

   Document dependencies, state, startup behavior, graceful shutdown, capacity, and availability targets before writing manifests.

2. 2

   Design health correctly

   Readiness should remove a pod that cannot serve; liveness should restart only an unrecoverable process. Startup probes must reflect initialization without masking permanent failure.

3. 3

   Make rollout observable

   Connect deployment events to latency, errors, saturation, and business outcomes. Use canaries or progressive delivery where failure impact justifies the operational cost.

4. 4

   Practice node and region loss

   Validate disruption budgets, topology spread, data recovery, queue backlog behavior, and capacity headroom under realistic infrastructure failure.

Production review

Use these two lists during architecture review, readiness assessment, and post-incident learning.