Kurs › Folge 20

Requests und Limits: was bei zu wenig RAM passiert

Der Unterschied zwischen „reserviert" und „Obergrenze" — und der OOM-Kill live.

Das Video zu dieser Folge ist noch nicht veröffentlicht. Die Notizen stehen trotzdem schon hier.

Was du danach kannst

Requests und Limits für CPU und Speicher setzen
die Auswirkung auf das Scheduling erklären
einen OOMKilled-Pod erkennen und beheben

Worum es geht

Der Unterschied zwischen „reserviert" und „Obergrenze" — und der OOM-Kill live.

Voraussetzungen

ein laufendes Cluster aus den vorigen Folgen
Zugriff per kubectl

Zum Nachlesen

Warum Requests mehr sind als eine Reservierung

Der Scheduler benutzt sie, um einen Knoten auszusuchen — das ist der offensichtliche Teil. Der weniger offensichtliche: Sie sind die Bezugsgröße für jede prozentuale Skalierung.

Ein --cpu-percent=50 beim Autoscaler heißt nicht „50 Prozent eines Kerns", sondern „50 Prozent der angeforderten CPU". Ohne Requests gibt es keinen Bezug, und der Autoscaler meldet schlicht:

unable to get metrics for resource cpu: missing request for cpu

Mehr dazu in Folge 26.

Und ein Hinweis vorweg: kubectl top funktioniert in einem frischen Cluster noch nicht — Kubernetes sammelt von sich aus keine Messwerte. Dafür braucht es den metrics-server, ebenfalls Folge 26.

Befehle aus dieser Folge

kubectl top nodes
kubectl top pods
kubectl get pod <name> -o jsonpath='{.status.qosClass}'

Begriffe

Request: was der Scheduler reserviert — danach sucht er den Node aus
Limit: die harte Obergrenze; bei Speicher endet sie im OOM-Kill
QoS-Klasse: Guaranteed, Burstable, BestEffort — sie entscheidet, wer zuerst fliegt

Folien dieser Folge ansehen →