Freigeben über

Skalierungsoptionen für Anwendungen in Azure Kubernetes Service (AKS)

Wenn Sie Anwendungen in Azure Kubernetes Service (AKS) ausführen, müssen Sie möglicherweise die Menge der Computeressourcen in Ihrem Cluster aktiv erhöhen oder verringern. Wenn Sie die Anzahl der anwendungsinstanzen ändern, die Sie haben, müssen Sie möglicherweise die Anzahl der zugrunde liegenden Kubernetes-Knoten ändern. Möglicherweise müssen Sie auch eine große Anzahl anderer Anwendungsinstanzen bereitstellen.

In diesem Artikel werden die Kernkonzepte der AKS-Anwendungsskalierung eingeführt, einschließlich der manuellen Skalierung von Pods oder Knoten, der Verwendung der horizontalen automatischen Podskalierung, der automatischen Clusterskalierung und der Integration in Azure Container Instances (ACI).

Manuelles Skalieren von Pods oder Knoten

Sie können Replikate, oder Pods, und Knoten manuell skalieren, um zu testen, wie Ihre Anwendung auf eine Änderung bei den verfügbaren Ressourcen und Zuständen reagiert. Durch manuelle Skalierung von Ressourcen können Sie eine festgelegte Menge von Ressourcen definieren, die verwendet werden sollen, z. B. die Anzahl der Knoten, um eine Fixkosten zu verwalten. Zum manuellen Skalieren definieren Sie eine Replikat- oder Knotenanzahl. Die Kubernetes-API plant dann die Erstellung weiterer Pods oder das Entladen von Knoten basierend auf dieser Anzahl von Replikaten oder Knoten.

Wenn Sie Knoten verkleinern, ruft die Kubernetes-API die relevante Azure Compute-API auf, die an den vom Cluster verwendeten Computetyp gebunden ist. Zum Beispiel bestimmt die Virtual Machine Scale Sets-API, welche Knoten entfernt werden sollen, bei Clustern, die auf Virtual Machine Scale Sets basieren. Weitere Informationen dazu, wie Knoten beim Herunterskalieren für die Entfernung ausgewählt werden, finden Sie in den Häufig gestellten Fragen zu VM-Skalierungsgruppen.

Informationen zu den ersten Schritten mit der manuellen Skalierung von Knoten finden Sie unter Manuelles Skalieren von Knoten in einem AKS-Cluster. Informationen zum manuellen Skalieren der Anzahl von Pods finden Sie unter Kubectl-Skalierungsbefehl.

Horizontale automatische Podskalierung

Kubernetes verwendet die horizontale automatische Podskalierung (HPA) zum Überwachen des Ressourcenbedarfs und automatischen Skalieren der Anzahl der Pods. Standardmäßig überprüft die HPA die Metrik-API alle 15 Sekunden auf alle erforderlichen Änderungen in der Replikatanzahl, während die Metrik-API alle 60 Sekunden Daten aus dem Kubelet abruft. Daher wird HPA alle 60 Sekunden aktualisiert. Wenn Änderungen erforderlich sind, wird die Anzahl der Replikate entsprechend skaliert. HPA funktioniert mit AKS-Clustern, die Metrikserver für Kubernetes, Version 1.8 und höher bereitgestellt haben.

Automatische horizontale Kubernetes-Podskalierung

Wenn Sie die HPA für eine bestimmte Bereitstellung konfigurieren, definieren Sie die minimale und maximale Anzahl an Replikaten, die ausgeführt werden können. Außerdem definieren Sie die Metrik, anhand derer Sie die Überwachung durchführen und Skalierungsentscheidungen treffen, wie die CPU-Auslastung.

Informationen zu den ersten Schritten mit der horizontalen automatischen Podskalierung in AKS finden Sie unter Automatische Podskalierung in AKS.

Abkühlung der Skalierung von Ereignissen

Da die HPA alle 60 Sekunden effektiv aktualisiert wird, wurden frühere Skalierungsereignisse möglicherweise nicht erfolgreich abgeschlossen, bevor eine weitere Überprüfung durchgeführt wird. Dieses Verhalten kann dazu führen, dass die HPA die Anzahl der Replikate ändert, bevor das vorherige Skalierungsereignis die Anwendungsworkload empfangen und die Ressourcenanforderungen entsprechend anpassen konnte.

