The Long, Winding and Bumpy Road to CronJob’s GA
summary
CronJob reaches GA in Kubernetes 1.21 after replacing the old poll-based controller with an informer + workqueue design that uses a delaying interface to requeue jobs at the next schedule, live GETs against the API to avoid stale-cache duplicates, and a faster computeNextSchedule optimization. Stress tests on a single-node VM push beyond 6120 cronjobs: the old controller shows multi-minute linear lag and missed runs, the new controller shows no visible delay and exposes a histogram metric for schedule skew.
AI-written summary · about
chapters (19)
- 0:00Intro
- 0:13In the beginning...
- 0:39Distributed CRON Distributed CRON jobs in ks #2156
- 2:15ScheduledJob
- 4:14Slowing down...
- 5:01Brace for impact!
- 5:35Two controllers? Writing Controllers
- 6:45Modern Controllers
- 8:34Informers and Event Handlers.
- 10:07Workers
- 11:31Scheduling
- 13:21Sync actions
- 16:15Challenges: Handling Update
- 19:45Challenges: Lagging Caches
- 22:50Challenges: Dirty Buffers
- 24:16What do we get?
- 25:30Scale Test Setup
- 27:15Performance Comparison
- 29:24Newer additions
related talks
23mKubernetes CronJobs - Does Anyone Actually Use This [in Production]?
16mKubernetes SIG Apps Updates
27mKubernetes SIG Apps Updates
24mWriting kube controllers for everyone
26mKubernetes SIG Apps Updates
30mWG-Batch Updates: What’s New and What Is Next?
29mLightning Talk: Evolving the Job API to Become Defacto Standard for Batch Worklo...
37mIntroduction to the Kubernetes WG Batch