Anfragen und Grenzen: die Einstellungen, die jeder falsch macht

Wenn ich die eine Kubernetes-Einstellung wählen müsste, die die meisten Verwirrungen verursacht, wären es Ressourcenanfragen und Grenzen. Sie sehen einfach aus: ein paar Zahlen in einer YAML-Datei. Aber sie entscheiden, wohin deine Kapsel fährt, wie schnell sie ist, ob sie getötet wird und wie viel dein Cluster kostet.

Lasst uns durchgehen, was sie eigentlich tun.

Was Anfragen und Grenzen bedeuten

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 512Mi

Anträge Die Kapsel ist garantiert. Der Planer entscheidet, welcher Knoten Platz hat. Ein Knoten mit 4 CPUs kann Kapseln, deren CPU-Anfragen zusammen etwa 4 sind, ungeachtet dessen, wie viel sie tatsächlich verwenden, passen.

Grenzen sind die maximale Nutzung der Kapsel.

Die wichtigste Erkenntnis: CPU und Speicher verhalten sich ganz anders, wenn man die Grenze erreicht.

Was passiert eigentlich, wenn man ein Limit erreicht

Die CPU ist komprimierbar. Wenn ein Container versucht, mehr CPU als sein Limit zu verwenden, erhält er Schnüren- Ich weiß . Er stürzt nicht ab, er verlangsamt sich nur. Der Kernel lässt ihn nur für einen bestimmten Teil der Zeit laufen. Das zeigt sich als mysteriöse Latenzspitzen, oft ohne hohe durchschnittliche CPU-Nutzung.

Das Gedächtnis ist nicht komprimierbar. Wenn ein Container mehr Speicher verbraucht als es benötigt, tötet der Kernel ihn. Das ist der berühmte - Er wurde getötet. Status. Die Kapsel startet wieder, und wenn es so weitergeht, sehen Sie CrashLoopBackOff.

kubectl describe pod shop-api-7d9f
# Last State: Terminated
#   Reason:   OOMKilled
#   Exit Code: 137

Es gibt auch die Räumung: Wenn ein Knotenall insgesamt aus dem Speicher läuft, räumt das Kubelet die Kapseln aus, beginnend mit denen, die am meisten über ihre Anforderungen hinaus verwenden.

Qualitätssicherungsklassen, einfach

Kubernetes ordnet jeden Pod in eine von drei Qualitätsklassen ein, basierend auf seinen Anforderungen und Grenzen:

• Garantiert: verlangt gleiche Grenzen für CPU und Speicher in jedem Container. Als Letzter vertrieben.
• mit einem Gehalt an Zellstoff von mehr als 0,01 GHT: die Anträge werden festgelegt, jedoch unterhalb der Grenzwerte (oder nur einige). Die häufigste Klasse.
• BestEffort: keine Anfragen oder Grenzen. Erstmals entlassen, wenn der Knoten unter Druck steht.

Für wichtige Dienstleistungen vermeiden Sie BestEffort. Für kritische Arbeitslasten gilt mindestens für den Speicher garantiert.

Anfragen entscheiden, wo Ihre Kapsel wohnt. Grenzen bestimmen, wie es stirbt.

Die CPU-Debatte beschränkt

Hier streiten Ingenieure. Sollten Sie überhaupt CPU-Limits setzen?

Die Klage gegen CPU-Limits: Drosseln schadet der Latenzzeit, manchmal sogar, wenn der Knoten viele leere CPUs hat. Ohne Grenzen kann eine Kapsel die CPU verwenden, wenn sie verfügbar ist, und Anfragen garantieren immer noch jedem seinen fairen Anteil. Viele erfahrene Teams setzen CPU-Anfragen, aber keine CPU-Limits.

Die CPU-Grenzwerte: Vorhersehbarkeit. In Clustern mit mehreren Mietern oder wenn man verhindern muss, dass eine laute Arbeitsbelastung alles übernimmt, geben Grenzen harte Grenzen. Einige Laufzeiten und Lizenzmodelle hängen auch davon ab.

Mein Standard: Setzen Sie immer CPU-Anfragen, Setzen Sie Speicheranfragen und Speicherlimits, und setzen Sie nur CPU-Limits, wenn es einen bestimmten Grund gibt. Für den Speicher setze ich das Limit normalerweise gleich der Anfrage oder nahe daran, damit die Kapseln nicht überraschend ausgeschoben werden.

Die richtigen Zahlen finden

Raten ist wie die meisten Teams beginnen, und es ist normalerweise falsch in beiden Richtungen: einige Kapseln verhungern, andere reservieren Ressourcen, die sie nie verwenden (und dafür bezahlen Sie).

Bessere Ansätze:

• Schauen Sie sich den tatsächlichen Gebrauch an. in Prometheus oder Ihrem Überwachungswerkzeug über mindestens eine Woche. Ein allgemeiner Ausgangspunkt: Anfragen in der Nähe der typischen Nutzung (z. B. der 90. Perzentil), Speichergrenze mit etwas Kopfraum über dem Gipfel.
• VPA im Empfehlungsmodus Berechnet Vorschläge für Sie.
• Goldlöckchen (von Fairwinds) läuft VPA im Empfehlungsmodus und zeigt die Ergebnisse pro Namespace in einem Dashboard an.
• Überprüfen Sie die Drosselung mit der container_cpu_cfs_throttled_periods_total Metrische. Hohe Drosselung bei niedrigem Durchschnittsverbrauch ist ein Zeichen dafür, dass die CPU-Grenze zu eng ist.
• Sprachenlaufzeiten sind wichtig. Java, Node.js und Go haben jeweils ihre eigene Beziehung zum Container-Speicher und zu CPU-Limits. Stellen Sie sicher, dass Ihre Laufzeit ihre Grenzen kennt (moderne JVMs erkennen beispielsweise automatisch Containergrenzen).

Schutzgeländer für den gesamten Cluster

Um zu verhindern , dass sich die Kapseln ohne Einstellungen einbrechen:

• Grenzbereich setzt Standardanfragen und Grenzen pro Namensraum.
• Quoten für Ressourcen begrenzt die Gesamtzahl der Anfragen, die ein Namespaces beantragen kann.
• Politikinstrumente Wie Kyverno kann er Anfragen auf jeder Kapsel verlangen.

Was solltet ihr heute tun?

Überprüfen Sie, welche Ihrer Arbeitslasten überhaupt keine Anfragen haben. Finde die erst mal in Ordnung. Dann schauen Sie sich OOMKills und Drosselungsmetriken an und passen Sie auf der Grundlage echter Daten anstatt Vermutungen an.

Meine Meinung: Setze Anfragen ehrlich, behandle Speicherlimits mit Respekt und denke zweimal darüber nach, bevor du deine eigene CPU einschränkst.

Desly