Scaling Spinnaker for Kubernetes deployments
summary
Spinnaker deployments stall because Force Cache Refresh ~12 minutes actually waits for a full cache cycle: Orca posts an on‑demand refresh to cloud‑driver, cloud‑driver runs kubectl get (returns huge JSON for secrets/configmaps), saves to the on‑demand region, and the next cache agent run (default every 30s) merges it. Use cloud‑driver /cache/introspection to see last execution duration and kubectl time, increase cloud‑driver CPU/memory or cache threads, prefer SQL over Redis, or enable live manifest calls (bypass cache) with caveats; 1.23 removes the slow flow.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:16Time to scale?
- 1:23Force Cache Refresh - Request
- 3:55Force Cache Refresh - Process
- 6:27Troubleshooting
- 10:44Caching agents
- 12:19What to do?
- 17:38Problem of liveManifest Calls
- 18:50New in Spinnaker 1.23
related talks
45mEvolution of Spinnaker Internals & Operations
28mSalesforce Status Report – What Are We Up To With Spinnaker?
46mSpinnaker at Scale for Snap's Multi Cloud Service Mesh
36mSpinnaker - Land of a 1000 Builds
48mScaling a Migration to CD at Airbnb
33mPanel Discussion: Spinnaker Success - CD as a Service using Spinnaker
17mIntroduction to Spinnaker on Kubernetes
01h 04mOpening Keynote [Full]