Cluster Autoscaler - Amazon EKS

Cluster Autoscaler

Der Kubernetes Cluster Autoscaler passt die Anzahl der Knoten in Ihrem Cluster automatisch an, wenn Pods ausfallen oder auf andere Knoten umgeplant werden. Der Cluster Autoscaler wird normalerweise als Bereitstellung in Ihrem Cluster installiert. Es verwendet die Führungsauswahl, um eine hohe Verfügbarkeit sicherzustellen, aber die Skalierung wird jeweils nur von einem Replikat durchgeführt.

Stellen Sie vor der Bereitstellung des Cluster Autoscaler sicher, dass Sie mit der Schnittstelle von Kubernetes-Konzepten mit AWS-Funktionen vertraut sind. Die folgenden Begriffe werden in diesem Thema verwendet:

  • Kubernetes Cluster Autoscaler – Eine Kernkomponente der Kubernetes-Steuerebene, die Planungs- und Skalierungsentscheidungen trifft. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Kubernetes-Steuerebene auf GitHub.

  • AWS-Cloud-Provider-Implementierung – Eine Erweiterung des Kubernetes Cluster Autoscaler, die die Entscheidungen des Kubernetes Cluster Autoscaler durch die Kommunikation mit AWS-Produkten und -Services wie Amazon EC2 implementiert. Weitere Informationen finden Sie unter Cluster Autoscaler auf AWS auf GitHub.

  • Knotengruppen – Eine Kubernetes-Abstraktion für eine Gruppe von Knoten innerhalb eines Clusters. Knotengruppen sind keine echte Kubernetes-Ressource, aber sie werden als Abstraktion im Cluster Autoscaler, der Cluster-API und anderen Komponenten gefunden. Knoten, die innerhalb einer einzelnen Knotengruppe gefunden werden, können mehrere gemeinsame Eigenschaften wie Markierungen und Taints aufweisen. Sie können jedoch weiterhin aus mehr als einer Availability Zone oder einem Instance-Typ bestehen.

  • Amazon-EC2-Auto-Scaling-Gruppen – Eine Funktion von AWS, die vom Cluster Autoscaler verwendet wird. Auto-Scaling-Gruppen eignen sich für eine Vielzahl von Anwendungsfällen. Amazon-EC2-Auto-Scaling-Gruppen sind so konfiguriert, dass Instances gestartet werden, die automatisch ihrem Kubernetes-Cluster beitreten. Sie wenden auch Markierungen und Taints auf ihre entsprechende Knotenressource in der Kubernetes-API an.

Als Referenz werden Verwaltete Knotengruppen mit Amazon-EC2-Auto-Scaling-Gruppen verwaltet und sind mit dem Cluster Autoscaler kompatibel.

In diesem Thema wird beschrieben, wie Sie den Cluster Autoscaler in Ihrem Amazon-EKS-Cluster bereitstellen und konfigurieren können, um Ihre Amazon-EC2-Auto-Scaling-Gruppen zu ändern.

Prerequisites

Vor der Bereitstellung des Cluster Autoscaler müssen Sie die folgenden Voraussetzungen erfüllen:

  • Über einen vorhandenen Amazon-EKS-Cluster verfügen – Wenn Sie keinen Cluster haben, lesen Sie Erstellen eines Amazon-EKS-Clusters.

  • Ein vorhandener IAM-OIDC-Anbieter für Ihren Cluster. Um festzustellen, ob Sie eine haben oder erstellen müssen, lesen Sie Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster.

  • Knotengruppen mit Auto-Scaling-Gruppen-Tags – Der Cluster Autoscaler benötigt die folgenden Tags in Ihren Auto-Scaling-Gruppen, damit sie automatisch erkannt werden können.

    • Wenn Sie eksctl zum Erstellen Ihrer Knotengruppen verwendet haben, werden diese Tags automatisch angewendet.

    • Wenn Sie eksctl nicht verwendet haben, müssen Sie Ihre Auto-Scaling-Gruppen manuell mit den folgenden Tags versehen. Weitere Informationen finden Sie unter Markierung von Amazon-EC2-Ressourcen im Amazon-EC2-Benutzerhandbuch für Linux-Instances.

    Schlüssel Value
    k8s.io/cluster-autoscaler/<cluster-name>

    owned

    k8s.io/cluster-autoscaler/enabled TRUE

Erstellen Sie eine IAM-Richtlinie und -Rolle

