Cluster Autoscaler

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Übersicht

Der Kubernetes Cluster Autoscaler ist eine beliebte Cluster-Autoscaling-Lösung, die von SIG Autoscaling verwaltet wird. Er ist dafür verantwortlich, dass Ihr Cluster über genügend Knoten verfügt, um Ihre Pods zu planen, ohne Ressourcen zu verschwenden. Es sucht nach Pods, deren Zeitplan nicht eingehalten wird, und nach Knoten, die nicht ausgelastet sind. Anschließend wird das Hinzufügen oder Entfernen von Knoten simuliert, bevor die Änderung auf Ihren Cluster angewendet wird. Die AWS Cloud Provider-Implementierung innerhalb von Cluster Autoscaler steuert das .DesiredReplicas Feld Ihrer EC2 Auto Scaling Scaling-Gruppen.

Dieser Leitfaden bietet ein mentales Modell für die Konfiguration von Cluster Autoscaler und die Auswahl der besten Kompromisse, um die Anforderungen Ihres Unternehmens zu erfüllen. Es gibt zwar keine einzige optimale Konfiguration, aber es gibt eine Reihe von Konfigurationsoptionen, mit denen Sie Kompromisse zwischen Leistung, Skalierbarkeit, Kosten und Verfügbarkeit eingehen können. Darüber hinaus enthält dieser Leitfaden Tipps und bewährte Methoden zur Optimierung Ihrer Konfiguration für AWS.

Glossar

Die folgende Terminologie wird in diesem Dokument häufig verwendet. Diese Begriffe können eine weit gefasste Bedeutung haben, sind jedoch für die Zwecke dieses Dokuments auf die folgenden Definitionen beschränkt.

Skalierbarkeit bezieht sich darauf, wie gut der Cluster Autoscaler funktioniert, wenn die Anzahl der Pods und Knoten Ihres Kubernetes-Clusters zunimmt. Wenn die Skalierbarkeitsgrenzen erreicht werden, verschlechtern sich die Leistung und Funktionalität des Cluster Autoscalers. Wenn der Cluster Autoscaler seine Skalierbarkeitsgrenzen überschreitet, kann er Ihrem Cluster keine Knoten mehr hinzufügen oder entfernen.

Leistung bezieht sich darauf, wie schnell der Cluster Autoscaler Skalierungsentscheidungen treffen und ausführen kann. Ein Cluster-Autoscaler mit perfekter Leistung würde sofort eine Entscheidung treffen und eine Skalierungsaktion als Reaktion auf Stimuli auslösen, z. B. wenn ein Pod nicht mehr planbar ist.

Verfügbarkeit bedeutet, dass Pods schnell und ohne Unterbrechung geplant werden können. Dazu gehört auch, wann neu erstellte Pods geplant werden müssen und wann ein herunterskalierter Knoten alle verbleibenden Pods beendet, die für ihn geplant sind.

Die Kosten hängen von der Entscheidung ab, die hinter der Skalierung und Skalierung von Ereignissen steht. Ressourcen werden verschwendet, wenn ein vorhandener Knoten nicht ausgelastet ist oder ein neuer Knoten hinzugefügt wird, der zu groß für eingehende Pods ist. Je nach Anwendungsfall kann es zu Kosten kommen, wenn Pods aufgrund einer aggressiven Skalierungsentscheidung vorzeitig beendet werden.

Knotengruppen sind ein abstraktes Kubernetes-Konzept für eine Gruppe von Knoten innerhalb eines Clusters. Es ist keine echte Kubernetes-Ressource, sondern existiert als Abstraktion im Cluster Autoscaler, der Cluster-API und anderen Komponenten. Knoten innerhalb einer Knotengruppe haben Eigenschaften wie Labels und Taints gemeinsam, können aber aus mehreren Availability Zones oder Instance-Typen bestehen.

EC2 Auto Scaling Groups können als Implementierung von Node Groups auf verwendet werden EC2. EC2 Auto Scaling Scaling-Gruppen sind so konfiguriert, dass sie Instances starten, die ihren Kubernetes-Clustern automatisch beitreten, und Labels und Taints auf ihre entsprechende Node-Ressource in der Kubernetes-API anwenden.

EC2 Managed Node Groups sind eine weitere Implementierung von Node Groups on. EC2 Sie reduzieren die Komplexität der manuellen Konfiguration von EC2 Autoscaling Scaling Groups und bieten zusätzliche Verwaltungsfunktionen wie ein Upgrade der Knotenversion und eine ordnungsgemäße Knotenbeendigung.

Betrieb des Cluster-Autoscalers

Der Cluster Autoscaler wird normalerweise als Bereitstellung in Ihrem Cluster installiert. Um eine hohe Verfügbarkeit zu gewährleisten, nutzt er die Wahl eines Leaders, aber die Arbeit wird jeweils von einem einzelnen Replikat erledigt. Es ist nicht horizontal skalierbar. Bei Basis-Setups sollte es standardmäßig mit den mitgelieferten Installationsanweisungen sofort einsatzbereit sein, aber es gibt ein paar Dinge zu beachten.

Stellen Sie sicher, dass:

Verwenden Sie den Zugriff mit den geringsten Rechten auf die IAM-Rolle

Wenn Auto Discovery verwendet wird, empfehlen wir dringend, den Zugriff mit den geringsten Rechten autoscaling:TerminateInstanceInAutoScalingGroup zu verwenden, indem Sie Aktionen autoscaling:SetDesiredCapacity auf die Auto Scaling-Gruppen beschränken, die auf den aktuellen Cluster beschränkt sind.

Dadurch wird verhindert, dass ein Cluster-Autoscaler, der in einem Cluster ausgeführt wird, Knotengruppen in einem anderen Cluster ändert, auch wenn das --node-group-auto-discovery Argument nicht mithilfe von Tags auf die Knotengruppen des Clusters beschränkt wurde (z. B.). k8s.io/cluster-autoscaler/<cluster-name>

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

Konfiguration Ihrer Knotengruppen

Effektives Autoscaling beginnt mit der korrekten Konfiguration einer Reihe von Knotengruppen für Ihren Cluster. Die Auswahl der richtigen Gruppe von Knotengruppen ist entscheidend, um die Verfügbarkeit zu maximieren und die Kosten für Ihre Workloads zu senken. AWS implementiert Node Groups mithilfe von EC2 Auto Scaling Groups, die für eine Vielzahl von Anwendungsfällen flexibel sind. Der Cluster Autoscaler geht jedoch von einigen Annahmen über Ihre Node Groups aus. Wenn Sie Ihre EC2 Auto Scaling Group-Konfigurationen mit diesen Annahmen konsistent halten, wird unerwünschtes Verhalten minimiert.

Stellen Sie sicher, dass:

Hinweis: Wir empfehlen die Verwendung von EKS Managed Node Groups. Verwaltete Knotengruppen verfügen über leistungsstarke Verwaltungsfunktionen, darunter Funktionen für Cluster Autoscaler wie automatische EC2 Auto Scaling Scaling-Gruppenerkennung und ordnungsgemäße Knotenbeendigung.

Optimierung im Hinblick auf Leistung und Skalierbarkeit

Wenn Sie die Komplexität der Laufzeit des Autoscaling-Algorithmus verstehen, können Sie den Cluster Autoscaler so optimieren, dass er auch in großen Clustern mit mehr als 1.000 Knoten reibungslos funktioniert.

Die wichtigsten Faktoren für die Optimierung der Skalierbarkeit des Cluster-Autoscalers sind die für den Prozess bereitgestellten Ressourcen, das Scanintervall des Algorithmus und die Anzahl der Knotengruppen im Cluster. Für die tatsächliche Komplexität dieses Algorithmus während der Laufzeit spielen noch weitere Faktoren eine Rolle, wie z. B. die Komplexität des Plug-ins für die Terminplanung und die Anzahl der Pods. Diese Parameter werden als nicht konfigurierbare Parameter betrachtet, da sie von der Arbeitslast des Clusters abhängen und nicht einfach angepasst werden können.

Der Cluster Autoscaler lädt den Status des gesamten Clusters in den Arbeitsspeicher, einschließlich Pods, Knoten und Knotengruppen. Bei jedem Scanintervall identifiziert der Algorithmus Pods, die nicht geplant werden können, und simuliert die Planung für jede Knotengruppe. Die Optimierung dieser Faktoren ist mit verschiedenen Kompromissen verbunden, die für Ihren Anwendungsfall sorgfältig abgewogen werden sollten.

Vertikale automatische Skalierung des Cluster-Autoscalers

Die einfachste Möglichkeit, den Cluster-Autoscaler auf größere Cluster zu skalieren, besteht darin, die Ressourcenanforderungen für seine Bereitstellung zu erhöhen. Sowohl Arbeitsspeicher als auch CPU sollten für große Cluster erhöht werden, obwohl dies je nach Clustergröße erheblich variiert. Der Autoscaling-Algorithmus speichert alle Pods und Knoten im Arbeitsspeicher, was in einigen Fällen zu einem Speicherbedarf von mehr als einem Gigabyte führen kann. Das Erhöhen der Ressourcen erfolgt in der Regel manuell. Wenn Sie feststellen, dass die ständige Optimierung der Ressourcen zu einer Betriebsbelastung führt, sollten Sie die Verwendung von Addon Resizer oder Vertical Pod Autoscaler in Betracht ziehen.

Reduzierung der Anzahl der Knotengruppen

Die Minimierung der Anzahl der Knotengruppen ist eine Möglichkeit, sicherzustellen, dass der Cluster Autoscaler auch in großen Clustern eine gute Leistung erbringt. Dies kann für einige Organisationen, die ihre Knotengruppen pro Team oder pro Anwendung strukturieren, eine Herausforderung darstellen. Dies wird zwar vollständig von der Kubernetes-API unterstützt, es wird jedoch als Cluster-Autoscaler-Anti-Pattern mit Auswirkungen auf die Skalierbarkeit angesehen. Es gibt viele Gründe, mehrere Knotengruppen zu verwenden (z. B. Spot oder GPUs), aber in vielen Fällen gibt es alternative Designs, die bei Verwendung einer kleinen Anzahl von Gruppen den gleichen Effekt erzielen.

Stellen Sie sicher, dass:

Verkürzung des Scanintervalls

Ein niedriges Scanintervall (z. B. 10 Sekunden) stellt sicher, dass der Cluster-Autoscaler so schnell wie möglich reagiert, wenn Pods nicht mehr planbar sind. Jeder Scan führt jedoch zu vielen API-Aufrufen an die Kubernetes-API und die EC2 Auto Scaling Group oder die EKS Managed Node Group. APIs Diese API-Aufrufe können zu einer Ratenbegrenzung oder sogar zur Nichtverfügbarkeit des Dienstes für Ihre Kubernetes Control Plane führen.

Das Standard-Scan-Intervall beträgt 10 Sekunden, aber auf 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 2 Minuten dauert, einen Knoten zu starten, führt eine Änderung des Intervalls auf 1 Minute zu einem Kompromiss zwischen 6-fach reduzierten API-Aufrufen und einer um 38% langsameren Skalierung.

Sharding zwischen Knotengruppen

Der Cluster Autoscaler kann so konfiguriert werden, dass er auf einer bestimmten Gruppe von Knotengruppen ausgeführt wird. Mithilfe dieser Funktionalität ist es möglich, mehrere Instanzen des Cluster Autoscaler bereitzustellen, von denen jede für den Betrieb auf einem anderen Satz von Knotengruppen konfiguriert ist. Mit dieser Strategie können Sie eine beliebig große Anzahl von Knotengruppen verwenden und dabei Kosten gegen Skalierbarkeit eintauschen. Wir empfehlen, dies nur als letzten Ausweg zur Leistungsverbesserung zu verwenden.

Der Cluster Autoscaler wurde ursprünglich nicht für diese Konfiguration entwickelt, daher gibt es einige Nebenwirkungen. Da die Shards nicht miteinander kommunizieren, ist es möglich, dass mehrere Autoscaler versuchen, einen Pod zu planen, der nicht geplant werden kann. Dies kann zu einer unnötigen Skalierung mehrerer Knotengruppen führen. Diese zusätzlichen Knoten werden nach dem wieder skaliertscale-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:

Optimierung im Hinblick auf Kosten und Verfügbarkeit

Spot Instances

Sie können Spot-Instances in Ihren Knotengruppen verwenden und bis zu 90% gegenüber dem On-Demand-Preis sparen. Im Gegenzug können Spot-Instances jederzeit unterbrochen werden, wenn die Kapazität wieder EC2 aufgebraucht wird. Fehler mit unzureichender Kapazität treten auf, wenn Ihre EC2 Auto Scaling Scaling-Gruppe aufgrund mangelnder verfügbarer Kapazität nicht hochskalieren kann. Wenn Sie die Vielfalt maximieren, indem Sie viele Instance-Familien auswählen, können Sie Ihre Chance erhöhen, die gewünschte Skalierung zu erreichen, indem Sie viele Spot-Kapazitätspools nutzen, und die Auswirkungen von Spot-Instance-Unterbrechungen auf die Verfügbarkeit Ihres Clusters 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. Denken Sie daran, dass Sie On-Demand-Instances anstelle von Spot-Instances verwenden sollten, wenn Sie garantierte Ressourcen benötigen.

Bei der Konfiguration gemischter Instance-Richtlinien ist es wichtig, dass alle Instance-Typen über eine ähnliche Ressourcenkapazität verfügen. Der Scheduling-Simulator des Autoscalers verwendet den ersten InstanceType in der. MixedInstancePolicy Wenn nachfolgende Instance-Typen größer sind, können Ressourcen nach einer Skalierung verschwendet werden. Wenn sie kleiner sind, können Ihre Pods aufgrund unzureichender Kapazität möglicherweise nicht im Zeitplan für die neuen Instances eingesetzt werden. Beispielsweise verfügen M4-, M5-, M5a- und M5n-Instances alle über eine ähnliche Menge an CPU und Arbeitsspeicher und eignen sich hervorragend für eine. MixedInstancePolicy Das EC2 Instance Selector-Tool kann Ihnen dabei helfen, ähnliche Instance-Typen zu identifizieren.

Es wird empfohlen, On-Demand- und Spot-Kapazitäten in separate EC2 Auto Scaling Scaling-Gruppen zu isolieren. Dies wird der Verwendung einer Basiskapazitätsstrategie vorgezogen, da sich die Scheduling-Eigenschaften grundlegend unterscheiden. Da Spot-Instances jederzeit unterbrochen werden können (wenn die Kapazität wieder EC2 benötigt wird), belasten Benutzer häufig ihre präemptiven Knoten, was eine ausdrückliche Pod-Tolerierung des Preemption-Verhaltens erfordert. Diese Fehler führen zu unterschiedlichen Scheduling-Eigenschaften für die Knoten, weshalb sie in mehrere EC2 Auto Scaling Scaling-Gruppen aufgeteilt werden sollten.

Der Cluster Autoscaler basiert auf einem Konzept von Expandern, die unterschiedliche Strategien für die Auswahl der zu skalierenden Knotengruppe bieten. Diese Strategie --expander=least-waste ist eine gute Standardstrategie für allgemeine Zwecke. Wenn Sie mehrere Knotengruppen für die Diversifizierung von Spot-Instances verwenden möchten (wie in der Abbildung oben beschrieben), kann sie zur weiteren Kostenoptimierung der Knotengruppen beitragen, indem die Gruppe skaliert wird, die nach der Skalierung am besten genutzt werden kann.

Priorisierung einer Knotengruppe//ASG

Sie können die prioritätsbasierte automatische Skalierung auch mithilfe des Priority Expanders konfigurieren. --expander=priorityermöglicht es Ihrem Cluster, einer Knotengruppe /ASG Priorität einzuräumen. Wenn er aus irgendeinem Grund nicht skalieren kann, wählt er die nächste Knotengruppe in der Prioritätenliste aus. Dies ist nützlich in Situationen, in denen Sie beispielsweise P3-Instance-Typen verwenden möchten, da deren GPU eine optimale Leistung für Ihren Workload bietet. Als zweite Option können Sie aber auch P2-Instance-Typen verwenden.

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 EC2 Auto Scaling-Gruppe entsprechend dem Namen p3-node-group zu skalieren. Wenn dieser Vorgang innerhalb nicht erfolgreich ist--max-node-provision-time, wird versucht, eine EC2 Auto Scaling-Gruppe zu skalieren, die dem Namen p2-node-group entspricht. Dieser Wert ist standardmäßig auf 15 Minuten voreingestellt und kann für eine reaktionsschnellere Knotengruppenauswahl reduziert werden. Wenn der Wert jedoch zu niedrig ist, kann dies zu unnötigen Skalierungen führen.

Überbereitstellung

Der Cluster Autoscaler minimiert die Kosten, indem er sicherstellt, dass Knoten dem Cluster nur hinzugefügt werden, wenn sie benötigt werden, und entfernt werden, wenn sie nicht verwendet werden. Dies wirkt sich erheblich auf die Bereitstellungslatenz aus, da viele Pods gezwungen sein werden, auf die Skalierung eines Knotens zu warten, 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 mithilfe temporärer Pods mit negativer Priorität implementiert, die Speicherplatz im Cluster belegen. Wenn neu erstellte Pods nicht planbar sind und eine höhere Priorität haben, werden die temporären Pods gesperrt, um Platz zu schaffen. Die temporären Pods können dann nicht mehr geplant werden, was den Cluster Autoscaler veranlasst, neue Knoten mit überdimensionierter Kapazität zu skalieren.

Überprovisionierung bietet weitere, weniger offensichtliche Vorteile. Ohne Überprovisionierung besteht einer der Nebeneffekte eines stark ausgelasteten Clusters darin, dass Pods mithilfe der preferredDuringSchedulingIgnoredDuringExecution Regel der Pod- oder Node-Affinität weniger optimale Planungsentscheidungen treffen. Ein häufiger Anwendungsfall hierfür ist die Trennung von Pods für eine hochverfügbare Anwendung über mehrere Verfügbarkeitszonen hinweg mithilfe von. AntiAffinity Eine Überprovisionierung kann die Wahrscheinlichkeit, dass ein Knoten der richtigen Zone verfügbar ist, erheblich erhöhen.

Die Höhe der überbereitgestellten Kapazität ist eine sorgfältige Geschäftsentscheidung für Ihr Unternehmen. Im Kern handelt es sich um einen Kompromiss zwischen Leistung und Kosten. Eine Möglichkeit, diese Entscheidung zu treffen, besteht darin, Ihre durchschnittliche Skalierungshäufigkeit zu ermitteln und diese durch die Zeit zu dividieren, die für die Skalierung eines neuen Knotens benötigt wird. Wenn Sie beispielsweise im Durchschnitt alle 30 Sekunden einen neuen Knoten benötigen und die Bereitstellung eines neuen Knotens 30 Sekunden in EC2 Anspruch nimmt, sorgt ein einziger Overprovisioning-Node dafür, dass immer ein zusätzlicher Knoten verfügbar ist, wodurch die Planungslatenz um 30 Sekunden reduziert wird — auf Kosten einer einzigen zusätzlichen EC2 Instance. Um die Entscheidungen zur zonalen Planung zu verbessern, sollten Sie eine Anzahl von Knoten, die der Anzahl der Availability Zones in Ihrer EC2 Auto Scaling Scaling-Gruppe entspricht, zu viel bereitstellen, um sicherzustellen, dass der Scheduler die beste Zone für eingehende Pods auswählen kann.

Vermeiden Sie die Räumung von Scale Down

Die Bereinigung einiger Workloads ist teuer. Big-Data-Analysen, Aufgaben für maschinelles Lernen und Testläufe werden irgendwann abgeschlossen, müssen aber neu gestartet werden, wenn sie unterbrochen werden. Der Cluster Autoscaler versucht, jeden Knoten unter dem herunterzuskalieren scale-down-utilization-threshold, wodurch alle verbleibenden Pods auf dem Knoten unterbrochen werden. Dies kann verhindert werden, indem sichergestellt wird, dass Pods, deren Entfernung teuer ist, durch ein Etikett geschützt werden, das vom Cluster Autoscaler erkannt wird.

Stellen Sie sicher, dass:

Fortschrittliche Anwendungsfälle

EBS-Datenträger

Persistenter Speicher ist entscheidend für die Erstellung von zustandsbehafteten Anwendungen wie Datenbanken oder verteilten Caches. EBS-Volumes ermöglichen diesen Anwendungsfall auf Kubernetes, sind jedoch auf eine bestimmte Zone beschränkt. Diese Anwendungen können hochverfügbar sein, wenn sie auf mehrere verteilt werden, wobei für jede AZ ein separates EBS-Volume AZs verwendet wird. Der Cluster Autoscaler kann dann die Skalierung der Autoscaling-Gruppen ausgleichen. EC2

Stellen Sie sicher, dass:

Gemeinsame Terminplanung

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. Dies kann erreicht werden, indem die Pod-Affinität für alle gemeinsam geplanten Pods oder die Verwendung von Node Affinity festgelegt wird. topologyKey: failure-domain.beta.kubernetes.io/zone Der Cluster Autoscaler skaliert dann eine bestimmte Zone entsprechend den Anforderungen. Möglicherweise möchten Sie mehrere EC2 Auto Scaling Scaling-Gruppen zuweisen, eine pro Availability Zone, um ein Failover für die gesamte gemeinsam geplante Arbeitslast zu ermöglichen.

Stellen Sie sicher, dass:

Accelerators

Einige Cluster nutzen spezielle Hardwarebeschleuniger wie GPU. Beim Skalieren kann es mehrere Minuten dauern, bis das Accelerator Device Plug-in die Ressource dem Cluster bekannt gibt. Der Cluster Autoscaler hat simuliert, dass dieser Knoten über den Accelerator verfügen wird, aber solange der Accelerator nicht bereit ist und die verfügbaren Ressourcen des Knotens aktualisiert, können ausstehende Pods auf dem Knoten nicht geplant werden. Dies kann zu wiederholtem unnötigem Aufskalieren führen.

Darüber hinaus werden Knoten mit Beschleunigern und hoher CPU- oder Speicherauslastung bei der Herunterskalierung nicht berücksichtigt, selbst wenn der Beschleuniger nicht verwendet wird. Dieses Verhalten kann aufgrund der relativ hohen Kosten von Beschleunigern kostspielig sein. Stattdessen kann der Cluster Autoscaler spezielle Regeln anwenden, um Knoten beim Herunterfahren in Betracht zu ziehen, wenn sie über ungenutzte Beschleuniger verfügen.

Um in diesen Fällen das richtige Verhalten sicherzustellen, können Sie das Kubelet auf Ihren Accelerator-Knoten so konfigurieren, dass der Knoten beschriftet wird, bevor er dem Cluster beitritt. Der Cluster Autoscaler verwendet diesen Labelselektor, um das für den Beschleuniger optimierte Verhalten auszulösen.

Stellen Sie sicher, dass:

Skalierung ab 0

Cluster Autoscaler ist in der Lage, Knotengruppen auf und von Null zu skalieren, was zu erheblichen Kosteneinsparungen führen kann. Es erkennt die CPU-, Speicher- und GPU-Ressourcen einer Auto Scaling Scaling-Gruppe, indem es die in seiner LaunchConfiguration oder InstanceType LaunchTemplate angegebenen Werte überprüft. Einige Pods benötigen zusätzliche Ressourcen wie WindowsENI oder oder spezifische PrivateIPv4Address NodeSelectors oder Taints, die anhand von nicht erkannt werden können. LaunchConfiguration Der Cluster Autoscaler kann diese Faktoren berücksichtigen, indem er sie anhand von Tags in der EC2 Auto Scaling Scaling-Gruppe erkennt. Zum Beispiel:

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

Hinweis: Denken Sie daran, dass bei einer Skalierung auf Null Ihre Kapazität wieder auf Null zurückgesetzt wird EC2 und möglicherweise in future nicht mehr verfügbar sein wird.

Zusätzliche Parameter

Es gibt viele Konfigurationsoptionen, mit denen das Verhalten und die Leistung des Cluster Autoscaler optimiert werden können. Eine vollständige Liste der Parameter ist verfügbar unter GitHub.

Weitere Ressourcen

Diese Seite enthält eine Liste der Präsentationen und Demos von Cluster Autoscaler. Wenn Sie hier eine Präsentation oder Demo hinzufügen möchten, senden Sie bitte eine Pull-Anfrage.

Referenzen