Get best of the week

Best Practices von Kubernetes. Abfragen und Ressourcenlimits festlegen

Best Practices von Kubernetes. Erstellen kleiner Container
Best Practices für Kubernetes. Kubernetes-Organisation mit dem Kubernetes
Best Practices-Namespace. Überprüfen der Lebensfähigkeit von Kubernetes mithilfe der Bereitschafts- und Lebendigkeitstests

Für jede Kubernetes-Ressource können Sie zwei Arten von Anforderungen konfigurieren: Anforderungen und Grenzwerte. Der erste beschreibt die Mindestanforderungen für die Verfügbarkeit von freien Knotenressourcen, die zum Ausführen eines Containers oder Herds erforderlich sind, der zweite begrenzt streng die dem Container zur Verfügung stehenden Ressourcen.

Wenn Kubernetes einen Pod plant, ist es sehr wichtig, dass die Container über genügend Ressourcen für den normalen Betrieb verfügen. Wenn Sie vorhaben, eine große Anwendung auf einem Knoten mit begrenzten Ressourcen bereitzustellen, funktioniert sie möglicherweise nicht, da dem Knoten der Arbeitsspeicher ausgeht oder die Prozessorleistung fehlt. In diesem Artikel wird untersucht, wie Sie die Probleme mangelnder Computerkapazität mithilfe von Ressourcenanforderungen und -einschränkungen lösen können.

Anforderungen und Limits sind Mechanismen, mit denen Kubernetes Ressourcen wie Prozessor und Speicher verwaltet. Anfragen ist das Ergebnis, von dem der Container garantiert die angeforderte Ressource erhält. Wenn ein Container eine Ressource anfordert, plant Kubernetes diese nur auf dem Host, der sie bereitstellen kann. Grenzwerte Grenzwerte steuern, dass die vom Container angeforderten Ressourcen niemals einen bestimmten Wert überschreiten.



Ein Container kann die Rechenleistung nur bis zu einem bestimmten Grenzwert erhöhen. Danach wird sie begrenzt. Mal sehen, wie es funktioniert. Es gibt also zwei Arten von Ressourcen - Prozessor und Speicher. Der Kubernetes Scheduler verwendet Daten aus diesen Ressourcen, um herauszufinden, wo Ihre Pods ausgeführt werden sollen. Eine typische Herdressourcenspezifikation sieht so aus.



Jeder Container im Pod kann seine eigenen Abfragen und Einschränkungen festlegen, die alle additiv sind. Prozessorressourcen werden in Millimetern definiert. Wenn Ihr Startcontainer zwei volle Kerne benötigt, setzen Sie den Wert auf 2000 m. Wenn der Container nur 1/4 des Kerns mit Strom versorgt, beträgt der Wert 250 m. Beachten Sie, dass der Start Ihres Herdes überhaupt nicht geplant ist, wenn Sie einen Prozessorressourcenwert zuweisen, der größer als die Anzahl der Kerne des größten Knotens ist. Eine ähnliche Situation tritt auf, wenn Sie ein Sub haben, das vier Kerne benötigt, und der Kubernetes-Cluster nur aus zwei virtuellen Hauptmaschinen besteht.

Sofern Ihre Anwendung nicht speziell für die Nutzung mehrerer Kerne ausgelegt ist (wobei Programme wie komplexe wissenschaftliche Computer- und Datenbankoperationen in den Sinn kommen), empfiehlt es sich, CPU-Anforderungen auf 1 oder weniger zu setzen und dann mehr Replikate für auszuführen Skalierbarkeit. Eine solche Lösung gibt dem System mehr Flexibilität und Zuverlässigkeit.

Wenn es um Prozessorbeschränkungen geht, werden die Dinge interessanter, da es sich um eine komprimierbare Ressource handelt. Wenn sich Ihre Anwendung der Prozessorkapazitätsgrenze nähert, verlangsamt Kubernetes Ihren Container mithilfe der CPU-Drosselung, wodurch die Prozessorfrequenz verringert wird. Dies bedeutet, dass der Prozessor künstlich eingeschränkt wird, wodurch die Anwendung möglicherweise eine schlechtere Leistung erhält, der Prozess jedoch nicht beendet oder weitergegeben wird.

Speicherressourcen werden in Bytes definiert. Normalerweise wird der Wert in den Einstellungen in Mib-Mebytes gemessen. Sie können jedoch einen beliebigen Wert angeben, von Bytes bis Petabytes. Hier ist die Situation dieselbe wie bei der CPU. Wenn Sie eine Anforderung für eine Speichermenge stellen, die die Speichermenge auf Ihren Knoten überschreitet, wird die Ausführung dieses Pods nicht geplant. Im Gegensatz zu Prozessorressourcen wird der Speicher jedoch nicht komprimiert, da die Verwendung nicht eingeschränkt werden kann. Daher wird die Ausführung des Containers gestoppt, sobald die Grenzen des ihm zugewiesenen Speichers überschritten werden.



