Implementing the Schedulers: A Look at the Internals of Diego...
summary
Side‑by‑side implementation details: Cloud Foundry replaces DEAs with auctioneer/BBS (Diego) or kube‑scheduler/API server (Eirini) while runtime duties map to rep/garden versus kubelet/CRI. Eirini packages CF LinuxFS3 into container images via the Bits service and registry (base ~900MB) and supports standard kubernetes tooling. Diego demonstrates much higher proven scale (about 1,000 nodes, ~250,000 app instances) versus Eirini’s tested ~30–40 nodes, ~2,500 app instances. Key failures with Eirini are staging/registry bottlenecks and rolling upgrade complexity; functionality exists but scalability work remains.
AI-written summary · about
chapters (9)
- 0:00Intro
- 1:07CF Overview
- 3:25A Brief History of CF Schedulers
- 4:55Diego Architecture
- 12:30Scheduler Comparison - Pluggability
- 15:18Pushing an App with Diego
- 20:03Diego RootFS Update Flow
- 22:44Eirini RootFS Update Flow
- 24:31Summary
related talks
28mDiego vs Eirini: How to Choose the Best Fitting Container...
37mCloud Foundry Diego Overview
36mWe Come From a Land of Runtimes
30mDiego Runtime Overview
26mMicroservices With Cloud Foundry and Kubernetes
31mNew Cloud Foundry Architectures and Features and their Performance Impact
28mCloud Foundry 101 for Kubernetes Users
31mScaling a Distributed Container Management System: Diego Performance