, 14 tweets, 6 min read
Kubernetes Borg/Omega history topic 11: PodDisruptionBudget. Google constantly performs software and hardware maintenance in its datacenters: firmware updates, kernel and image updates, disk repairs, switch updates, battery tests, etc. etc. More and more kinds over time.
Even though Borg tasks are designed to be resilient, this could get pretty disruptive. Rate-limiting maintenance tasks independently isn't efficient if you have dozens of them, and it's not always feasible to perform all types of maintenance at the same time.
Even if rate-limiting machine disruptions, it's also possible for the same task to get disrupted over and over again, like a can being kicked down the road. Hence, the Safe Removal Service (aka SRSly -- pronounced seriously) was developed by SRE. (SRE builds lots of automation.)
SRSly kept track of how often tasks of the same Borg Job were disrupted (aka evicted). Maintenance automation queried SRSly regarding all tasks scheduled on a machine before taking it out of service. This enabled Borg to provide a SLO on task disruption.
Borgmaster, however, did not know about SRSly. Instead, all critical/production workloads were changed to run with the same priority so that they wouldn't preempt each other. Doing that for every Borg Job in the company was extremely painful -- more on priority/preemption later
For Omega, we developed a model that could be applied both during task preemption to run a higher-priority task and eviction for maintenance -- disruption counters. There was a time dimension that ended up not being effective due to constant changes, so we dropped it in K8s
I think I first mentioned this in Kubernetes in my big scheduling braindump comment: github.com/kubernetes/kub…. It came up again when I proposed maxUnavailable to moderate concurrent disruptions caused by updates during the design of Deployment:
github.com/kubernetes/kub…
That discussion was forked into github.com/kubernetes/kub…. Around that time, Matt Liggett (github.com/kubernetes/kub…) joined the GKE team from Borg SRE (woo hoo!). One of the first things Matt worked on was improving node drains: github.com/kubernetes/kub…
Together with @davidopp and @erictune4, we folded disruption budgets into the rescheduling design proposal: github.com/kubernetes/com…. (Rescheduling deserves its own thread -- I'll do that one next.) Implementation began in github.com/kubernetes/kub… and github.com/kubernetes/kub…
PodDisruptionBudget is now documented: kubernetes.io/docs/concepts/… and kubernetes.io/docs/tasks/run…. Try it out and give us feedback on how well it works for you. We're looking to advance it from beta to GA: github.com/kubernetes/enh…
You can safely drain a node with kubetctl drain: kubernetes.io/docs/tasks/adm…. Node upgrades and the cluster autoscaler in Google Kubernetes Engine (GKE) also respect PodDisruptionBudget. The latter is documented here: cloud.google.com/kubernetes-eng…
Node upgrade behavior is documented here: cloud.google.com/kubernetes-eng…
And more about the Google SRE philosophy behind automation can be found in the SRE book: landing.google.com/sre/sre-book/c…
And the Safe Removal Service was also mentioned in Google's "VM Live Migration at Scale" paper in VEE 2018: dl.acm.org/citation.cfm?i…
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Brian Grant

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!