Beachten Sie, dass Sie keine Anforderungen konfigurieren können, die die Größe der Ressourcen überschreiten, die Ihre Websites bereitstellen können. Die Merkmale der gemeinsam genutzten Ressourcen für virtuelle GKE-Maschinen finden Sie unter den Links unter diesem Video.

In einer idealen Welt reichen die Standard-Containereinstellungen aus, damit die Workflows reibungslos verlaufen. Aber die reale Welt ist nicht so, die Leute können leicht vergessen, die Verwendung von Ressourcen zu konfigurieren, oder Hacker setzen Anforderungen und Einschränkungen, die die realen Fähigkeiten der Infrastruktur überschreiten. Um die Entwicklung dieser Szenarien zu verhindern, können Sie ResourceQuota-Ressourcenkontingente und LimitRange-Einschränkungsbereiche konfigurieren.

Nachdem Sie einen Namespace erstellt haben, können Sie diese mit Kontingenten blockieren. Wenn Sie beispielsweise Prod- und Dev-Namespaces haben, wird eine Vorlage verwendet, in der es überhaupt keine Produktionsquoten gibt und die Entwicklungsquoten sehr streng sind. Dies ermöglicht es dem Produkt, im Falle eines starken Anstiegs des Datenverkehrs alle verfügbaren Ressourcen für sich zu nutzen und den Entwickler vollständig zu blockieren.

Ein Ressourcenkontingent kann so aussehen. In diesem Beispiel gibt es 4 Abschnitte - dies sind die 4 untersten Codezeilen.



Schauen wir uns jeden an. Requests.cpu ist die maximale Anzahl kombinierter Prozessorleistungsanforderungen, die von allen Namespace-Containern stammen können. In diesem Beispiel können Sie 50 Container mit Anforderungen von jeweils 10 m, fünf Container mit Anforderungen von 100 m oder nur einen Container mit einer Anforderung von 500 m haben. Solange die Gesamtzahl der request.cpu dieses Namespace weniger als 500 m beträgt, ist alles in Ordnung.

Angeforderte Speicheranforderungen. Speicher ist die maximale Anzahl kombinierter Speicheranforderungen, die alle Container im Namespace haben können. Wie im vorherigen Fall können Sie 50 Container mit jeweils 2 Mib, fünf Container mit jeweils 20 Mib oder einen einzelnen Container mit 100 Mib haben, bis die Gesamtmenge des angeforderten Speichers im Namespace weniger als 100 Mebibyte beträgt.

Limits.cpu ist der maximale kombinierte Prozessorleistungswert, den alle Namespace-Container verwenden können. Wir können davon ausgehen, dass dies die Grenze der Prozessorleistungsanforderungen ist.

Schließlich ist limit.memory die maximale Menge an gemeinsam genutztem Speicher, die alle Container im Namespace verwenden können. Dies ist eine Einschränkung der Gesamtspeicheranforderungen.
Daher arbeiten Container in einem Kubernetes-Cluster standardmäßig mit unbegrenzten Computerressourcen. Mithilfe von Ressourcenkontingenten können Clusteradministratoren den Ressourcenverbrauch und deren Erstellung basierend auf dem Namespace begrenzen. Im Namespace kann das Pod-Modul oder der Container so viel CPU- und Speicherleistung verbrauchen, wie das Kontingent der Namespace-Ressourcen bestimmt. Es besteht jedoch die Sorge, dass ein unter oder ein Container alle verfügbaren Ressourcen monopolisieren könnte. Um dies zu verhindern, wird der Grenzbereich Range Range verwendet - die Richtlinie zum Einschränken der Verteilung von Ressourcen (für Pods oder Container) im Namespace.

Der Grenzbereich bietet Einschränkungen, die Folgendes umfassen können:

  • ;
  • Starage Request PersistentVolumeClaim ;
  • Request Limit ;
  • Requests/Limits .

Auf diese Weise können Sie einen Grenzbereich in Ihrem Namespace erstellen. Im Gegensatz zu dem Kontingent, das für den gesamten Namespace gilt, wird der Grenzbereich für einzelne Container verwendet. Dies kann verhindern, dass Benutzer sehr kleine oder umgekehrt riesige Container im Namespace erstellen. Der Grenzbereich kann so aussehen.



Wie im vorherigen Fall können hier 4 Abschnitte unterschieden werden. Werfen wir einen Blick auf jeden.
Im Standardabschnitt werden die Standardeinschränkungen für den Container im Kamin festgelegt. Wenn Sie diese Werte im Grenzbereich angeben, werden alle Container, für die diese Werte nicht explizit festgelegt wurden, von den Standardwerten geleitet.

