Kubernetes provides the building blocks; patterns provide the architecture. This post covers the deployment strategies, structural patterns, and tenancy models that separate production-grade clusters from demo setups.
Deployment Strategy Comparison
| Strategy | Zero downtime | Rollback speed | Resource cost | Risk | Complexity | Best for |
|---|
| Rolling update | Yes | Slow (re-roll) | 1x + surge | Low per-pod | Low | Stateless services, default choice |
| Blue-green | Yes | Instant (switch) | 2x | All-or-nothing | Medium | Critical services needing instant rollback |
| Canary | Yes | Fast (route shift) | 1x + canary % | Controlled blast radius | High | User-facing services, gradual rollout |
| Recreate | No (downtime) | Slow | 1x | Full outage during deploy | Low | Stateful services, DB migrations |
| A/B testing | Yes | Fast | 1x + variant % | Segment-specific | High | Feature experimentation |
| Shadow / dark launch | Yes | N/A (no user impact) | 2x | None (mirrored traffic) | Very high | Performance validation |
Sidecar / Ambassador / Adapter Patterns
┌─────────────────────────────────────────────────┐
│ POD │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ App │ │ Sidecar │ │ Sidecar │ │
│ │ Container │ │ (proxy) │ │ (logging)│ │
│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │
│ │ │ │ │
│ └──────── shared network ─────┘ │
│ shared volumes │
└─────────────────────────────────────────────────┘
| Pattern | Role | Example | When to use |
|---|
| Sidecar | Extend app with cross-cutting concerns | Envoy proxy, log forwarder, cert rotation | Service mesh, observability |
| Ambassador | Proxy outbound connections from app | OAuth token injection, rate limiter | Simplify app-to-external communication |
| Adapter | Normalize app output for external systems | Prometheus exporter, log format converter | Heterogeneous monitoring |
| Init container | Run setup before app starts | DB migration, config fetch, secret injection | One-time initialization |
Resource Management Taxonomy
Resource Management
├── Requests & Limits
│ ├── CPU requests (scheduling guarantee)
│ ├── CPU limits (throttling ceiling)
│ ├── Memory requests (scheduling guarantee)
│ └── Memory limits (OOM-kill boundary)
├── Quality of Service (QoS)
│ ├── Guaranteed (requests = limits)
│ ├── Burstable (requests < limits)
│ └── BestEffort (no requests/limits)
├── Cluster-Level Controls
│ ├── ResourceQuotas (per-namespace caps)
│ ├── LimitRanges (per-pod defaults & bounds)
│ └── PriorityClasses (eviction ordering)
└── Autoscaling
├── HPA — Horizontal Pod Autoscaler (replica count)
├── VPA — Vertical Pod Autoscaler (resource sizing)
├── KEDA — Event-driven scaling (queue depth, custom metrics)
└── Cluster Autoscaler / Karpenter (node provisioning)
Namespace Strategy Matrix
| Strategy | Structure | Pros | Cons | Best for |
|---|
| Per environment | dev / staging / prod | Simple, clear separation | Poor isolation within env | Small teams, <10 services |
| Per team | team-a / team-b / platform | Team autonomy, RBAC mapping | Cross-team service discovery harder | Medium orgs, domain teams |
| Per service | api-gateway / billing / ml-serving | Maximum isolation | Namespace sprawl, overhead | Strict security requirements |
| Hybrid | prod-team-a / staging-team-a | Best of both worlds | Naming conventions critical | Large organizations |
| Per tenant | tenant-abc / tenant-xyz | Strong data isolation | Cluster resource pressure | Multi-tenant SaaS |
Multi-Tenancy Comparison
| Dimension | Namespace isolation | Virtual clusters (vCluster) | Separate clusters |
|---|
| Isolation level | Soft (RBAC + NetworkPolicy) | Medium (virtual control plane) | Hard (physical separation) |
| Cost efficiency | High (shared infra) | Medium | Low (duplicated infra) |
| Blast radius | Namespace | Virtual cluster | Full cluster |
| CRD isolation | None (shared) | Per virtual cluster | Full |
| Complexity | Low | Medium | High |
| Compliance | Basic | Good | Best (air-gapped) |
| Best for | Internal teams, dev/staging | ISVs, platform engineering | Regulated industries, PCI/HIPAA |
Pod Disruption Budget (PDB) Guidelines
| Workload type | Recommended PDB | Rationale |
|---|
| Stateless API (3+ replicas) | minAvailable: 2 or maxUnavailable: 1 | Maintain capacity during drain |
| Stateful (DB, cache) | minAvailable: N-1 (quorum) | Preserve quorum for consensus |
| Singleton (1 replica) | maxUnavailable: 0 | Prevent eviction, accept drain block |
| Batch / CronJob | No PDB | Restart is acceptable |
| DaemonSet | maxUnavailable: 1 | Rolling node drain |
Resources
:::