So skalieren Sie Ihre Workloads auf DigitalOcean-Kubernetes automatisch

Bei der Arbeit mit einer Anwendung, die aufKubernetes basiert, müssen Entwickler häufig zusätzlichepods einplanen, um Zeiten mit Spitzenverkehr oder erhöhter Lastverarbeitung zu bewältigen. Standardmäßig ist das Planen dieser zusätzlichen Pods ein manueller Schritt. Der Entwickler muss die Anzahl der gewünschtenreplicas indeployment object ändern, um den erhöhten Datenverkehr zu berücksichtigen, und sie dann wieder ändern, wenn die zusätzlichen Pods nicht mehr benötigt werden. Diese Abhängigkeit von manuellen Eingriffen kann in vielen Szenarien weniger als ideal sein. Beispielsweise könnte Ihre Arbeitslast mitten in der Nacht die Stoßzeiten erreichen, wenn niemand zur Skalierung der Pods wach ist, oder Ihre Website könnte einen unerwarteten Anstieg des Datenverkehrs verzeichnen, wenn eine manuelle Antwort nicht schnell genug wäre, um die Last zu bewältigen. In diesen Situationen besteht der effizienteste und am wenigsten fehleranfällige Ansatz darin, die Skalierung Ihrer Cluster mitHorizontal Pod Autoscaler (HPA)zu automatisieren.

Durch die Verwendung von Informationen ausMetrics Server erkennt der HPA eine erhöhte Ressourcennutzung und skaliert daraufhin Ihre Arbeitslast für Sie. Dies ist besonders bei Mikroservice-Architekturen nützlich und bietet Ihrem Kubernetes-Cluster die Möglichkeit, Ihre Bereitstellung auf der Grundlage von Messwerten wie der CPU-Auslastung zu skalieren. In Kombination mitDigitalOcean Kubernetes (DOKS) kann ein verwaltetes Kubernetes-Angebot, das Entwicklern eine Plattform für die Bereitstellung containerisierter Anwendungen bietet, mithilfe von HPA eine automatisierte Infrastruktur erstellen, die sich schnell an Änderungen des Datenverkehrs und der Auslastung anpasst.

[.Hinweis]##

Note: Wenn Sie überlegen, ob Sie die automatische Skalierung für Ihre Workload verwenden möchten, beachten Sie, dass die automatische Skalierung am besten für zustandslose Anwendungen geeignet ist, insbesondere für Anwendungen, bei denen mehrere Instanzen der Anwendung ausgeführt werden können und Datenverkehr parallel akzeptiert wird. Diese Parallelität ist wichtig, da das Hauptziel der automatischen Skalierung darin besteht, die Arbeitslast einer Anwendung dynamisch auf mehrere Instanzen in Ihrem Kubernetes-Cluster zu verteilen, um sicherzustellen, dass Ihre Anwendung über die erforderlichen Ressourcen verfügt, um den Datenverkehr zeitnah und stabil zu bedienen, ohne eine einzelne Instanz zu überlasten.

Ein Beispiel für eine Workload, die diese Parallelität nicht aufweist, ist die automatische Skalierung von Datenbanken. Das Einrichten der automatischen Skalierung für eine Datenbank wäre erheblich komplexer, da Sie die Rennbedingungen, Probleme mit der Datenintegrität, der Datensynchronisierung und das ständige Hinzufügen und Entfernen von Datenbankclustermitgliedern berücksichtigen müssten. Aus diesen Gründen empfehlen wir nicht, die automatische Skalierungsstrategie dieses Lernprogramms für Datenbanken zu verwenden.

In diesem Lernprogramm richten Sie eine Beispielbereitstellung fürNginxauf DOKS ein, die horizontal skaliert werden kann, um der erhöhten CPU-Auslastung Rechnung zu tragen. Sie erreichen dies, indem Sie Metrics Server in Ihrem Cluster bereitstellen, um Pod-Metriken für HPA zu erfassen, die bei der Ermittlung des Zeitpunkts für die Skalierung verwendet werden sollen.

Bevor Sie mit diesem Handbuch beginnen, benötigen Sie Folgendes:

[[Schritt-1 - Erstellen einer Testbereitstellung]] == Schritt 1 - Erstellen einer Testbereitstellung

Um die Auswirkungen des HPA zu veranschaulichen, stellen Sie zunächst eine Anwendung bereit, die Sie für die automatische Skalierung verwenden. In diesem Lernprogramm wird ein StandardNginx Docker image als Bereitstellung verwendet, da es vollständig parallel betrieben werden kann, in Kubernetes häufig mit Tools wieNginx Ingress Controller verwendet wird und leicht einzurichten ist. Diese Nginx-Bereitstellung dient als statischeWelcome to Nginx!-Seite, die im Basisimage standardmäßig enthalten ist. Wenn Sie bereits eine Bereitstellung haben, die Sie skalieren möchten, können Sie diese Bereitstellung verwenden und diesen Schritt überspringen.

Erstellen Sie die Beispielbereitstellung mit dem Nginx-Basisimage, indem Sie den folgenden Befehl ausführen. Sie können den Namenweb ersetzen, wenn Sie Ihrer Bereitstellung einen anderen Namen geben möchten:

Das Flag--image=nginx:latesterstellt die Bereitstellung aus der neuesten Version des Nginx-Basisimages.

Nach einigen Sekunden dreht sich der Pod Ihresweb. Um diesen Pod anzuzeigen, führen Sie den folgenden Befehl aus, der die Pods anzeigt, die im aktuellen Namespace ausgeführt werden:

Dadurch erhalten Sie eine Ausgabe ähnlich der folgenden:

Beachten Sie, dass ursprünglich nur ein Pod bereitgestellt wurde. Sobald die automatische Skalierung ausgelöst wird, werden automatisch weitere Pods gedreht.

Sie haben jetzt eine grundlegende Bereitstellung, die innerhalb des Clusters ausgeführt wird. Dies ist die Bereitstellung, die Sie für die automatische Skalierung konfigurieren möchten. Der nächste Schritt besteht darin, diese Bereitstellung so zu konfigurieren, dass ihre Ressourcenanforderungen und -beschränkungen definiert werden.

[[Schritt-2 - Festlegen von CPU-Grenzwerten und Anforderungen für Ihre Bereitstellung]] == Schritt 2 - Festlegen von CPU-Grenzwerten und Anforderungen für Ihre Bereitstellung

In diesem Schritt legen Sierequests and limits für die CPU-Auslastung für Ihre Bereitstellung fest. Limits in Kubernetes werden in der Bereitstellung festgelegt, um die maximale Menge der Ressource (entweder CPU oder Speicher) zu beschreiben, die der Pod verwenden kann. Requests werden in der Bereitstellung festgelegt, um zu beschreiben, wie viel dieser Ressource auf einem Knoten benötigt wird, damit dieser Knoten als gültiger Knoten für die Planung betrachtet wird. Wenn auf Ihrem Webserver beispielsweise eine Speicheranforderung von 1 GB festgelegt wurde, werden nur Knoten mit mindestens 1 GB freiem Speicher für die Planung berücksichtigt. Für die automatische Skalierung müssen diese Grenzwerte und Anforderungen festgelegt werden, da der HPA diese Informationen benötigt, wenn er Skalierungs- und Planungsentscheidungen trifft.

Um die Anforderungen und Beschränkungen festzulegen, müssen Sie Änderungen an der soeben erstellten Bereitstellung vornehmen. In diesem Lernprogramm wird der folgende Befehlkubectl edit verwendet, um die im Cluster gespeicherte API-Objektkonfiguration zu ändern. Der Befehlkubectl edit öffnet den Editor, der durch die UmgebungsvariablenKUBE_EDITOR oderEDITORdefiniert ist, oder greift für Windows standardmäßig aufvi for Linux odernotepad zurück.

Bearbeiten Sie Ihre Bereitstellung:

Sie sehen die Konfiguration für die Bereitstellung. Sie können jetzt Ressourcenlimits und Anforderungen festlegen, die für die CPU-Auslastung Ihrer Bereitstellung festgelegt wurden. Diese Grenzwerte legen die Basis fest, wie viel von jeder Ressource ein Pod dieser Bereitstellung einzeln verwenden kann. Durch Einstellen dieser Option erhält die HPA einen Referenzrahmen, anhand dessen festgestellt werden kann, ob ein Pod überarbeitet wird. Wenn Sie beispielsweise erwarten, dass Ihr Pod einen oberen Prozentsatz (t0) von 100 Millicore CPU hat und der Pod derzeit 95 Millicore verwendet, weiß HPA, dass er zu 95{'t0': 'limit'}usgelastet ist. Ohne diese Beschränkung auf 100 Milicores kann die HPA die volle Kapazität des Pods nicht entschlüsseln.

Wir können die Grenzen und Anforderungen im Abschnittresources festlegen:

Bereitstellungskonfigurationsdatei

In diesem Lernprogramm setzen Sierequests für die CPU auf100m und den Speicher auf250Mi. Diese Werte dienen nur zu Demonstrationszwecken. Jede Workload ist anders, daher sind diese Werte für andere Workloads möglicherweise nicht sinnvoll. In der Regel sollten diese Werte auf das Maximum festgelegt werden, das ein Pod dieser Workload voraussichtlich verwenden wird. Es wird empfohlen, die Anwendung zu überwachen und Daten zur Ressourcennutzung in Bezug auf die Leistung zu niedrigen und Spitzenzeiten zu erfassen, um diese Werte zu ermitteln. Diese Werte können auch jederzeit angepasst und geändert werden, sodass Sie jederzeit zurückkehren und Ihre Bereitstellung später optimieren können.

Fügen Sie die folgenden hervorgehobenen Zeilen unter dem Abschnittresources Ihres Nginx-Containers ein:

Bereitstellungskonfigurationsdatei

Sobald Sie diese Zeilen eingefügt haben, speichern und beenden Sie die Datei. Wenn es ein Problem mit der Syntax gibt, öffnetkubectl die Datei erneut für Sie mit einem Fehler, der für weitere Informationen veröffentlicht wird.

Nachdem Sie Ihre Grenzwerte und Anforderungen festgelegt haben, müssen Sie sicherstellen, dass Ihre Metriken erfasst werden, damit der HPA diese Grenzwerte überwachen und korrekt einhalten kann. Zu diesem Zweck richten Sie einen Dienst zum Erfassen der CPU-Metriken ein. In diesem Lernprogramm verwenden Sie das Metrics Server-Projekt zum Sammeln dieser Metriken, die Sie mit einem Helm-Diagramm installieren.

[[Schritt 3 - Installieren des Metrikservers]] == Schritt 3 - Installieren des Metrikservers

Als nächstes installieren Sie dieKubernetes Metric Server. Dies ist der Server, auf dem Pod-Metriken erfasst werden, anhand derer der HPA entscheidet, ob eine automatische Skalierung erforderlich ist.

Führen Sie den folgenden Befehl aus, um den Metrics Server mitHelm zu installieren:

Dadurch wird die neueste stabile Version von Metrics Server installiert. Das Flag--name benennt diese Versionmetrics-server.

Wenn Sie auf die Initialisierung dieses Pods warten, versuchen Sie, mit dem Befehlkubectl top poddie Metriken Ihres Pods anzuzeigen:

Dieser Befehl soll einen Überblick über die Ressourcennutzung in Ihrem Cluster auf Pod-Ebene geben. Aufgrund der Art und Weise, wie DOKS mit DNS umgeht, gibt dieser Befehl an dieser Stelle einen Fehler zurück:

Dieser Fehler tritt auf, weil DOKS-Knoten keinen DNS-Eintrag für sich selbst erstellen und weil Metrics Server die Knoten über ihre Hostnamen kontaktiert, werden die Hostnamen nicht richtig aufgelöst. Um dieses Problem zu beheben, ändern Sie die Art und Weise, in der der Metrics Server mit Knoten kommuniziert, indem Sie dem Metrics Server-Container mit dem folgenden Befehl Laufzeitflags hinzufügen:

Sie werden ein Flag unter dem Abschnittcommand hinzufügen.

Metrics-Server-Konfigurationsdatei

Das Flag, das Sie hinzufügen, ist--kubelet-preferred-address-types=InternalIP. Dieses Flag weist den Metrikserver an, Knoten mit ihreninternalIPim Gegensatz zu ihrem Hostnamen zu kontaktieren. Sie können dieses Flag als Problemumgehung für die Kommunikation mit den Knoten über interne IP-Adressen verwenden.

Fügen Sie außerdem das Flag--metric-resolution hinzu, um die Standardrate zu ändern, mit der der Metrics Server Metriken abkratzt. In diesem Lernprogramm legen wir fest, dass Metrics Server alle60s Datenpunkte erstellt. Wenn Sie jedoch mehr Metrikdaten wünschen, können Sie den Metrics Server bitten, alle10s oder20sMetriken zu kratzen. s. Dadurch erhalten Sie mehr Datenpunkte für die Ressourcennutzung pro Zeitraum. Fühlen Sie sich frei, diese Auflösung an Ihre Bedürfnisse anzupassen.

Fügen Sie der Datei die folgenden hervorgehobenen Zeilen hinzu:

Metrics-Server-Konfigurationsdatei

Speichern und beenden Sie den Editor, nachdem die Markierung hinzugefügt wurde.

Verwenden Sie nach einigen Minutenkubectl top pod, um zu überprüfen, ob Ihr Metrics Server ausgeführt wird. Mit diesem Befehl können wir wie bisher Ressourcen auf Pod-Ebene nutzen. Diesmal können Sie auf einem funktionierenden Metrics Server die Metriken für jeden Pod anzeigen:

Dies gibt bei laufendem Metrics Server-Pod die folgende Ausgabe aus:

Sie verfügen nun über einen funktionsfähigen Metrics Server und können die Ressourcennutzung von Pods in Ihrem Cluster anzeigen und überwachen. Als Nächstes konfigurieren Sie den HPA so, dass er diese Daten überwacht und auf Zeiträume mit hoher CPU-Auslastung reagiert.

[[Schritt-4 - Erstellen und Validieren des horizontalen Pod-Autoscalers]] == Schritt 4 - Erstellen und Validieren des horizontalen Pod-Autoscalers

Zuletzt müssen Sie den Horizontal Pod Autoscaler (HPA) für Ihre Bereitstellung erstellen. Der HPA ist das eigentliche Kubernetes-Objekt, das die von Ihrem Metrics Server erfassten CPU-Nutzungsdaten routinemäßig überprüft und Ihre Bereitstellung anhand der in Schritt 2 festgelegten Schwellenwerte skaliert.

Erstellen Sie die HPA mit dem Befehlkubectl autoscale:

Dieser Befehl erstellt den HPA für die Bereitstellung vonweb. Außerdem wird das Flag--max verwendet, um die maximalen Replikate festzulegen, auf dieweb skaliert werden kann. In diesem Fall legen Sie4 fest.

Das--cpu-percent-Flag teilt dem HPA mit, bei wie viel Prozent des in Schritt 2 festgelegten Grenzwerts Sie die automatische Skalierung auslösen möchten. Hierbei werden auch die Anforderungen verwendet, um die skalierten Pods für einen Knoten zu planen, der die anfängliche Ressourcenzuweisung aufnehmen kann. Wenn in diesem Beispiel das Limit, das Sie für Ihre Bereitstellung in Schritt 1 festgelegt haben, 100 Millicores (100m) beträgt, löst dieser Befehl eine automatische Skalierung aus, sobald der Pod80m bei durchschnittlicher CPU-Auslastung erreicht. Auf diese Weise kann die Bereitstellung automatisch skaliert werden, bevor die CPU-Ressourcen aufgebraucht werden.

Jetzt, da Ihre Bereitstellung automatisch skaliert werden kann, ist es an der Zeit, dies zu testen.