Im Standardabfrageabschnitt defaultRequest werden die Standardabfragen für den Container im Herd konfiguriert. Wenn Sie diese Werte im Grenzbereich festlegen, werden diese Werte standardmäßig von Containern verwendet, für die diese Parameter nicht explizit festgelegt wurden.

Der Abschnitt max gibt die maximalen Einschränkungen an, die für den Container im Kamin festgelegt werden können. Die Werte im Standardabschnitt und die Einschränkungen für den Container können nicht über diesem Grenzwert festgelegt werden. Es ist wichtig zu beachten, dass der Maximalwert zum Standardwert wird, wenn max eingestellt ist und der Standardabschnitt fehlt.

Der Abschnitt min gibt die Mindestabfragen an, die für den Container im Kamin festgelegt werden können. Gleichzeitig können die Werte im Standardabschnitt und die Anforderungen für den Container nicht unter diesen Grenzwert gesetzt werden.

Auch hier ist es wichtig zu beachten, dass, wenn dieser Wert festgelegt ist, der Standardwert nicht ist, der Mindestwert zur Standardabfrage wird.

Infolgedessen werden diese Ressourcenanforderungen vom Kubernetes-Scheduler verwendet, um Ihre Workloads auszuführen. Damit Sie Ihre Container richtig konfigurieren können, ist es sehr wichtig zu verstehen, wie dies funktioniert. Angenommen, Sie möchten mehrere Module in Ihrem Cluster ausführen. Unter der Annahme, dass die Herdspezifikationen gültig sind, verwendet der Kubernetes-Zeitplan den zyklischen Ausgleich, um den Knoten für die Arbeitslast auszuwählen.



Kubernetes prüft, ob der Knoten von Knoten 1 über genügend Ressourcen verfügt, um Pod-Container-Anforderungen zu erfüllen. Ist dies nicht der Fall, wird er zum nächsten Knoten weitergeleitet. Wenn keiner der Knoten im System Anforderungen erfüllen kann, werden die Pods in den Status "Ausstehend" versetzt. Mit Funktionen der Google Kubernetes-Engine wie der automatischen Skalierung von Knoten kann GKE den Wartezustand automatisch ermitteln und weitere zusätzliche Knoten erstellen.

Wenn anschließend eine Überkapazität an Knoten vorhanden ist, reduziert die automatische Skalierungsfunktion deren Anzahl, um Geld zu sparen. Aus diesem Grund plant Kubernetes abfragebasierte Pods. Das Limit kann jedoch höher sein als bei Anforderungen, und in einigen Fällen gehen dem Knoten tatsächlich die Ressourcen aus. Wir nennen diesen Zustand Überbindungsstatus.



Wie gesagt, wenn wir über einen Prozessor sprechen, wird Kubernetes beginnen, Pods zu begrenzen. Jeder Pod erhält so viel, wie er angefordert hat. Wenn er jedoch gleichzeitig das Limit nicht erreicht, beginnt die Drosselung.

Bei den Speicherressourcen muss Kubernetes hier entscheiden, welche Pods gelöscht und welche aufbewahrt werden sollen, bis Sie Systemressourcen freigeben. Andernfalls stürzt das gesamte System ab.

Stellen wir uns ein Szenario vor, in dem auf einem Computer nicht genügend Arbeitsspeicher vorhanden ist. Wie wird Kubernetes dies tun?

Kubernetes sucht nach Pods, die mehr Ressourcen als angefordert verbrauchen. Wenn Ihre Container also überhaupt keine Anfragen haben, bedeutet dies, dass sie standardmäßig mehr verwenden als sie angefordert haben, einfach weil sie überhaupt nichts angefordert haben! Solche Container werden zu Hauptkandidaten für das Herunterfahren. 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 die Parameter ihrer Abfragen überschritten haben, werden sie nach Priorität sortiert und anschließend die Module mit der niedrigsten Priorität gelöscht. Wenn alle Module dieselbe Priorität haben, stoppt Kubernetes die Pods, die ihre Anforderungen mehr als die übrigen Pods überschreiten.

In sehr seltenen Fällen kann Kubernetes die Herde unterbrechen, die sich noch in seinem Geltungsbereich befinden. Dies kann passieren, wenn kritische Systemkomponenten wie der Kubelet-Agent oder Docker mehr Ressourcen verbrauchen, als für sie reserviert waren.
In der Anfangsphase kleiner Unternehmen kann der Kubernetes-Cluster problemlos funktionieren, ohne Ressourcenanforderungen und -einschränkungen festzulegen. Wenn Ihre Teams und Projekte jedoch an Größe zunehmen, 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 Ihnen viel Ärger ersparen.

Best Practices von Kubernetes. Richtig Beenden Deaktivieren


Ein bisschen Werbung :)


Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?

More articles:


All Articles