Für jede Kubernetes-Ressource besteht die Möglichkeit, zwei Arten von Anforderungen zu konfigurieren – Requests und Limits. Die erste beschreibt die minimalen Anforderungen an verfügbare Ressourcen eines Knotens, die zum Starten eines Containers oder Pods erforderlich sind, während die zweite strikt die Ressourcen begrenzt, die dem Container zur Verfügung stehen.
Wenn Kubernetes einen Pod plant, ist es entscheidend, dass die Container genügend Ressourcen für einen reibungslosen Betrieb haben. Wenn Sie beabsichtigen, eine große Anwendung auf einem Knoten mit begrenzten Ressourcen bereitzustellen, könnte es gut sein, dass sie aufgrund mangelndem Arbeitsspeicher oder unzureichender CPU-Leistung nicht funktioniert. In diesem Artikel werden wir erörtern, wie man Probleme mit unzureichenden Computerressourcen durch Resource Requests und Limits beheben kann.
Anfragen und Limits sind Mechanismen, die Kubernetes verwendet, um Ressourcen wie CPU und Arbeitsspeicher zu verwalten. Anfragen stellen sicher, dass ein Container die angeforderten Ressourcen garantiert erhält. Wenn ein Container Ressourcen anfordert, plant Kubernetes ihn nur auf einem Knoten, der diese bereitstellen kann. Limits kontrollieren, dass die vom Container angeforderten Ressourcen niemals einen bestimmten Wert überschreiten.
Ein Container kann seine Rechenleistung nur bis zu einem bestimmten Limit erhöhen, danach wird er eingeschränkt. Lassen Sie uns sehen, wie das funktioniert. Es gibt also zwei Ressourcenarten – CPU und Arbeitsspeicher. Der Kubernetes-Planer nutzt Daten über diese Ressourcen, um zu entscheiden, wo Ihre Pods gestartet werden sollen. Eine typische Ressourcenspezifikation für einen Pod sieht so aus.
Jeder Container in einem Pod kann eigene Ressourcenanforderungen und -beschränkungen festlegen, die additiv sind. Die CPU-Ressourcen werden in Millikernen angegeben. Wenn Ihr Container zwei volle Kerne benötigt, setzen Sie den Wert auf 2000m. Wenn der Container jedoch nur ein Viertel eines Kerns benötigt, beträgt der Wert 250m. Beachten Sie, dass Ihr Pod nicht geplant werden kann, wenn Sie einen CPU-Wert zuweisen, der höher ist als die Anzahl der Kerne des größten Knotens. Das gleiche passiert, wenn Sie einen Pod haben, der vier Kerne benötigt, und der Kubernetes-Cluster besteht nur aus zwei virtuellen Maschinen.
Es sei denn, Ihre Anwendung wurde speziell für die Nutzung mehrerer Kerne entwickelt (denken Sie an Programme wie komplexe wissenschaftliche Berechnungen und Datenbankoperationen), ist es am besten, die CPU-Anforderungen auf 1 oder weniger festzulegen und dann eine größere Anzahl von Replikaten zur Skalierung auszuführen. Diese Lösung verleiht dem System mehr Flexibilität und Zuverlässigkeit.
Wenn es um CPU-Beschränkungen geht, wird es interessanter, da sie als komprimierbare Ressource gelten. Wenn Ihre Anwendung annähernd an die CPU-Leistungslimits kommt, beginnt Kubernetes, Ihren Container durch CPU-Throttling zu drosseln – das bedeutet eine Reduzierung der Prozessorfrequenz. Das bedeutet, dass der Prozessor künstlich limitiert wird, was zu einer potenziell schlechteren Leistung Ihrer Anwendung führen kann, aber der Prozess wird nicht angehalten oder beendet.
Speicherressourcen werden in Bytes definiert. In der Regel wird der Wert in den Einstellungen in Mebibyte (Mib) angegeben, Sie können jedoch jeden Wert von Bytes bis Petabytes festlegen. Hier gilt dasselbe wie für die CPU – wenn Sie eine Anfrage für eine Menge an Speicher stellen, die das verfügbare Gedächtnis Ihrer Knoten überschreitet, wird die Ausführung dieses Pods nicht geplant. 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 er die ihm zugewiesene Speichermenge überschreitet.
Es ist wichtig zu beachten, dass Sie keine Anfragen konfigurieren können, die die Größe der Ressourcen überschreiten, die Ihre Knoten bereitstellen können. Die Spezifikationen der gemeinsamen Ressourcen für GKE-VMs finden Sie unter den Links, die unter diesem Video bereitgestellt sind.
In einer idealen Welt wären die standardmäßigen Container-Einstellungen völlig ausreichend, damit die Workflows reibungslos ablaufen. Doch die Realität sieht anders aus; Menschen können leicht vergessen, die Ressourcennutzung zu konfigurieren, oder Hacker setzen Anfragen und Einschränkungen, die die tatsächlichen Möglichkeiten der Infrastruktur überschreiten. Um solche Szenarien zu verhindern, können Sie Ressourcenkontingente (ResourceQuota) und Einschränkungsbereiche (LimitRange) festlegen.
Nach der Erstellung von Namespaces können diese mit Kontingenten gesperrt werden. Wenn Sie beispielsweise die Namespaces prod und dev haben, wird ein Muster verwendet, bei dem keine Kontingente für die Produktion vorhanden sind, während die Kontingente für die Entwicklung sehr streng sind. Dies ermöglicht es prod, im Falle eines plötzlichen Anstiegs des Verkehrs alle verfügbaren Ressourcen zu beanspruchen und dev vollständig zu blockieren.
Das Ressourcenquota könnte folgendermaßen aussehen. In diesem Beispiel gibt es 4 Abschnitte – das sind die 4 unteren Codezeilen.
Schauen wir uns jeden einzelnen an. Requests.cpu ist die maximale Anzahl kombinierter Anfragen an die Prozessorleistung, die von allen Containern im Namensraum erfolgen können. In diesem Beispiel könnten Sie 50 Container mit je 10m Anfragen haben, fünf Container mit je 100m Anfragen oder einfach einen Container mit einer Anfrage von 500m. Solange die gesamte Anzahl der requests.cpu für diesen Namensraum unter 500m bleibt, ist alles in Ordnung.
Die angeforderte Speicherkapazität requests.memory ist die maximale Summe der gespeicherten Anfragen, die alle Container im Namensraum haben können. Wie im vorherigen Fall könnten Sie 50 Container mit je 2 MiB, fünf Container mit je 20 MiB oder einen einzigen Container mit 100 MiB haben, solange die gesamte angeforderte Speicherkapazität im Namensraum unter 100 Mebibyte bleibt.
Limits.cpu ist der maximal kombinierte Wert der Prozessorleistung, die alle Container im Namensraum nutzen können. Man kann dies als die Obergrenze für CPU-Anfragen betrachten.
Limits.memory ist schließlich das maximale Gesamtvolumen an Arbeitsspeicher, das alle Container im Namensraum verwenden dürfen. Dies ist die Grenze der gesamten Speichermengenanfragen.
Standardmäßig arbeiten Container im Kubernetes-Cluster mit unbegrenzten Rechenressourcen. Mit Hilfe von Ressourcenquoten können Clusteradministratoren den Ressourcenverbrauch und die -bereitstellung basierend auf dem Namensraum einschränken. Innerhalb eines Namensraums kann ein Pod oder Container so viel CPU- und Speicherleistung verbrauchen, wie durch die Ressourcenquote des Namensraums festgelegt ist. Es besteht jedoch die Sorge, dass ein Pod oder Container alle verfügbaren Ressourcen monopolisiert. Um dies zu verhindern, wird ein Limit Range verwendet – eine Richtlinie zur Begrenzung der Ressourcenverteilung (für Pods oder Container) im Namensraum.
Ein Limit Range bietet Einschränkungen, die Folgendes ermöglichen:
- Stellen Sie die minimale und maximale Auslastung der Rechenressourcen für jedes Modul oder jeden Container im Namensraum sicher.
- Erzwingen Sie die minimale und maximale Speicherkapazitätsanforderung für jede PersistentVolumeClaim im Namensraum.
- Erzwingen Sie das Verhältnis zwischen Anforderung (Request) und Limit für Ressourcen im Namensraum.
- Legen Sie standardmäßig Anforderungen und Limits für Rechenressourcen im Namensraum fest und fügen Sie diese automatisch bei der Ausführung in die Container ein.
So können Sie einen Limitbereich in Ihrem Namensraum erstellen. Im Gegensatz zu einer Quota, die für den gesamten Namensraum gilt, wird der Limit Range für einzelne Container verwendet. Dies kann verhindern, dass Benutzer extrem kleine oder hingegen riesige Container innerhalb des Namensraums erstellen. Ein Limit Range könnte folgendermaßen aussehen.
Wie im vorherigen Fall gibt es hier 4 Bereiche. Lassen Sie uns jeden einzeln betrachten.
Im Abschnitt default werden Standardbeschränkungen für Container im Pod festgelegt. Wenn Sie diese Werte innerhalb des zulässigen Bereichs definieren, gelten für alle Container, für die diese Werte nicht ausdrücklich festgelegt wurden, die Standardwerte.
Im Abschnitt defaultRequest werden die Standardanfragen für Container im Pod konfiguriert. Auch hier gilt: Wenn Sie diese Werte innerhalb des zulässigen Bereichs festlegen, verwenden alle Container, für die diese Parameter nicht explizit definiert sind, die Standardwerte.
Im Abschnitt max sind die maximalen Grenzen aufgeführt, die für Container im Pod festgelegt werden können. Die Werte im Abschnitt default und die Begrenzungen für Container dürfen nicht über diesem Limit liegen. Es ist wichtig zu beachten, dass, wenn ein max-Wert festgelegt wird und der Abschnitt default fehlt, der max-Wert zum Standardwert wird.
Im Abschnitt min sind die minimalen Anfragen aufgeführt, die für Container im Pod festgelegt werden können. Die Werte im Abschnitt default und die Anfragen für Container dürfen dabei nicht unter diesem Limit liegen.
Es ist wichtig zu beachten, dass, wenn dieser Wert gesetzt ist und der Standardwert auf 'nein' steht, der minimale Wert zur Standardanforderung wird.
Diese Ressourcenanforderungen werden vom Kubernetes-Planer verwendet, um Ihre Workloads auszuführen. Um Ihre Container richtig zu konfigurieren, ist es entscheidend zu verstehen, wie dies funktioniert. Angenommen, Sie möchten mehrere Pods in Ihrem Cluster starten. Wenn die Pod-Spezifikationen gültig sind, wird Kubernetes eine Round-Robin-Balancierung verwenden, um einen Knoten zur Ausführung der Arbeitslast auszuwählen.
Kubernetes prüft, ob Node 1 über genügend Ressourcen verfügt, um die Containeranforderungen des Pods zu erfüllen, und wenn nicht, wechselt es zum nächsten Knoten. Sollte kein Knoten im System die Anforderungen erfüllen können, wechseln die Pods in den Zustand 'Pending'. Mit Funktionen wie der automatischen Skalierung von Knoten im Google Kubernetes Engine kann GKE den Pending-Zustand automatisch erkennen und zusätzliche Knoten erstellen.
Sollte später ein Überangebot an Knotenkapazität entstehen, wird die Auto-Scaling-Funktion deren Anzahl verringern, um Kosten zu sparen. Deshalb plant Kubernetes Pods basierend auf den Anfragen. Es kann jedoch vorkommen, dass das Limit höher ist als die Anfragen, sodass ein Knoten unter Umständen tatsächlich Ressourcen erschöpfen kann. Wir nennen diesen Zustand Overcommitment-Zustand.
Wie bereits erwähnt, wird Kubernetes, wenn es um die CPU geht, beginnen, Pods zu drosseln. Jeder Pod erhält die Menge, die er angefragt hat, aber wenn er das Limit nicht erreicht, wird eine Drosselung wirksam.
Hinsichtlich der Ressourcenverwendung von Speicher muss Kubernetes Entscheidungen darüber treffen, welche Pods entfernt und welche beibehalten werden, bis Sie systemische Ressourcen freigeben, sonst könnte das gesamte System zusammenbrechen.
Stellen wir uns ein Szenario vor, in dem Sie eine Maschine haben, die ihr Speicherkontingent erschöpft hat – wie wird Kubernetes in diesem Fall reagieren?
Kubernetes sucht nach Pods, die mehr Ressourcen verbrauchen, als angefordert. Wenn Ihre Container überhaupt keine Requests haben, bedeutet das, dass sie standardmäßig mehr verwenden, als sie angefordert haben, einfach weil sie überhaupt nichts angefordert haben! Solche Container sind die Hauptkandidaten für eine Abschaltung. Die nächsten Kandidaten sind Container, die alle ihre Anforderungen erfüllt haben, aber noch unter dem maximalen Limit liegen.
Wenn Kubernetes mehrere Pods findet, die ihre Anforderungsparameter überschritten haben, sortiert es sie nach Priorität und löscht die Module mit der niedrigsten Priorität. Wenn alle Module die gleiche Priorität haben, stoppt Kubernetes die Pods, die ihre Anforderungen mehr überschreiten als die anderen Pods.
In sehr seltenen Fällen kann Kubernetes auch Pods beenden, die sich innerhalb ihrer Anforderungen befinden. Dies kann geschehen, wenn kritische Systemkomponenten wie der Kubelet-Agent oder Docker mehr Ressourcen verbrauchen, als für sie reserviert wurden.
In den Anfangsphasen von kleinen Unternehmen kann ein Kubernetes-Cluster hervorragend ohne die Festlegung von Ressourcenanforderungen und -grenzen funktionieren. Doch wenn Ihre Teams und Projekte wachsen, könnte es sein, dass Sie in diesem Bereich auf Probleme stoßen. Das Hinzufügen von Anforderungen und Grenzen zu Ihren Modulen und Namensräumen erfordert nur geringfügige zusätzliche Anstrengungen und kann Ihnen viele Kopfschmerzen ersparen.
Ein wenig Werbung 🙂
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