Erstellen Sie eine IAM-Richtlinie, die die Berechtigungen erteilt, die der Cluster Autoscaler benötigt, um eine IAM-Rolle zu verwenden. Ersetzen Sie während der gesamten Prozeduren alle <example-values> (einschließlich <>) durch Ihre eigenen Werte.

  1. Erstellen Sie eine IAM-Richtlinie.

    1. Speichern Sie den folgenden Inhalt in einer Datei namens cluster-autoscaler-policy.json. Wenn Ihre vorhandenen Knotengruppen mit eksctl erstellt wurden und Sie die Option --asg-access verwendet haben, ist diese Richtlinie bereits vorhanden und Sie können mit Schritt 2 fortfahren.

      { "Version": "2012-10-17", "Statement": [ { "Action": [ "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup", "ec2:DescribeLaunchTemplateVersions" ], "Resource": "*", "Effect": "Allow" } ] }
    2. Erstellen Sie die Richtlinie mit dem folgenden Befehl. Sie können den Wert für policy-name ändern.

      aws iam create-policy \ --policy-name AmazonEKSClusterAutoscalerPolicy \ --policy-document file://cluster-autoscaler-policy.json

      Notieren Sie sich den Amazon-Ressourcennamen (ARN), der in der Ausgabe zurückgegeben wird. Sie müssen sie in einem späteren Schritt verwenden.

  2. Sie können eine IAM-Rolle erstellen und ihr eine IAM-Richtlinie mit eksctl oder AWS Management Console zuordnen. Wählen Sie die gewünschte Registerkarte für die folgenden Anweisungen.

    eksctl
    1. Führen Sie den folgenden Befehl aus, falls Sie Ihren Amazon-EKS-Cluster mit eksctl erstellt haben. Wenn Sie Ihre Knotengruppen mit der Option --asg-access erstellt haben, ersetzen Sie <AmazonEKSClusterAutoscalerPolicy> durch den Namen der IAM-Richtlinie, die eksctl für Sie erstellt hat. Der Richtlinienname ähnelt eksctl-<cluster-name>-nodegroup-ng-<xxxxxxxx>-PolicyAutoScaling.

      eksctl create iamserviceaccount \ --cluster=<my-cluster> \ --namespace=kube-system \ --name=cluster-autoscaler \ --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/<AmazonEKSClusterAutoscalerPolicy> \ --override-existing-serviceaccounts \ --approve
    2. Wir empfehlen, dass Sie, falls Sie Ihre Knotengruppen mit der Option --asg-access erstellt haben, die von eksctl erstellte IAM-Richtlinie trennen und an das Amazon-EKS-Knoten-IAM-Rolle anhängen, das eksctl für Ihre Knotengruppen erstellt hat. Sie trennen die Richtlinie von der Knoten-IAM-Rolle, damit Cluster Autoscaler ordnungsgemäß funktioniert. Durch das Trennen der Richtlinie werden anderen Pods auf Ihren Knoten nicht die Berechtigungen in der Richtlinie zugewiesen. Weitere Informationen finden Sie unter Entfernen von IAM-Identitätsberechtigungen im Amazon-EC2-Benutzerhandbuch für Linux-Instances.

    AWS Management Console
    1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.

    2. Wählen Sie im Navigations-Panel Rollen und Rolle erstellen aus.

    3. Wählen Sie im Abschnitt Select type of trusted entity (Typ der vertrauenswürdigen Entität auswählen) die Option Web identity (Web-Identität) aus.

    4. Im Abschnitt Choose a web identity provider (Webidentitätsanbieter auswählen):

      1. Wählen Sie für Identity provider (Identitätsanbieter) die URL für Ihren Amazon-EKS-Cluster aus.

      2. Wählen Sie für Audience (Zielgruppe) sts.amazonaws.com.

    5. Wählen Sie Next: Permissions aus.

    6. Wählen Sie im Abschnitt Richtlinie anhängen die AmazonEKSClusterAutoscalerPolicy-Richtlinie aus, die Sie in Schritt 1 erstellt haben, um sie für Ihr Service-Konto zu verwenden.

    7. Wählen Sie Next: Tags (Weiter: Tags (Markierungen)) aus.

    8. Auf dem Bildschirm Add tags (optional) (Tags hinzufügen (optional)) können Sie Tags für das Konto hinzufügen. Klicken Sie auf Next: Review (Weiter: Prüfen).

    9. Geben Sie für Rollenname einen Namen für Ihre Rolle ein, z. B. AmazonEKSClusterAutoscalerRole, und wählen Sie dann Rolle erstellen aus.

    10. Nachdem die Rolle erstellt wurde, wählen Sie die Rolle in der Konsole aus, um sie zur Bearbeitung zu öffnen.

    11. Klicken Sie auf der Registerkarte Trust Relationships (Vertrauensbeziehungen) auf Edit Trust Relationship (Vertrauensbeziehungen bearbeiten).

    12. Suchen Sie die Zeile, die wie folgt aussieht:

      "oidc.eks.us-west-2.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E:aud": "sts.amazonaws.com"

      Ändern Sie die Zeile so, dass sie wie die folgende Zeile aussieht. Ersetzen Sie <EXAMPLED539D4633E53DE1B716D3041E> (einschließlich <>) durch die OIDC-Anbieter-ID Ihres Clusters und ersetzen Sie <region-code> durch den Regionscode, in dem sich Ihr Cluster befindet.

      "oidc.eks.<region-code>.amazonaws.com/id/<EXAMPLED539D4633E53DE1B716D3041E>:sub": "system:serviceaccount:kube-system:cluster-autoscaler"
    13. Wählen Sie Update Trust Policy (Vetrauensrichtlinie aktualisieren) aus, um den Vorgang abzuschließen.

Bereitstellen des Cluster Autoscalers

Führen Sie die folgenden Schritte aus, um den Cluster Autoscaler bereitzustellen. Wir empfehlen Ihnen, Überlegungen zur Bereitstellung zu überprüfen und die Cluster-Autoscaler-Bereitstellung zu optimieren, bevor Sie sie in einem Produktionscluster bereitstellen.