Zur Validierung generieren Sie eine Last, die Ihren Cluster über Ihren Schwellenwert setzt, und beobachten dann, wie der Autoscaler übernimmt. Öffnen Sie zunächst ein zweites Terminal, um die aktuell geplanten Pods anzuzeigen und die Liste der Pods alle 2 Sekunden zu aktualisieren. Verwenden Sie dazu den Befehlwatch in diesem zweiten Terminal:

Der Befehlwatch gibt den als Argumente angegebenen Befehl fortlaufend aus und zeigt die Ausgabe in Ihrem Terminal an. Die Dauer zwischen Wiederholungen kann mit dem Flag-nweiter konfiguriert werden. Für die Zwecke dieses Lernprogramms ist die Standardeinstellung von zwei Sekunden ausreichend.

Das Terminal zeigt nun zunächst die Ausgabe vonkubectl top pods an und aktualisiert dann alle 2 Sekunden die von diesem Befehl generierte Ausgabe, die ungefähr so ​​aussieht:

Beachten Sie die Anzahl der Pods, die derzeit fürweb bereitgestellt werden.

Wechseln Sie zurück zu Ihrem ursprünglichen Terminal. Sie öffnen jetzt mitkubectl exec ein Terminal in Ihrem aktuellenweb-Pod und erstellen eine künstliche Last. Sie können dies erreichen, indem Sie in den Pod gehen undstress CLI tool installieren.

Geben Sie Ihren Pod mitkubectl exec ein und ersetzen Sie den markierten Pod-Namen durch den Namen Ihresweb-Pods:

Dieser Befehl ist im Konzept der Verwendung vonssh zum Anmelden an einem anderen Computer sehr ähnlich. /bin/bash erstellt eine Bash-Shell in Ihrem Pod.

Aktualisieren Sie anschließend in der Bash-Shell in Ihrem Pod die Repository-Metadaten und installieren Sie das Paketstress.

[.Hinweis]##

Note: Für CentOS-basierte Container wäre dies:

Generieren Sie als Nächstes mit dem Befehlstress eine CPU-Auslastung Ihres Pods und lassen Sie ihn ausführen:

Kehren Sie nun im zweiten Terminal zum Befehlwatchzurück. Warten Sie einige Minuten, bis der Metrics Server CPU-Daten erfasst hat, die über dem von der HPA festgelegten Schwellenwert liegen. Beachten Sie, dass Metriken standardmäßig mit der Rate erfasst werden, mit der Sie--metric-resolution bei der Konfiguration des Metrikservers festgelegt haben. Es kann ungefähr eine Minute dauern, bis die Nutzungskennzahlen aktualisiert sind.

Nach ungefähr zwei Minuten sehen Sie, wie sich zusätzlicheweb-Schoten drehen:

Sie können jetzt sehen, dass der HPA neue Pods basierend auf der von Metrics Server erfassten CPU-Auslastung geplant hat. Wenn Sie mit dieser Validierung zufrieden sind, verwenden SieCTRL+C, um den Befehlstress in Ihrem ersten Terminal zu stoppen, und beenden Sie dann die Bash-Shell Ihres Pods.

In diesem Artikel haben Sie eine Bereitstellung erstellt, die basierend auf der CPU-Auslastung automatisch skaliert wird. Sie haben Ihrer Bereitstellung CPU-Ressourcenbeschränkungen und -anforderungen hinzugefügt, Metrics Server mithilfe von Helm in Ihrem Cluster installiert und konfiguriert und einen HPA erstellt, um Skalierungsentscheidungen zu treffen.

Dies war eine Demonstrationsbereitstellung von Metrics Server und HPA. Jetzt können Sie die Konfiguration an Ihre speziellen Anwendungsfälle anpassen. Stellen Sie sicher, dass Sie in den Dokumenten vonKubernetes HPAnach Hilfe und Informationen zurequests and limitationsuchen. Überprüfen Sie auch dieMetrics Server project, um alle einstellbaren Einstellungen zu sehen, die für Ihren Anwendungsfall gelten können.

Wenn Sie mehr mit Kubernetes tun möchten, gehen Sie zu unserenKubernetes Community page oder erkunden Sie unsereManaged Kubernetes service.