Um Raceereignisse zu minimieren, wird ein Verzögerungswert festgelegt. Dieser Wert definiert, wie lange die HPA nach einem Skalierungsereignis warten muss, bevor ein anderes Skalierungsereignis ausgelöst werden kann. Dieses Verhalten ermöglicht, dass die neue Replikatanzahl wirksam werden und die Metriken-API die verteilte Workload widerspiegeln kann. Es gibt keine Verzögerung für Skalierungsereignisse ab Kubernetes 1.12. Die Standardverzögerung für Skalierungsereignisse beträgt jedoch 5 Minuten.

Automatische Clusterskalierung

Um auf veränderte Podanforderungen zu reagieren, passt die automatische Kubernetes-Clusterskalierung die Anzahl von Knoten basierend auf den angeforderten Computeressourcen im Knotenpool an. Standardmäßig überprüft die automatische Clusterskalierung den Metrik-API-Server alle 10 Sekunden auf erforderliche Änderungen der Knotenanzahl. Wenn die automatische Clusterskalierung ermittelt, dass eine Änderung erforderlich ist, wird die Anzahl von Knoten im AKS-Cluster entsprechend herauf- oder herabgesetzt. Die automatische Clusterskalierung funktioniert mit Kubernetes RBAC-fähigen AKS-Clustern, die Kubernetes 1.10.x oder höher ausführen.

Automatische Kubernetes-Clusterskalierung

Die automatische Clusterskalierung wird normalerweise zusammen mit der horizontalen automatischen Podskalierung verwendet. Im kombinierten Einsatz setzt die horizontale Podautoskalierung die Anzahl von Pods je nach Bedarf der Anwendung herauf oder herab, und die Clusterautoskalierung passt die Anzahl von Knoten für die Ausführung weiterer Pods an.

Informationen zu den ersten Schritten mit der automatischen Clusterskalierung in AKS finden Sie unter Automatische Clusterskalierung in AKS.

Aufskalieren von Ereignissen

Wenn ein Knoten nicht über ausreichende Computeressourcen zum Ausführen eines angeforderten Pods verfügt, kann dieser Pod den Planungsprozess nicht erfüllen. Der Pod kann erst gestartet werden, wenn weitere Computeressourcen innerhalb des Knotenpools verfügbar gemacht werden.

Wenn die automatische Clusterskalierung Pods erkennt, die aufgrund von Einschränkungen von Knotenpoolressourcen nicht eingeplant werden können, wird die Anzahl von Knoten innerhalb des Knotenpools heraufgesetzt, um die zusätzlichen Computeressourcen bereitzustellen. Wenn diese Knoten erfolgreich bereitgestellt werden und für die Verwendung innerhalb des Knotenpools verfügbar sind, werden die Pods zur Ausführung darauf eingeplant.

Wenn Ihre Anwendung schnell skalieren muss, bleiben einige Pods möglicherweise in einem Zustand der Planung, bis weitere Knoten, die vom Cluster-Autoscaler bereitgestellt werden, die geplanten Pods akzeptieren können. Für Anwendungen mit hohen Burstanforderungen können Sie mit virtuellen Knoten und Azure Container Instances skalieren.

Abskalieren von Ereignissen

Die automatische Clusterskalierung überwacht auch den Status der Podplanung für Knoten, die nicht vor kurzem neue Planungsanforderungen empfangen haben. Dieses Szenario zeigt, dass der Knotenpool mehr Computeressourcen als erforderlich besitzt, und dass die Anzahl der Knoten verringert werden kann. Standardmäßig werden Knoten, die einen Schwellenwert überschreiten, für den 10 Minuten nicht mehr benötigt werden, für den Löschvorgang geplant. Wenn diese Situation eintritt, werden Pods zur Ausführung auf anderen Knoten innerhalb des Knotenpools eingeplant, und die automatische Clusterskalierung setzt die Anzahl der Knoten herab.

Bei Ihren Anwendungen kann eine Unterbrechung auftreten, da Pods auf anderen Knoten eingeplant werden, wenn die automatische Clusterskalierung die Anzahl der Knoten herabsetzt. Um Unterbrechungen zu minimieren, vermeiden Sie Anwendungen, die eine einzelne Podinstanz verwenden.

Ereignisgesteuerte automatische Kubernetes-Skalierung (KEDA)

