Promotion Failed: How (Not) To Stage Your (Kubernetes) Platform - Nicolai Ort
summary
Kubernetes-as-a-Service platforms must treat the platform as Kubernetes plus CSI CNI ingress tooling and the ordering interface, and stage the full dependency stack not just namespaces. Use a single versioned state (YAML/TF) promoted by git tags or pipelines (GitHub Actions, Argo CD, Flux) rather than manual copy, keep stages to roughly dev plus two, enforce a delay of at least 4 days with a fast‑track button for CVEs, run daily smoke tests and create backups immediately before any promotion.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 1:24Kubernetes platform
- 3:10Stages in platform engineering
- 5:17Right number of stages
- 6:17State management
- 7:42Organizing state files
- 9:51State file organization
- 11:16Promotion workflow theory
- 11:58Risks of manual editing
- 13:50Automating promotions
- 14:33Delay-based promotion
- 15:37Testing platform changes
- 16:23End-to-end testing
- 18:13Tests versus manual oversight
- 19:16Staging challenges
- 20:39Fast-tracking critical fixes
- 21:22Tested backups importance
- 21:43Communicating changes
- 22:45Change tracking dashboard
- 23:06Key takeaways
related talks
06mSponsored Keynote: From Clusters to Cloud: Taking GitOps Promotion Further with Kargo
37mBuilding a Managed Platform While Maintaining a Good Developer Experience
05mApplication promotion in GitOps
07mNavigating Multi-stage Deployment Pipelines via the GitOps Approach
27mA Million Ways To Promote Changes Between Environments
39mPlatform Engineering as a (Community) Service
24mThe Cluster Is Not the Platform: Operating Industrial Edge Kubernetes as a Fleet
32mHow Might You Platform: Avoiding Traps Before It's Too Late