Ein Container läuft nicht einfach irgendwie – er bekommt Ressourcen zugesichert und begrenzt. Wer beides verwechselt, wundert sich später über abrupte Neustarts.
In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.
Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.
Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.
Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.
Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.
Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.
📌 Request · Limit · OOM-Kill
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting
In Kubernetes wird beim Start jedes Containers festgelegt, wie viel CPU und Speicher ihm garantiert und wie viel er höchstens verbrauchen darf. Das betrifft jede Web-Anwendung, jeden Job, jeden Dienst im Cluster – einem Cluster, einer Gruppe von Rechnern, die Container gemeinsam betreiben.
Zuerst definiert man die Requests: die Mengen an CPU und Speicher, die der Scheduler, die Komponente, die Container auf Knoten verteilt, fest einplant und garantiert. CPU misst man in Millicores: 1000m sind ein voller Kern, 500m die Hälfte. Speicher steht in Bytes, etwa mit dem Suffix Mi für Mebibyte.
Dann prüft der Scheduler anhand der Requests, ob ein Knoten noch Platz hat. Er kennt die Limits bei der Platzierung nicht. Fehlen Requests, bucht er Knoten über, weil er den Bedarf nicht kennt – Engpässe treten dann erst zur Laufzeit auf.
Danach läuft der Container und darf über seinen Request hinaus wachsen, solange Ressourcen frei sind. Ein Beispiel: Request 100m CPU und 128Mi Speicher, Limit 500m und 256Mi. Kurzzeitig darf er also auf das Fünffache der zugesicherten CPU wachsen.
Zuletzt greifen die Limits zur Laufzeit. Überschreitet der Container sein Speicher-Limit, beendet ihn der Kernel sofort per OOM-Kill und Kubernetes startet ihn neu. Am CPU-Limit wird er nicht beendet, sondern gedrosselt: Er läuft langsamer, arbeitet aber weiter. Pods ganz ohne Werte erhalten die Klasse BestEffort und werden bei Speicherknappheit zuerst verdrängt.
Requests sind das Versprechen an den Scheduler, Limits die Grenze im Betrieb. Wer Limits als Requests deutet, plant Knoten falsch voll; wer beides weglässt, überlässt die Verteilung dem Zufall.
📌 Request · Limit · OOM-Kill
📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #CloudHosting
2 Tage vor