So stellen Sie den Cluster Autoscaler bereit

  1. Bereitstellen des Cluster-Autoscalers.

    kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
  2. Fügen Sie dem cluster-autoscaler-Servicekonto den ARN der IAM-Rolle hinzu, die Sie zuvor erstellt haben. Ersetzen Sie die <Beispielwerte> durch eigene Werte.

    kubectl annotate serviceaccount cluster-autoscaler \ -n kube-system \ eks.amazonaws.com/role-arn=arn:aws:iam::<ACCOUNT_ID>:role/<AmazonEKSClusterAutoscalerRole>
  3. Patchen Sie die Bereitstellung, um die cluster-autoscaler.kubernetes.io/safe-to-evict-Annotation zu den Cluster Autoscaler-Pods mit dem folgenden Befehl hinzuzufügen.

    kubectl patch deployment cluster-autoscaler \ -n kube-system \ -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'
  4. Bearbeiten Sie die Cluster Autoscaler-Bereitstellung mit dem folgenden Befehl.

    kubectl -n kube-system edit deployment.apps/cluster-autoscaler

    Bearbeiten Sie den cluster-autoscaler-Containerbefehl, um <YOUR CLUSTER NAME> (einschließlich <>) durch den Namen Ihres Clusters zu ersetzen, und fügen Sie die folgenden Optionen hinzu.

    • --balance-similar-node-groups

    • --skip-nodes-with-system-pods=false

    spec: containers: - command: - ./cluster-autoscaler - --v=4 - --stderrthreshold=info - --cloud-provider=aws - --skip-nodes-with-local-storage=false - --expander=least-waste - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME> - --balance-similar-node-groups - --skip-nodes-with-system-pods=false

    Speichern und schließen Sie die Datei, um die Änderungen zu übernehmen.

  5. Öffnen Sie die Seite Cluster-Autoscaler-Veröffentlichungen in einem Webbrowser und suchen Sie die neuste Cluster-Autoscaler-Version, die der Haupt- und Nebenversion Ihres Kubernetes-Clusters entspricht. Wenn beispielsweise die Kubernetes-Version Ihres Clusters 1.21 lautet, suchen Sie die neueste Cluster-Autoscaler-Version, die mit 1.21 beginnt. Notieren Sie sich die semantische Versionsnummer (1.21.n) für diese Version, die Sie im nächsten Schritt benötigen.

  6. Legen Sie das Cluster Autoscaler-Abbild-Tag mit dem folgenden Befehl auf die Version fest, die Sie im vorherigen Schritt notiert haben. Ersetzen Sie 1.21.n durch Ihren eigenen Wert.

    kubectl set image deployment cluster-autoscaler \ -n kube-system \ cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v<1.21.n>

Anzeigen Ihrer Cluster Autoscaler-Protokolle

Nachdem Sie den Cluster Autoscaler bereitgestellt haben, können Sie die Protokolle anzeigen und überprüfen, ob die Cluster-Last überwacht wird.

Zeigen Sie Ihre Cluster Autoscaler-Protokolle mit dem folgenden Befehl an.

kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

Die Ausgabe sieht wie folgt aus:

I0926 23:15:55.165842 1 static_autoscaler.go:138] Starting main loop I0926 23:15:55.166279 1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loop I0926 23:15:55.166293 1 static_autoscaler.go:294] Filtering out schedulables I0926 23:15:55.166330 1 static_autoscaler.go:311] No schedulable pods I0926 23:15:55.166338 1 static_autoscaler.go:319] No unschedulable pods I0926 23:15:55.166345 1 static_autoscaler.go:366] Calculating unneeded nodes I0926 23:15:55.166357 1 utils.go:552] Skipping ip-192-168-3-111.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166365 1 utils.go:552] Skipping ip-192-168-71-83.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166373 1 utils.go:552] Skipping ip-192-168-60-191.<region-code>.compute.internal - node group min size reached I0926 23:15:55.166435 1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ... I0926 23:15:55.166458 1 static_autoscaler.go:403] Starting scale down I0926 23:15:55.166488 1 scale_down.go:706] No candidates for scale down

Überlegungen zur Bereitstellung

Lesen Sie die folgenden Überlegungen, um Ihre Cluster-Autoscaler-Bereitstellung zu optimieren.

Überlegungen zur Skalierung

Der Cluster Autoscaler kann so konfiguriert werden, dass er beliebige zusätzliche Funktionen Ihrer Knoten enthält. Diese Funktionen können Amazon-EBS-Volumes umfassen, die mit Knoten verbunden sind, Amazon-EC2-Instance-Typen von Knoten oder GPU-Beschleuniger.

Bereichsknotengruppen in mehr als einer Availability Zone anwenden

Wir empfehlen, dass Sie mehrere Knotengruppen konfigurieren, jede Gruppe einer einzelnen Availability Zone zuordnen und die --balance-similar-node-groups-Funktion aktivieren. Wenn Sie nur eine Knotengruppe erstellen, legen Sie fest, dass diese Knotengruppe mehr als eine Availability Zone umfasst.

Optimieren Sie Ihre Knotengruppen

Der Cluster Autoscaler trifft Annahmen darüber, wie Sie Knotengruppen verwenden. Dazu gehört auch, welche Instance-Typen Sie innerhalb einer Gruppe verwenden. Um diese Annahmen zu erfüllen, konfigurieren Sie Ihre Knotengruppe basierend auf diesen Überlegungen und Empfehlungen:

  • Jeder Knoten in einer Knotengruppe muss identische Planungseigenschaften aufweisen. Dazu gehören Markierungen, Taints und Ressourcen.

    • Für MixedInstancePolicies müssen die Instanztypen kompatible CPU-, Arbeitsspeicher- und GPU-Spezifikationen aufweisen.

    • Der erste in der Richtlinie angegebene Instance-Typ simuliert die Planung.

    • Wenn Ihre Richtlinie zusätzliche Instance-Typen mit mehr Ressourcen enthält, können Ressourcen nach der horizontalen Skalierung verschwendet werden.

    • Wenn Ihre Richtlinie zusätzliche Instance-Typen mit weniger Ressourcen als die ursprünglichen Instance-Typen enthält, können Pods möglicherweise nicht auf den Instances geplant werden.

  • Konfigurieren Sie eine kleinere Anzahl von Knotengruppen mit einer größeren Anzahl von Knoten, da die entgegengesetzte Konfiguration die Skalierbarkeit beeinträchtigen kann.

  • Verwenden Sie Amazon-EC2-Funktionen, wenn beide Systeme sie unterstützen (z. B. Regionen und MixedInstancePolicy.)

Wenn möglich, empfehlen wir Ihnen, Verwaltete Knotengruppen zu verwenden. Verwaltete Knotengruppen verfügen über leistungsstarke Verwaltungsfunktionen. Dazu gehören Funktionen für Cluster Autoscaler wie die automatische Amazon-EC2-Auto-Scaling-Gruppenerkennung und die ordnungsgemäße Knotenbeendigung.

Verwenden Sie EBS-Volumes als persistenten Speicher

Persistenter Speicher ist für die Erstellung zustandsorientierter Anwendungen wie Datenbanken und verteilte Caches von entscheidender Bedeutung. Mit Amazon-EBS-Volumes können Sie zustandsbehaftete Anwendungen auf Kubernetes erstellen. Sie sind jedoch darauf beschränkt, sie nur innerhalb einer einzigen Availability Zone zu erstellen. Weitere Informationen finden Sie unter Wie verwende ich persistenten Speicher in Amazon EKS?. Ziehen Sie für eine bessere Lösung in Betracht, zustandsbehaftete Anwendungen zu erstellen, die auf mehr als eine Availability Zone verteilt sind, indem ein separates Amazon-EBS-Volume für jede Availability Zone verwendet wird. Dadurch kann Ihre Anwendung hochverfügbar sein. Darüber hinaus kann der Cluster Autoscaler die Skalierung der Amazon-EC2-Auto-Scaling-Gruppen ausgleichen. Stellen Sie dazu sicher, dass die folgenden Bedingungen erfüllt sind:

  • Der Knotengruppenausgleich wird durch Setzen von balance-similar-node-groups=true aktiviert.

  • Ihre Knotengruppen werden mit identischen Einstellungen konfiguriert (außer wenn sie sich in mehr als einer Availability Zone befinden und unterschiedliche Amazon-EBS-Volumes verwenden).

Mitplanung

Verteilte Trainingsjobs für Machine Learning profitieren erheblich von der minimierten Latenz von Knotenkonfigurationen in derselben Zone. Diese Workloads stellen mehrere Pods in einer bestimmten Zone bereit. Sie können dies erreichen, indem Sie die Pod-Affinität für alle gemeinsam geplanten Pods oder die Knotenaffinität mit topologyKey: topology.kubernetes.io/zone festlegen. Mit dieser Konfiguration skaliert der Cluster Autoscaler eine bestimmte Zone hoch, um den Anforderungen zu entsprechen. Weisen Sie mehrere Amazon-EC2-Auto-Scaling-Gruppen zu, eine für jede Availability Zone, um ein Failover für den gesamten gemeinsam geplanten Workload zu ermöglichen. Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Der Knotengruppenausgleich wird durch Setzen von balance-similar-node-groups=true aktiviert.

  • Knotenaffinität, Pod-Präemption oder beides werden verwendet, wenn Cluster sowohl regionale als auch zonale Knotengruppen enthalten.

    • Verwenden Sie Knotenaffinität, um regionale Pods zu erzwingen oder zu fördern und zonale Knotengruppen zu vermeiden.

    • Planen Sie keine zonalen Pods für regionale Knotengruppen. Dies kann zu einer unausgeglichenen Kapazität Ihrer Regional-Pods führen.

    • Konfigurieren Sie die Pod-Präemption, wenn Ihre zonalen Workloads Unterbrechungen und Verlagerungen tolerieren können. Dies erzwingt eine Präemption und eine Neuplanung in einer weniger umkämpften Zone für Ihre regional skalierten Pods.

Accelerator und GPUs

Einige Cluster verwenden spezielle Hardware-Accelerator wie eine dedizierte GPU. Beim Hochskalieren kann es mehrere Minuten dauern, bis der Beschleuniger die Ressource dem Cluster ankündigt. Während dieser Zeit simuliert der Cluster Autoscaler, dass dieser Knoten über den Accelerator verfügt. Bis der Accelerator jedoch bereit ist und die verfügbaren Ressourcen des Knotens aktualisiert, können ausstehende Pods nicht auf dem Knoten geplant werden. Dies kann zu wiederholtem unnötigem Aufskalieren führen.

Knoten mit Beschleunigern und hoher CPU- oder Arbeitsspeicherauslastung werden beim Herunterskalieren nicht berücksichtigt, selbst wenn der Accelerator nicht verwendet wird. Dies kann jedoch zu unnötigen Kosten führen. Um diese Kosten zu vermeiden, kann der Cluster Autoscaler spezielle Regeln anwenden, um Knoten für das Herunterskalieren zu berücksichtigen, wenn diese über unbelegte Accelerators verfügen.

Um in diesen Fällen das richtige Verhalten sicherzustellen, konfigurieren Sie das kubelet auf Ihren Accelerator-Knoten, um den Knoten zu kennzeichnen, bevor er dem Cluster beitritt. Der Cluster Autoscaler verwendet diesen Etikett-Selektor, um das vom Accelerator optimierte Verhalten aufzurufen. Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Das kubelet für GPU-Knoten ist mit --node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE konfiguriert.

  • Knoten mit Accelerators halten sich an die Regel für identische Planungseigenschaftsregeln.

Skalierung von Null

Cluster Autoscaling kann Knotengruppen auf Null und von Null skalieren. Dies kann zu erheblichen Kosteneinsparungen führen. Der Cluster Autoscaler erkennt die CPU-, Arbeitsspeicher- und GPU-Ressourcen einer Auto Scaling-Gruppe, indem er das InstanceType untersucht, das in seinem LaunchConfiguration oder LaunchTemplate angegeben ist. Einige Pods erfordern zusätzliche Ressourcen wie WindowsENI oder PrivateIPv4Address. Oder sie benötigen möglicherweise spezifische NodeSelectors oder Taints. Diese beiden letzteren können nicht von der LaunchConfiguration entdeckt werden. Der Cluster Autoscaler kann diese Faktoren jedoch berücksichtigen, indem er sie anhand der folgenden Tags in der Auto-Scaling-Gruppe erkennt.

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME Value: 5 Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY Value: $LABEL_VALUE Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY Value: NoSchedule
Anmerkung
  • Bei einer Skalierung auf Null wird Ihre Kapazität an Amazon EC2 zurückgegeben und kann in Zukunft nicht mehr verfügbar sein.

  • Sie können describeNodegroup verwenden, um Probleme mit verwalteten Knotengruppen bei der Skalierung auf und von Null zu diagnostizieren.

Zusätzliche Konfigurationsparameter

Es gibt viele Konfigurationsoptionen, mit denen das Verhalten und die Leistung des Cluster Autoscaler optimiert werden können. Eine vollständige Liste der Parameter finden Sie unter Was sind die Parameter für CA? auf GitHub.

Performanceaspekte

Es gibt einige wichtige Elemente, die Sie ändern können, um die Leistung und Skalierbarkeit des Cluster Autoscaler zu optimieren. Die Primären sind alle Ressourcen, die dem Prozess bereitgestellt werden, das Scanintervall des Algorithmus und die Anzahl der Knotengruppen im Cluster. Es gibt jedoch auch mehrere andere Faktoren, die an der wahren Laufzeitkomplexität dieses Algorithmus beteiligt sind. Dazu gehören die Komplexität des Planungs-Plug-ins und die Anzahl der Pods. Diese werden als nicht konfigurierbare Parameter betrachtet, da sie integraler Bestandteil des Workloads des Clusters sind und nicht einfach optimiert werden können.

Skalierbarkeit bezieht sich auf die Leistung des Cluster Autoscaler, wenn die Anzahl der Pods und Knoten in Ihrem Kubernetes-Cluster zunimmt. Wenn seine Skalierbarkeitskontingente erreicht werden, verschlechtert sich die Leistung und Funktionalität des Cluster Autoscaler. Darüber hinaus kann der Cluster Autoscaler keine Knoten mehr in Ihrem Cluster hinzufügen oder entfernen, wenn er seine Skalierbarkeitskontingente überschreitet.

Leistung bezieht sich darauf, wie schnell der Cluster Autoscaler Skalierungsentscheidungen treffen und implementieren kann. Ein perfekt funktionierender Cluster Autoscaler trifft sofort Entscheidungen und ruft Skalierungsaktionen als Reaktion auf bestimmte Bedingungen auf, z. B. wenn ein Pod nicht planbar wird.

Machen Sie sich mit der Laufzeitkomplexität des Auto-Scaling-Algorithmus vertraut. Dadurch wird es einfacher, den Cluster Autoscaler so abzustimmen, dass er in großen Clustern (mit mehr als 1.000 Knoten) gut funktioniert.

Der Cluster Autoscaler lädt den Status des gesamten Clusters in den Arbeitsspeicher. Dazu gehören die Pods, Knoten und Knotengruppen. In jedem Scanintervall identifiziert der Algorithmus nicht planbare Pods und simuliert die Planung für jede Knotengruppe. Seien Sie sich bewusst, dass die unterschiedliche Abstimmung dieser Faktoren mit unterschiedlichen Kompromissen verbunden ist.

Vertikales Auto Scaling

Sie können den Cluster Autoscaler auf größere Cluster skalieren, indem Sie die Ressourcenanforderungen für seine Bereitstellung erhöhen. Dies ist eine der einfacheren Methoden, dies zu tun. Erhöhen Sie sowohl den Arbeitsspeicher als auch die CPU für die großen Cluster. Beachten Sie, dass die Höhe des Arbeitsspeichers und der CPU stark von der jeweiligen Clustergröße abhängt. Der Auto-Scaling-Algorithmus speichert alle Pods und Nodes im Arbeitsspeicher. Dies kann in einigen Fällen zu einem Speicherbedarf von mehr als einem Gigabyte führen. Normalerweise müssen Sie die Ressourcen manuell erhöhen. Wenn Sie feststellen, dass Sie häufig Ressourcen manuell erhöhen müssen, sollten Sie den Addon Resizer oder den Vertical Pod Autoscaler verwenden, um den Prozess zu automatisieren.

Reduzierung der Anzahl der Knotengruppen

Sie können die Anzahl der Knotengruppen verringern, um die Leistung des Cluster Autoscaler in großen Clustern zu verbessern. Wenn Sie Ihre Knotengruppen nach einzelnen Teams oder Anwendungen strukturiert haben, kann dies eine Herausforderung darstellen. Obwohl dies von der Kubernetes-API vollständig unterstützt wird, gilt dies als Anti-Pattern für Cluster Autoscaler mit Auswirkungen auf die Skalierbarkeit. Die Verwendung mehrerer Knotengruppen, die beispielsweise sowohl Spot- als auch GPU-Instances verwenden, bietet viele Vorteile. In vielen Fällen gibt es alternative Konstruktionen, die mit wenigen Gruppen den gleichen Effekt erzielen. Stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

  • Isolieren Sie Pods, indem Sie Namespaces anstelle von Knotengruppen verwenden.

    • In mehrmandantenfähigen Clustern mit geringer Vertrauenswürdigkeit ist dies möglicherweise nicht möglich.

    • Legen Sie Pod ResourceRequests und ResourceLimits richtig fest, um Ressourcenkonflikte zu vermeiden.

    • Verwenden Sie größere Instance-Typen für einen optimaleren Behälter und einen geringeren System-Pod-Overhead.

  • Vermeiden Sie die Verwendung von NodeTaints oder NodeSelectors zum Planen von Pods. Verwenden Sie sie nur eingeschränkt.

  • Definieren Sie regionale Ressourcen als eine einzelne Amazon-EC2-Auto-Scaling-Gruppe mit mehr als einer Availability Zone.

Verkürzen des Scanintervalls

Die Verwendung eines niedrigen Scanintervalls, beispielsweise der Standardeinstellung von zehn Sekunden, stellt sicher, dass der Cluster Autoscaler so schnell wie möglich reagiert, wenn Pods nicht planbar sind. Jeder Scan führt jedoch zu vielen API-Aufrufen der Kubernetes API und der Amazon-EC2-Auto-Scaling-Gruppe oder der von Amazon EKS verwalteten Knotengruppen-APIs. Diese API-Aufrufe können zu einer Ratenbegrenzung oder sogar zur Nichtverfügbarkeit von Diensten für Ihre Kubernetes Steuerebene führen.

Das Standardscanintervall beträgt zehn Sekunden, aber bei AWS dauert das Starten eines Knotens erheblich länger, um eine neue Instance zu starten. Dies bedeutet, dass es möglich ist, das Intervall zu erhöhen, ohne die Gesamtzeit für die Hochskalierung zu erhöhen. Wenn es beispielsweise zwei Minuten dauert, einen Knoten zu starten, ändern Sie das Intervall nicht auf eine Minute, da dies zu einem Kompromiss von 6x reduzierten API-Aufrufen für 38 % langsamere Skalierungen führen könnte.

Sharding über Knotengruppen hinweg

Sie können den Cluster Autoscaler so konfigurieren, dass er auf einem bestimmten Satz von Knotengruppen betrieben wird. Mithilfe dieser Funktionalität können Sie mehrere Instances von Cluster Autoscaler bereitstellen. Konfigurieren Sie jede Instance für den Betrieb auf einem anderen Satz von Knotengruppen. Auf diese Weise können Sie eine beliebig große Anzahl von Knotengruppen verwenden und die Kosten für die Skalierbarkeit eintauschen. Wir empfehlen dies jedoch nur als letzten Ausweg, um die Leistung von Cluster Autoscaler zu verbessern.

Diese Konfiguration hat ihre Nachteile. Dies kann zu einer unnötigen Skalierung mehrerer Knotengruppen führen. Die zusätzlichen Knoten werden nach dem scale-down-delay.

metadata: name: cluster-autoscaler namespace: cluster-autoscaler-1 ... --nodes=1:10:k8s-worker-asg-1 --nodes=1:10:k8s-worker-asg-2 --- metadata: name: cluster-autoscaler namespace: cluster-autoscaler-2 ... --nodes=1:10:k8s-worker-asg-3 --nodes=1:10:k8s-worker-asg-4

Stellen Sie sicher, dass die folgenden Bedingungen true sind.

  • Jeder Shard ist so konfiguriert, dass er auf einen eindeutigen Satz von Amazon-EC2-Auto-Scaling-Gruppen verweist.

  • Jeder Shard wird in einem separaten Namespace bereitgestellt, um Konflikte bei der Anführerwahl zu vermeiden.

Kosteneffizienz und Verfügbarkeit

Die primären Optionen zum Optimieren der Kosteneffizienz des Cluster Autoscaler beziehen sich auf die Bereitstellung von Amazon-EC2-Instances. Darüber hinaus muss die Kosteneffizienz mit der Verfügbarkeit abgewogen werden. In diesem Abschnitt werden Strategien beschrieben, z. B. die Verwendung von Spot-Instances zur Kostensenkung und Overprovisioning zur Reduzierung der Latenz beim Erstellen neuer Knoten.

  • Verfügbarkeit – Pods können schnell und ohne Unterbrechung geplant werden. Dies gilt selbst dann, wenn neu erstellte Pods geplant werden müssen und wenn ein herunterskalierter Knoten alle verbleibenden Pods, die für ihn geplant sind, beendet.

  • Kosten – Wird durch die Entscheidung hinter Aufskalierunga- und Abskalierungs-Ereignissen bestimmt. Ressourcen werden verschwendet, wenn ein vorhandener Knoten nicht ausgelastet ist oder ein neuer Knoten hinzugefügt wird, der für eingehende Pods zu groß ist. Je nach Anwendungsfall können Kosten anfallen, die mit der vorzeitigen Beendigung von Pods aufgrund einer aggressiven Entscheidung zum Herunterskalieren verbunden sind.

Spot-Instances

Sie können Spot-Instances in Ihren Knotengruppen verwenden, um bis zu 90 % Rabatt auf den On-Demand-Preis zu sparen. Dies hat den Nachteil, dass Spot-Instances möglicherweise jederzeit unterbrochen werden, wenn Amazon EC2 die Kapazität wieder benötigt. Insufficient Capacity Errors tritt auf, wenn Ihre Amazon-EC2-Auto-Scaling-Gruppe aufgrund eines Mangels an verfügbarer Kapazität nicht hochskaliert werden kann. Die Auswahl vieler verschiedener Instance-Familien hat zwei Hauptnutzen. Erstens kann es Ihre Chance erhöhen, die gewünschte Skalierung zu erreichen, indem Sie viele Spot-Kapazitätspools nutzen. Zweitens kann es auch die Auswirkungen von Spot-Instance-Unterbrechungen auf die Cluster-Verfügbarkeit verringern. Gemischte Instance-Richtlinien mit Spot-Instances sind eine großartige Möglichkeit, die Vielfalt zu erhöhen, ohne die Anzahl der Knotengruppen zu erhöhen. Beachten Sie jedoch, dass Sie On-Demand-Instances anstelle von Spot-Instances verwenden, wenn Sie garantierte Ressourcen benötigen.

Spot-Instances können beendet werden, wenn die Nachfrage nach Instances steigt. Weitere Informationen finden Sie im Abschnitt Spot-Instance-Unterbrechungen im Amazon-EC2-Benutzerhandbuch für Linux-Instances. Das Projekt AWS-Knotenterminierungs-Handler benachrichtigt die Kubernetes-Steuerebene automatisch, wenn ein Knoten ausfällt. Das Projekt verwendet die Kubernetes-API, um den Knoten zu sperren, um sicherzustellen, dass dort keine neue Arbeit geplant ist, und entleert ihn dann und entfernt alle vorhandenen Arbeiten.

Es ist wichtig, dass alle Instance-Typen eine ähnliche Ressourcenkapazität aufweisen, wenn Sie Richtlinien für gemischte Instances konfigurieren. Der Planungssimulator des Autoscalings verwendet den ersten Instance-Typ in der Richtlinie für gemischte Instances. Wenn nachfolgende Instance-Typen größer sind, könnten nach einer Hochskalierung Ressourcen verschwendet werden. Wenn die Instances kleiner sind, können Ihre Pods aufgrund unzureichender Kapazität möglicherweise die neuen Instances nicht einplanen. M4-, M5-, M5a,- und M5n-Instances haben beispielsweise alle ähnliche Mengen an CPU und Arbeitsspeicher und sind hervorragende Kandidaten für eine Richtlinie für gemischte Instances. Das Amazon-EC2-Instance-Selector-Tool kann Ihnen dabei helfen, ähnliche Instance-Typen zu identifizieren. Weitere Informationen finden Sie unter Amazon-EC2-Instance-Selector auf GitHub.

Wir empfehlen Ihnen, die Kapazität Ihrer On-Demand- und Spot-Instances in separate Amazon-EC2-Auto-Scaling-Gruppen zu isolieren. Wir empfehlen dies gegenüber der Verwendung einer Basiskapazitätsstrategie, da die Planungseigenschaften von On-Demand- und Spot-Instances unterschiedlich sind. Spot-Instances können jederzeit unterbrochen werden. Wenn Amazon EC2 die Kapazität zurück benötigt, werden präemptive Knoten häufig getarnt, sodass eine explizite Pod-Tolerierung für das präemptive Verhalten erforderlich ist. Dies führt zu unterschiedlichen Planungseigenschaften für die Knoten, daher sollten sie in mehrere Amazon-EC2-Auto-Scaling-Gruppen aufgeteilt werden.

Der Cluster Autoscaler beinhaltet das Konzept von Expandern. Zusammen bieten sie verschiedene Strategien für die Auswahl der zu skalierenden Knotengruppe. Die Strategie --expander=least-waste ist ein guter Allzweckstandard, und wenn Sie mehrere Knotengruppen für die Spot-Instance-Diversifizierung verwenden, wie zuvor beschrieben, könnte dies dazu beitragen, die Knotengruppen weiter zu optimieren, indem die Gruppe skaliert wird, die danach am besten genutzt wird die Skalierungsaktivität.

Priorisieren einer Knotengruppe oder Auto-Scaling-Gruppe

Sie können auch prioritätsbasiertes Autoscaling konfigurieren, indem Sie den Priority-Expander verwenden. --expander=priority ermöglicht Ihrem Cluster, eine Knotengruppe oder Auto-Scaling-Gruppe zu priorisieren, und wenn er aus irgendeinem Grund nicht skalieren kann, wählt er die nächste Knotengruppe in der priorisierten Liste aus. Dies ist in Situationen nützlich, in denen Sie beispielsweise P3-Instance-Typen verwenden möchten, da deren GPU eine optimale Leistung für Ihre Workload bietet, aber als zweite Option können Sie auch P2-Instance-Typen verwenden. Beispiel:

apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-priority-expander namespace: kube-system data: priorities: |- 10: - .*p2-node-group.* 50: - .*p3-node-group.*

Cluster Autoscaler versucht, die Amazon-EC2-Auto-Scaling-Gruppe mit dem Namen p3-node-group hochzuskalieren. Wenn dieser Vorgang innerhalb von --max-node-provision-time nicht erfolgreich ist, wird versucht, eine Amazon EC2 Auto Scaling-Gruppe zu skalieren, die dem Namen p2-node-group entspricht. Dieser Wert beträgt standardmäßig 15 Minuten und kann für eine reaktionsfähigere Knotengruppenauswahl reduziert werden. Wenn der Wert jedoch zu niedrig ist, kann eine unnötige Skalierung auftreten.

Overprovisioning

Der Cluster Autoscaler trägt dazu bei, die Kosten zu minimieren, indem sichergestellt wird, dass Knoten nur bei Bedarf zum Cluster hinzugefügt und entfernt werden, wenn sie nicht verwendet werden. Dies wirkt sich erheblich auf die Bereitstellungslatenz aus, da viele Pods warten müssen, bis ein Knoten hochskaliert wird, bevor sie geplant werden können. Es kann mehrere Minuten dauern, bis Knoten verfügbar sind, was die Pod-Planungslatenz um eine Größenordnung erhöhen kann.

Dies kann durch Overprovisioning gemildert werden, bei dem die Kosten für die Planungslatenz eingetauscht werden. Overprovisioning wird mit temporären Pods mit negativer Priorität implementiert. Diese Pods belegen Platz im Cluster. Wenn neu erstellte Pods nicht planbar sind und eine höhere Priorität haben, werden die temporären Pods vorgezogen, um Platz zu schaffen. Dann werden die temporären Pods nicht planbar, was dazu führt, dass der Cluster Autoscaler neue überprovisionierte Knoten aufskaliert.

Eine Überprovisionierung hat weitere Vorteile. Ohne Überprovisionierung treffen Pods in einem stark ausgelasteten Cluster weniger optimale Planungsentscheidungen mit der preferredDuringSchedulingIgnoredDuringExecution-Regel. Ein häufiger Anwendungsfall hierfür ist das Trennen von Pods für eine hochverfügbare Anwendung über Availability Zones hinweg mithilfe von AntiAffinity. Eine Overprovisioning kann die Wahrscheinlichkeit, dass ein Knoten der gewünschten Zone verfügbar ist, erheblich erhöhen.

Es ist wichtig, eine angemessene Menge an überprovisionierter Kapazität auszuwählen. Eine Möglichkeit, um sicherzustellen, dass Sie einen angemessenen Betrag auswählen, besteht darin, die durchschnittliche Häufigkeit des Hochskalierens durch die Zeitdauer zu dividieren, die zum Hochskalieren eines neuen Knotens benötigt wird. Wenn Sie beispielsweise im Durchschnitt alle 30 Sekunden einen neuen Knoten benötigen und Amazon EC2 30 Sekunden benötigt, um einen neuen Knoten bereitzustellen, stellt ein einzelner Knoten mit Overprovisioning sicher, dass immer ein zusätzlicher Knoten verfügbar ist. Dadurch kann die Planungslatenz um 30 Sekunden auf Kosten einer einzelnen zusätzlichen Amazon-EC2-Instance reduziert werden. Um bessere Planungsentscheidungen für Zonen zu treffen, können Sie die Anzahl der Knoten auch so überbieten, dass sie der Anzahl der Availability Zones in Ihrer Amazon-EC2-Auto-Scaling-Gruppe entspricht. Dadurch wird sichergestellt, dass der Scheduler die beste Zone für eingehende Pods auswählen kann.

Herunterskalierungs-Bereinigung verhindern

Die Bereinigung einiger Workloads ist teuer. Big-Data-Analysen, Machine-Learning-Aufgaben und Testläufer können lange dauern und müssen bei Unterbrechung neu gestartet werden. Der Cluster Autoscaler hilft beim Herunterskalieren jedes Knotens unter dem scale-down-utilization-threshold. Dies unterbricht alle verbleibenden Pods auf dem Knoten. Sie können dies jedoch verhindern, indem Sie sicherstellen, dass Pods, deren Entfernung teuer ist, durch eine vom Cluster Autoscaler erkannte Markierung geschützt werden. Stellen Sie dazu sicher, dass Pods, deren Bereinigung teuer ist, die Markierung cluster-autoscaler.kubernetes.io/safe-to-evict=false haben.