Für jede Kubernetes-Ressource können Sie zwei Arten von Anforderungen konfigurieren: Anforderungen und Grenzwerte. Der erste beschreibt die Mindestanforderungen an die Verfügbarkeit freier Knotenressourcen, die zum Ausführen eines Containers oder Pods erforderlich sind, der zweite begrenzt streng die für den Container verfügbaren Ressourcen.
Wenn Kubernetes Pods plant, ist es sehr wichtig, dass die Container über genügend Ressourcen verfügen, um ordnungsgemäß zu funktionieren. Wenn Sie planen, eine große Anwendung auf einem Knoten mit eingeschränkten Ressourcen bereitzustellen, kann es sein, dass sie nicht ausgeführt wird, weil auf dem Knoten nicht mehr genügend Arbeitsspeicher oder CPU-Leistung vorhanden ist. In diesem Artikel schauen wir uns an, wie Sie Engpässe bei der Rechenleistung mithilfe von Ressourcenanforderungen und -limits beheben können.
Anfragen und Limits sind Mechanismen, die Kubernetes zur Verwaltung von Ressourcen wie CPU und Speicher verwendet. Anfragen stellen sicher, dass der Container die angeforderte Ressource erhält. Wenn ein Container eine Ressource anfordert, plant Kubernetes diese nur auf einem Knoten, der sie bereitstellen kann. Grenzwerte steuern, dass die vom Container angeforderten Ressourcen niemals einen bestimmten Wert überschreiten.
Ein Container kann seine Rechenleistung nur bis zu einer bestimmten Grenze steigern, danach wird sie begrenzt. Mal sehen, wie es funktioniert. Es gibt also zwei Arten von Ressourcen: Prozessor und Speicher. Der Kubernetes-Planer verwendet Daten zu diesen Ressourcen, um herauszufinden, wo Ihre Pods ausgeführt werden sollen. Eine typische Ressourcenspezifikation für einen Pod sieht so aus.
Jeder Container in einem Pod kann seine eigenen Abfragen und Grenzwerte festlegen, alles ist additiv. Prozessorressourcen werden in Millicores definiert. Wenn Ihr Container zum Betrieb zwei volle Kerne benötigt, legen Sie den Wert auf 2000 m fest. Wenn der Container nur die Leistung von 1/4 des Kerns benötigt, beträgt der Wert 250 m. Beachten Sie, dass der Start Ihres Pods überhaupt nicht geplant ist, wenn Sie einen CPU-Ressourcenwert zuweisen, der größer ist als die Anzahl der Kerne des größten Knotens. Eine ähnliche Situation tritt auf, wenn Sie einen Pod haben, der vier Kerne benötigt, und der Kubernetes-Cluster nur aus zwei virtuellen Hauptmaschinen besteht.
Sofern Ihre Anwendung nicht speziell darauf ausgelegt ist, die Vorteile mehrerer Kerne zu nutzen (man denke an Programme wie komplexe wissenschaftliche Berechnungen und Datenbankoperationen), besteht die beste Vorgehensweise darin, die CPU-Anforderungen auf 1 oder niedriger zu setzen und dann weitere Replikate auszuführen, um die Skalierbarkeit zu gewährleisten. Diese Lösung verleiht dem System mehr Flexibilität und Zuverlässigkeit.
Wenn es um CPU-Einschränkungen geht, wird es interessanter, da es sich um eine komprimierbare Ressource handelt. Wenn sich Ihre Anwendung der Leistungsgrenze des Prozessors nähert, beginnt Kubernetes, Ihren Container durch CPU-Drosselung zu verlangsamen und so die Prozessorfrequenz zu reduzieren. Dies bedeutet, dass die CPU künstlich gedrosselt wird, was zu einer potenziell schlechteren Leistung der Anwendung führt, der Prozess jedoch nicht beendet oder entfernt wird.
Speicherressourcen werden in Bytes definiert. Normalerweise wird der Wert in den Einstellungen in Mebibyte Mib gemessen, Sie können jedoch einen beliebigen Wert festlegen, von Byte bis Petabyte. Hier gilt die gleiche Situation wie bei der CPU: Wenn Sie eine Speicheranforderung stellen, die größer ist als die Speichermenge auf Ihren Knoten, wird die Ausführung dieses Pods nicht eingeplant. Im Gegensatz zu CPU-Ressourcen wird der Speicher jedoch nicht komprimiert, da es keine Möglichkeit gibt, seine Nutzung einzuschränken. Daher wird die Ausführung des Containers gestoppt, sobald der ihm zugewiesene Speicher überschritten wird.
Denken Sie daran, dass Sie keine Anfragen konfigurieren können, die die Ressourcen überschreiten, die Ihre Knoten bereitstellen können. Spezifikationen für gemeinsam genutzte Ressourcen für virtuelle GKE-Maschinen finden Sie in den Links unter diesem Video.
Im Idealfall würden die Standardeinstellungen des Containers ausreichen, um einen reibungslosen Ablauf der Arbeitsabläufe zu gewährleisten. Aber in der realen Welt ist das nicht der Fall: Menschen können leicht vergessen, die Nutzung von Ressourcen zu konfigurieren, oder Hacker legen Anforderungen und Einschränkungen fest, die über die tatsächlichen Fähigkeiten der Infrastruktur hinausgehen. Um das Auftreten solcher Szenarien zu verhindern, können Sie Ressourcenkontingente „ResourceQuota“ und „LimitRange“ konfigurieren.
Sobald ein Namespace erstellt wurde, kann dieser mithilfe von Kontingenten blockiert werden. Wenn Sie beispielsweise über die Namespaces prod und dev verfügen, besteht das Muster darin, dass es überhaupt keine Produktionskontingente und sehr strenge Entwicklungskontingente gibt. Dadurch kann Produkt im Falle eines starken Anstiegs des Datenverkehrs die gesamte verfügbare Ressource übernehmen und Entwickler vollständig blockieren.
Das Ressourcenkontingent könnte so aussehen. In diesem Beispiel gibt es 4 Abschnitte – das sind die 4 unteren Codezeilen.
Schauen wir uns jeden von ihnen an. Requests.cpu ist die maximale Anzahl kombinierter CPU-Anfragen, die von allen Containern im Namespace kommen können. In diesem Beispiel könnten Sie 50 Container mit 10-Millionen-Anfragen, fünf Container mit 100-Millionen-Anfragen oder nur einen Container mit 500-Millionen-Anfragen haben. Solange die Gesamtzahl der request.cpu eines bestimmten Namespace weniger als 500 m beträgt, ist alles in Ordnung.
Angeforderter Speicher „requests.memory“ ist die maximale Menge an kombinierten Speicheranforderungen, die alle Container im Namespace haben können. Wie im vorherigen Fall können Sie 50 2-MIB-Container, fünf 20-MIB-Container oder einen einzelnen 100-MIB-Container haben, solange die Gesamtmenge des im Namespace angeforderten Speichers weniger als 100 Mebibyte beträgt.
Limits.cpu ist die maximale kombinierte Menge an CPU-Leistung, die alle Container im Namespace nutzen können. Wir können dies als die Grenze der Prozessorleistungsanforderungen betrachten.
Limits.memory schließlich ist die maximale Menge an gemeinsam genutztem Speicher, die alle Container im Namespace nutzen können. Dies ist eine Begrenzung der gesamten Speicheranforderungen.
Daher werden Container in einem Kubernetes-Cluster standardmäßig mit unbegrenzten Rechenressourcen ausgeführt. Mit Ressourcenkontingenten können Clusteradministratoren den Ressourcenverbrauch und die Ressourcenerstellung basierend auf dem Namespace begrenzen. In einem Namespace kann ein Pod oder Container so viel CPU-Leistung und Arbeitsspeicher verbrauchen, wie durch das Namespace-Ressourcenkontingent festgelegt. Es besteht jedoch die Sorge, dass ein Pod oder Container alle verfügbaren Ressourcen monopolisieren könnte. Um diese Situation zu verhindern, wird ein Grenzwertbereich verwendet – eine Richtlinie zur Begrenzung der Zuweisung von Ressourcen (für Pods oder Container) im Namespace.
Der Grenzbereich bietet Einschränkungen, die:
- Stellen Sie eine minimale und maximale Nutzung der Rechenressourcen für jedes Modul oder jeden Container im Namespace sicher.
- Erzwingen Sie minimale und maximale Starage Request-Speicheranforderungen für jeden PersistentVolumeClaim im Namespace.
- eine Beziehung zwischen einer Anfrage und einem Limit für eine Ressource in einem Namespace erzwingen;
- Legen Sie Standardanforderungen/-limits für Rechenressourcen im Namespace fest und fügen Sie diese zur Laufzeit automatisch in Container ein.
Auf diese Weise können Sie einen Grenzbereich in Ihrem Namensraum erstellen. Im Gegensatz zu einem Kontingent, das für den gesamten Namensraum gilt, wird Limit Range für einzelne Container verwendet. Dies kann verhindern, dass Benutzer innerhalb des Namespace sehr kleine oder umgekehrt riesige Container erstellen. Der Grenzbereich könnte so aussehen.
Wie im vorherigen Fall lassen sich auch hier 4 Abschnitte unterscheiden. Schauen wir uns jeden einzelnen an.
Der Standardabschnitt legt die Standardgrenzen für den Container im Pod fest. Wenn Sie diese Werte auf den extremen Bereich festlegen, folgen alle Container, für die diese Werte nicht explizit festgelegt wurden, den Standardwerten.
Der Standardanforderungsabschnitt defaultRequest konfiguriert die Standardanforderungen für den Container im Pod. Auch hier gilt: Wenn Sie diese Werte auf den extremen Bereich festlegen, werden alle Container, die diese Optionen nicht explizit festlegen, standardmäßig auf diese Werte eingestellt.
Der Abschnitt „max“ gibt die maximalen Grenzwerte an, die für einen Container im Pod festgelegt werden können. Werte im Standardabschnitt und Containergrenzen können nicht über diesem Grenzwert liegen. Es ist wichtig zu beachten, dass der Maximalwert zum Standardwert wird, wenn der Wert auf „max“ eingestellt ist und kein Standardabschnitt vorhanden ist.
Der Abschnitt „min“ gibt die Mindestanforderungen an, die für einen Container in einem Pod festgelegt werden können. Die Werte im Standardabschnitt und in den Abfragen für den Container können jedoch nicht unter diesen Grenzwert gesetzt werden.
Auch hier ist es wichtig zu beachten, dass der Mindestwert zur Standardeingabeaufforderung wird, wenn dieser Wert festgelegt ist, der Standardwert jedoch nicht.
Diese Ressourcenanforderungen werden letztendlich vom Kubernetes-Planer zur Ausführung Ihrer Arbeitslasten verwendet. Damit Sie Ihre Container richtig konfigurieren können, ist es sehr wichtig zu verstehen, wie es funktioniert. Angenommen, Sie möchten mehrere Pods in Ihrem Cluster ausführen. Unter der Annahme, dass die Pod-Spezifikationen gültig sind, verwendet der Kubernetes-Zeitplan Round-Robin-Balancing, um einen Knoten zum Ausführen der Arbeitslast auszuwählen.
Kubernetes prüft, ob Knoten 1 über genügend Ressourcen verfügt, um Anforderungen aus den Pod-Containern zu erfüllen. Ist dies nicht der Fall, wechselt es zum nächsten Knoten. Wenn keiner der Knoten im System die Anforderungen erfüllen kann, gehen die Pods in den Status „Ausstehend“ über. Mithilfe von Google Kubernetes-Engine-Funktionen wie der automatischen Knotenskalierung kann GKE den Wartezustand automatisch erkennen und mehrere weitere zusätzliche Knoten erstellen.
Wenn Ihnen anschließend die Knotenkapazität ausgeht, wird durch die automatische Skalierung die Anzahl der Knoten reduziert, um Geld zu sparen. Aus diesem Grund plant Kubernetes Pods basierend auf Anfragen. Das Limit kann jedoch höher sein als die Anforderungen, und in einigen Fällen gehen dem Knoten möglicherweise tatsächlich die Ressourcen aus. Wir nennen diesen Zustand Overcommitment-Zustand.
Wie gesagt, wenn es um die CPU geht, wird Kubernetes damit beginnen, die Pods zu begrenzen. Jeder Pod erhält so viel, wie er angefordert hat. Wenn das Limit jedoch nicht erreicht wird, beginnt die Drosselung.
Wenn es um Speicherressourcen geht, ist Kubernetes gezwungen, Entscheidungen darüber zu treffen, welche Pods gelöscht und welche behalten werden sollen, bis Sie Systemressourcen freigeben oder das gesamte System abstürzt.
Stellen wir uns ein Szenario vor, in dem einer Maschine nicht mehr genügend Arbeitsspeicher zur Verfügung steht – wie würde Kubernetes damit umgehen?
Kubernetes sucht nach Pods, die mehr Ressourcen verbrauchen als angefordert. Wenn Ihre Container also überhaupt keine Anfragen haben, bedeutet das, dass sie standardmäßig mehr verbrauchen, als sie angefordert haben, einfach weil sie überhaupt nichts angefordert haben! Solche Container werden zu Hauptkandidaten für eine Abschaltung. Die nächsten Kandidaten sind Container, die alle ihre Anforderungen erfüllt haben, aber immer noch unter der Höchstgrenze liegen.
Wenn Kubernetes also mehrere Pods findet, die ihre Anforderungsparameter überschritten haben, werden sie nach Priorität sortiert und dann die Pods mit der niedrigsten Priorität entfernt. Wenn alle Pods die gleiche Priorität haben, beendet Kubernetes diejenigen Pods, deren Anforderungen stärker überschritten werden als andere Pods.
In sehr seltenen Fällen bricht Kubernetes möglicherweise Pods ab, die noch im Rahmen ihrer Anforderungen liegen. Dies kann passieren, wenn kritische Systemkomponenten wie der Kubelet-Agent oder Docker beginnen, mehr Ressourcen zu verbrauchen, als für sie reserviert waren.
In der Anfangsphase kleiner Unternehmen kann ein Kubernetes-Cluster also einwandfrei funktionieren, ohne dass Ressourcenanforderungen und -beschränkungen festgelegt werden müssen. Wenn Ihre Teams und Projekte jedoch größer werden, besteht die Gefahr, dass in diesem Bereich Probleme auftreten. Das Hinzufügen von Abfragen und Einschränkungen zu Ihren Modulen und Namespaces erfordert nur sehr wenig zusätzlichen Aufwand und kann viel Ärger ersparen.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com