Runtime Playbooks
Kubernetes Playbook
Use Kubernetes when the organization needs shared orchestration, policy, networking, and platform primitives enough to justify cluster operations. Do not use it as the default runtime for every service.
Good fit
Kubernetes is a good fit when teams need:
- Many services with consistent deployment and networking patterns.
- Admission policy, workload identity, and shared runtime controls.
- GitOps reconciliation for desired state.
- Custom controllers or platform abstractions.
- Portability across environments or providers.
Baseline architecture
Required defaults
Every cluster platform should define:
- Namespace and ownership model.
- Workload identity and cloud permission pattern.
- Ingress, DNS, and certificate flow.
- Resource requests, autoscaling, probes, and disruption budgets.
- Secrets delivery and rotation approach.
- GitOps or deployment workflow.
- Admission policy and exception process.
- Cluster upgrade and node lifecycle process.
Application checklist
Every Kubernetes workload should have:
- Deployment or rollout strategy.
- Health probes that reflect real readiness.
- Requests and limits appropriate to workload behavior.
- Service account scoped to least privilege.
- Config and secrets separated from images.
- Dashboard, alerts, logs, and traces.
- Rollback or disablement path.
Watchouts
- Per-team bespoke Helm charts create long-term platform drag.
- Missing requests and limits cause noisy-neighbor incidents.
- Cluster admin access becomes a hidden production backdoor.
- GitOps without ownership only moves manual drift into Git.
- Service mesh should follow a real traffic-management need, not vibes.