Burstable ist die mittlere QoS-Klasse in Kubernetes. Ein Pod erhält sie, wenn mindestens ein Container requests oder limits setzt, aber die strenge Guaranteed-Bedingung (identische Werte für alle Ressourcen in allen Containern) nicht erfüllt ist.
Typische Konfigurationen
Die Klasse Burstable entsteht zum Beispiel bei:
- nur
requestsohnelimits, requests < limits(bewusster Spielraum für Lastspitzen),- nur
limitsohnerequests, - gemischten Containern, bei denen nicht alle die Guaranteed-Bedingung erfüllen.
Was die Klasse bewirkt
requests reservieren eine Mindestmenge: Beim CPU sind sie hart garantiert, beim Memory im Normalbetrieb. limits erlauben dem Pod, bei freien Node-Ressourcen darüber hinaus zu arbeiten (Bursting) – bis zur cgroup-Grenze, die der Kernel erzwingt (siehe Kubernetes cgroup).
Eviction und OOM-Reihenfolge
Bei Node-Pressure-Eviction werden BestEffort-Pods zuerst beendet, dann Burstable- und zuletzt Guaranteed-Pods (siehe Eviction-Policy). Der oom_score_adj wird dynamisch berechnet: min(max(2, 1000 − (1000 × Memory-Request) / Node-Speicher), 999). Je mehr Memory ein Pod anfordert, desto niedriger sein Score – und desto später beendet ihn der OOM-Killer. Der Vertical Pod Autoscaler kann die requests nachjustieren und so den Abstand zum Limit verkleinern. Unter systemd liegt der Pod in der cgroup kubepods-burstable.slice.
Einsatz
Burstable ist die Standardklasse für die meisten Web- und App-Workloads: Sie verbindet eine Grundgarantie mit der Chance auf Lastspitzen. Wer requests weglässt, sollte bedenken, dass der Scheduler dann weniger planen kann – sinnvolle Angaben helfen auch ResourceQuota und LimitRange bei der Durchsetzung.
Verwandte Grundlagen: Pod-QoS-Klassen, PodSpec. Weitere QoS-Klassen: Guaranteed, BestEffort.