Ereignisgesteuerte automatische Kubernetes-Skalierung (Kubernetes Event-Driven Autoscaling, KEDA) ist eine Open Source-Komponente für die ereignisgesteuerte automatische Skalierung von Workloads. Sie skaliert Workloads dynamisch basierend auf der Anzahl der empfangenen Ereignisse. KEDA erweitert Kubernetes um eine als ScaledObject bezeichnete benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD), um zu beschreiben, wie Anwendungen als Reaktion auf bestimmten Datenverkehr skaliert werden sollen.

Die KEDA-Skalierung ist in Szenarien hilfreich, in denen Workloads Datenverkehrsbursts empfangen oder hohe Datenmengen verarbeiten. KEDA unterscheidet sich vom Horizontal Pod Autoscaler, da KEDA ereignisgesteuert ist und basierend auf der Anzahl der Ereignisse skaliert, während HPA metrikbasiert auf die Ressourcenauslastung, wie CPU und Arbeitsspeicher, skaliert.

Erste Schritte mit dem KEDA-Add-On in AKS finden Sie unter Übersicht über KEDA.

Automatische Bereitstellung von Knoten

Die automatische Bereitstellung von Knoten (Vorschau) (NAP) nutzt das Open-Source-Projekt Karpenter, das automatisch bereitstellt, konfiguriert und verwaltet Karpenter auf Ihrem AKS-Cluster. NAP stellt Knoten basierend auf ausstehenden Pod-Ressourcenanforderungen dynamisch bereit; es wählt automatisch die optimale VM-SKU und -Menge aus, um die Echtzeitnachfrage zu erfüllen.

NAP verwendet eine vordefinierte Liste von VM-SKUs als Ausgangspunkt, um zu entscheiden, welche SKU für ausstehende Workloads am besten geeignet ist. Für eine genauere Kontrolle können Benutzer die oberen Grenzwerte für Ressourcen definieren, die von einem Knotenpool verwendet werden, und Einstellungen, an denen Workloads geplant werden sollen, wenn mehrere Knotenpools vorhanden sind.

Burst zu Azure Container Instances (ACI)

Um Ihren AKS-Cluster schnell zu skalieren, können Sie ihn in Azure Container Instances (ACI) integrieren. Kubernetes verfügt über integrierte Komponenten zum Skalieren der Replikat- und Knotenanzahl. Wenn Ihre Anwendung jedoch schnell skalieren muss, kann die horizontale Pod-Autoskalierung möglicherweise mehr Pods planen, als die vorhandenen Rechenressourcen des Knotenpools unterstützen können. Wenn dieses Szenario konfiguriert ist, löst dieses Szenario dann die Cluster-Autoskalierung aus, um weitere Knoten im Knotenpool bereitzustellen. Es kann jedoch einige Minuten dauern, bis diese Knoten erfolgreich bereitgestellt und dem Kubernetes-Scheduler das Ausführen von Pods auf diesen Knoten gestattet werden.

Kubernetes-Burstskalierung in ACI

Mit ACI können Sie schnell Containerinstanzen ohne zusätzlichen Infrastrukturaufwand bereitstellen. Beim Herstellen der Verbindung mit AKS wird ACI eine sichere logische Erweiterung Ihres AKS-Clusters. Die virtuelle Knoten-Komponente, die unter Virtual Kubelet zu finden ist, wird in Ihrem AKS-Cluster installiert, der ACI als virtuellen Kubernetes-Knoten darstellt. Kubernetes kann dann Pods einplanen, die als ACI-Instanzen über virtuelle Knoten ausgeführt werden, nicht direkt in Ihrem AKS-Cluster als Pods auf VM-Knoten.

Die Anwendung erfordert keine Änderung, um virtuelle Knoten verwenden zu können. Ihre Bereitstellungen können AKS und ACI übergreifend und ohne Verzögerung skalieren, da die automatische Clusterskalierung neue Knoten im AKS-Cluster bereitstellt.

Virtuelle Knoten werden in einem anderen Subnetz im selben virtuellen Netzwerk wie Ihr AKS-Cluster bereitgestellt. Diese Konfiguration des virtuellen Netzwerks schützt den Datenverkehr zwischen ACI und AKS. Wie ein AKS-Cluster ist eine ACI-Instanz eine sichere, logische Computeressource, die von anderen Benutzern isoliert ist.

Nächste Schritte

Informationen zu den ersten Schritten mit der Skalierung von Anwendungen finden Sie in den folgenden Ressourcen:

Weitere Informationen zu den wesentlichen Konzepten von Kubernetes und AKS finden Sie in den folgenden Artikeln: