Kubernetes-Ressourcenrechner

Rechnen Sie Millicores und Speichersuffixe um, multiplizieren Sie über Replicas und sehen Sie die QoS-Klasse, die das kubelet vergibt. Die Suffixtabelle macht den Unterschied zwischen Mi und M greifbar — daher kommen stille Mehrkosten und überraschende OOMKills.

Beispiel-Workloads

Replicas

CPU request

CPU limit

Speicher request

Speicher limit

QoS-Klasse: BurstableCPU-Limit ist das 5.0-Fache des RequestsSpeicher-Limit ist das 2.0-Fache des Requests

	Pro Pod	× 3 Replicas
CPU request	0.1	0.3
CPU limit	0.5	1.5
Speicher request	128Mi	384Mi
Speicher limit	256Mi	768Mi

Manifest-Ausschnitt

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

# 3 replicas require
#   cpu    0.3 cores requested, 1.5 at the limit
#   memory 384Mi requested, 768Mi at the limit

Mi ist nicht M

Kubernetes akzeptiert binäre und dezimale Suffixe — und sie sind nicht gleich groß.

Suffix	Bytes	Suffix	Bytes	Unterschied
1Ki	1,024	1k	1,000	+2.4%
1Mi	1,048,576	1M	1,000,000	+4.9%
1Gi	1,073,741,824	1G	1,000,000,000	+7.4%

1G sind also 1G, 1Gi dagegen 1Gi — rund 7 % mehr.

Läuft vollständig im Browser. Diese Seite ist eine statische Datei. Was Sie eingeben, bleibt im Tab, wird nie an einen Server geschickt und ist beim Schließen verschwunden — ein echtes Token oder eine echte Konfiguration einzufügen ist also unbedenklich.

Wann man das braucht

Beim Dimensionieren eines Deployments, wenn Sie wissen müssen, wie viel Clusterkapazität die Replica-Zahl beansprucht.
Beim Herausfinden, warum ein Pod Burstable ist, obwohl er Guaranteed sein sollte.
Beim Übersetzen eines docker-compose-Speicherlimits in die Einheiten, die ein Manifest erwartet.

Durchgerechnete Beispiele

Millicores

Eingabe: 500m
Ergebnis: 0,5 Kerne

1000m ist ein Kern. Ein Request von 100m bedeutet, dass der Scheduler ein Zehntel Kern reserviert.

Das Suffix, das Geld kostet

Eingabe: 1000M gegen 1Gi
Ergebnis: 1.000.000.000 gegen 1.073.741.824 Bytes

Wer M schreibt und Mi meint, gibt dem Container rund 7 % weniger Speicher als beabsichtigt.

QoS Guaranteed

Eingabe: requests == limits
Ergebnis: Guaranteed

Nur wenn CPU- und Speicher-Requests exakt ihren Limits entsprechen. Alles andere ist Burstable und wird unter Druck früher verdrängt.

Wo es meistens schiefgeht

M schreiben, wenn Mi gemeint ist

512M sind 512.000.000 Bytes, 512Mi sind 536.870.912. Beides ist ein gültiges Manifest, es warnt also nichts — der Pod bekommt nur weniger Speicher, als die Zahl nahelegt.

Ein CPU-Limit weit über dem Request setzen

Ein Limit um ein Vielfaches über dem Request lässt den Pod ausbrechen und dann hart drosseln, sobald der Knoten ausgelastet ist. Latenzspitzen, die wie Anwendungsfehler aussehen, sind oft CFS-Throttling.

Requests ganz weglassen

Ein Pod ohne Requests ist BestEffort und wird als Erstes verdrängt, wenn ein Knoten knapp wird. Er gibt dem Scheduler auch nichts zum Planen, sodass Knoten ungleichmäßig volllaufen.

Häufige Fragen

Was ist der Unterschied zwischen Request und Limit?

Der Request ist das, was der Scheduler beim Platzieren reserviert; das Limit ist die Obergrenze, die der Kernel zur Laufzeit durchsetzt. Requests entscheiden, wo ein Pod landet, Limits, wann er gedrosselt oder per OOM beendet wird.

Wie wird die QoS-Klasse bestimmt?

Guaranteed heißt, dass jeder Container CPU- und Speicher-Requests gleich seinen Limits hat. BestEffort heißt gar keine Requests oder Limits. Alles dazwischen ist Burstable — wichtig, weil Verdrängung genau in dieser Reihenfolge passiert.

Sollte ich überhaupt ein CPU-Limit setzen?

Viele Teams setzen Speicherlimits, lassen CPU aber offen: Ein überschrittenes Speicherlimit beendet den Container, ein überschrittenes CPU-Limit drosselt nur — oft mit schlechteren Latenzfolgen, als den Pod freie Kapazität nutzen zu lassen.