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.

Cluster Autoscaler

-Übersicht

Der Kubernetes Cluster Autoscaler ist eine beliebte Cluster-Autoscaling-Lösung, die von SIG Autoscaling betrieben wird. https://github.com/kubernetes/community/tree/master/sig-autoscaling Er ist dafür verantwortlich, dass Ihr Cluster über genügend Knoten verfügt, um Ihre Pods zu planen, ohne Ressourcen zu verschwenden. Es achtet auf Pods, die den Zeitplan nicht einhalten, und auf 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 in Cluster Autoscaler steuert das .DesiredReplicas Feld Ihrer EC2 Auto Scaling-Gruppen.

Dieser Leitfaden bietet ein mentales Modell für die Konfiguration des Cluster Autoscalers und die Auswahl der besten Kompromisse, um die Anforderungen Ihres Unternehmens zu erfüllen. Es gibt zwar keine beste Konfiguration, aber es gibt eine Reihe von Konfigurationsoptionen, die es Ihnen ermöglichen, einen Kompromiss zwischen Leistung, Skalierbarkeit, Kosten und Verfügbarkeit einzugehen. 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 unten aufgeführten Definitionen beschränkt.

Skalierbarkeit bezieht sich darauf, wie gut der Cluster Autoscaler funktioniert, wenn die Anzahl der Pods und Knoten in Ihrem Kubernetes-Cluster zunimmt. Wenn die Grenzen der Skalierbarkeit 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 daraus entfernen.

Die Leistung bezieht sich darauf, wie schnell der Cluster Autoscaler in der Lage ist, Skalierungsentscheidungen zu treffen und auszuführen. Ein perfekt funktionierender Cluster Autoscaler würde sofort eine Entscheidung treffen und als Reaktion auf Stimuli, z. B. wenn ein Pod nicht planbar wird, eine Skalierungsaktion auslösen.

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

Die Kosten hängen von der Entscheidung ab, ob Ereignisse horizontal oder intern skaliert werden. 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 kann das vorzeitige Beenden von Pods aufgrund einer aggressiven Scale-Down-Entscheidung mit Kosten verbunden sein.

Node Groups 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 gemeinsame Eigenschaften wie Labels und Taints, können jedoch aus mehreren Availability Zones oder Instanztypen bestehen.

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

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

Betrieb des Cluster Autoscalers

Der Cluster Autoscaler wird normalerweise als Bereitstellung in Ihrem Cluster installiert. Es verwendet die Wahl des Leiters, um eine hohe Verfügbarkeit sicherzustellen, aber die Arbeit wird von einem einzelnen Replikat nach dem anderen erledigt. Es ist nicht horizontal skalierbar. Für grundlegende Setups sollte die Standardeinstellung anhand der mitgelieferten Installationsanweisungen sofort funktionieren, aber es gibt ein paar Dinge, die Sie beachten sollten.

Stellen Sie Folgendes sicher:

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 zu verwenden, indem Sie die Aktionen autoscaling:SetDesiredCapacity autoscaling:TerminateInstanceInAutoScalingGroup 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, selbst wenn das --node-group-auto-discovery Argument nicht mithilfe von Tags (z. B.) auf die Knotengruppen des Clusters beschränkt wurde. 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 der Schlüssel zur Maximierung der Verfügbarkeit und zur Senkung der Kosten für Ihre Workloads. 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 Folgendes sicher:

Optimierung im Hinblick auf Leistung und Skalierbarkeit

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

Die wichtigsten Regler 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. Es gibt noch andere Faktoren, die an der wahren Laufzeitkomplexität dieses Algorithmus beteiligt sind, wie z. B. die Komplexität des Scheduling-Plug-ins und die Anzahl der Pods. Diese Parameter werden als nicht konfigurierbare Parameter betrachtet, da sie für die Arbeitslast des Clusters typisch sind und nicht einfach angepasst werden können.

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

Vertikale Autoskalierung des Cluster-Autoscalers

Die einfachste Methode, den Cluster Autoscaler auf größere Cluster zu skalieren, besteht darin, die Ressourcenanforderungen für seine Bereitstellung zu erhöhen. Bei großen Clustern sollten sowohl der Arbeitsspeicher als auch die CPU 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 eine betriebliche Belastung darstellt, sollten Sie erwägen, den Addon Resizer oder den Vertical Pod Autoscaler zu verwenden.

Reduzierung der Anzahl der Knotengruppen

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

Stellen Sie Folgendes sicher:

Reduzierung 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 EKS Managed Node Group-APIs. Diese API-Aufrufe können zu einer Ratenbegrenzung oder sogar zur Nichtverfügbarkeit von Diensten für Ihre Kubernetes Control Plane führen.

Das Standard-Scanintervall beträgt 10 Sekunden, aber auf AWS dauert das Starten eines Nodes 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 38% langsameren Scale-ups.

Aufteilung zwischen Knotengruppen

Der Cluster Autoscaler kann so konfiguriert werden, dass er mit einer bestimmten Gruppe von Knotengruppen arbeitet. Mit dieser Funktion ist es möglich, mehrere Instanzen des Cluster Autoscalers bereitzustellen, die jeweils für den Betrieb mit einem anderen Satz von Knotengruppen konfiguriert sind. Diese Strategie ermöglicht es Ihnen, eine beliebig große Anzahl von Node-Gruppen zu verwenden, wobei Kosten gegen Skalierbarkeit eingetauscht werden. 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 planbar ist. Dies kann zu einer unnötigen Skalierung mehrerer Knotengruppen führen. Diese zusätzlichen Knoten werden nach dem wieder vergrößertscale-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 Folgendes sicher:

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. Mit dem Nachteil, dass die Spot-Instances jederzeit unterbrochen werden können, wenn EC2 die Kapazität wieder benötigt. Fehler bei unzureichender Kapazität treten auf, wenn Ihre EC2 Auto Scaling-Gruppe aufgrund fehlender verfügbarer Kapazität nicht skaliert werden kann. Wenn Sie die Vielfalt durch die Auswahl vieler Instance-Familien maximieren, 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 Ihre 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. Denken Sie daran, dass Sie On-Demand Instances anstelle von Spot-Instances verwenden sollten, wenn Sie garantierte Ressourcen benötigen.

Bei der Konfiguration von Richtlinien für gemischte Instances 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 Instanztypen größer sind, können nach einer Skalierung Ressourcen verschwendet werden. Bei kleineren Instanzen können Ihre Pods aufgrund unzureichender Kapazität möglicherweise nicht den Zeitplan für die neuen Instances einhalten. Zum Beispiel haben M4-, M5-, M5a- und M5n-Instances alle eine ähnliche Menge an CPU und Arbeitsspeicher und eignen sich hervorragend für eine. MixedInstancePolicy Das EC2 Instance Selector-Tool kann Ihnen helfen, ähnliche Instance-Typen zu identifizieren.

Es wird empfohlen, die Kapazität in separate EC2 Auto Scaling-Gruppen zu isolieren On-Demand und zu verorten. Dies wird der Verwendung einer Basiskapazitätsstrategie vorgezogen, da sich die Planungseigenschaften grundlegend unterscheiden. Da Spot-Instances jederzeit unterbrochen werden können (wenn EC2 die Kapazität wieder benötigt), belasten Benutzer häufig ihre präemptiven Nodes, sodass eine explizite Pod-Toleranz gegenüber dem Präemptionsverhalten erforderlich ist. Diese Fehler führen zu unterschiedlichen Planungseigenschaften für die Knoten, weshalb sie in mehrere EC2 Auto Scaling-Gruppen aufgeteilt werden sollten.

Der Cluster Autoscaler verfügt über ein Konzept von Expandern, die unterschiedliche Strategien für die Auswahl der zu skalierenden Knotengruppe bieten. Die Strategie --expander=least-waste ist eine gute Standardeinstellung für allgemeine Zwecke. Wenn Sie mehrere Knotengruppen zur Diversifizierung der Spot-Instances verwenden (wie in der Abbildung oben beschrieben), kann sie zur weiteren Kostenoptimierung der Knotengruppen beitragen, indem Sie die Gruppe skalieren, die nach der Skalierung am besten genutzt werden kann.

Priorisierung einer Knotengruppe/ASG

Sie können die prioritätsbasierte automatische Skalierung auch mithilfe des Prioritätserweiterers konfigurieren. --expander=priorityermöglicht Ihrem Cluster die Priorisierung einer Knotengruppe/ASG. Wenn er aus irgendeinem Grund nicht skalieren kann, wählt er die nächste Knotengruppe in der Prioritätsliste 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 Arbeitslast bietet. Als zweite Option können Sie jedoch 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, die dem Namen p3-node-group entspricht, hochzuskalieren. Wenn dieser Vorgang innerhalb nicht erfolgreich ist, wird versucht--max-node-provision-time, 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 reduziert werden, um eine schnellere Auswahl der Knotengruppe zu ermöglichen. Ist der Wert jedoch zu niedrig, kann dies zu unnötigen Scale-Outs führen.

Überbereitstellung

Der Cluster Autoscaler minimiert die Kosten, indem er sicherstellt, dass Knoten dem Cluster nur bei Bedarf hinzugefügt und entfernt werden, wenn sie nicht verwendet werden. Dies wirkt sich erheblich auf die Latenz bei der Bereitstellung aus, da viele Pods gezwungen sind, auf eine Node-Skalierung 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. Das 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, wird den temporären Pods vorgebeugt, um Platz zu schaffen. Die temporären Pods können dann nicht mehr geplant werden, was den Cluster Autoscaler veranlasst, neue Knoten mit überlasteten Ressourcen zu skalieren.

Eine Überversorgung hat auch andere, weniger offensichtliche Vorteile. Ohne Überprovisionierung besteht eine der Nebenwirkungen eines stark ausgelasteten Clusters darin, dass Pods aufgrund 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 mithilfe von mehreren Verfügbarkeitszonen. AntiAffinity Eine Überversorgung kann die Wahrscheinlichkeit, dass ein Knoten der richtigen Zone verfügbar ist, erheblich erhöhen.

Die Höhe der übermäßig bereitgestellten Kapazität ist eine sorgfältige Geschäftsentscheidung für Ihr Unternehmen. Im Kern geht es um einen Kompromiss zwischen Leistung und Kosten. Eine Möglichkeit, diese Entscheidung zu treffen, besteht darin, Ihre durchschnittliche Skalierungshäufigkeit zu ermitteln und sie durch die Zeit zu dividieren, die für das Hochskalieren eines neuen Knotens benötigt wird. Wenn Sie beispielsweise im Durchschnitt alle 30 Sekunden einen neuen Knoten benötigen und EC2 30 Sekunden benötigt, um einen neuen Knoten bereitzustellen, sorgt ein einziger Knoten mit Überversorgung dafür, dass immer ein zusätzlicher Knoten verfügbar ist. Dadurch wird die Latenz bei der Planung um 30 Sekunden reduziert — 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 Verfügbarkeitszonen in Ihrer EC2 Auto Scaling Group entsprechen, zu viel bereitstellen, um sicherzustellen, dass der Scheduler die beste Zone für eingehende Pods auswählen kann.

Verhindern Sie die Räumung nach unten

Die Bereinigung einiger Workloads ist teuer. Big-Data-Analysen, Aufgaben des maschinellen Lernens und Testläufe werden irgendwann abgeschlossen, müssen aber neu gestartet werden, wenn sie unterbrochen werden. Der Cluster Autoscaler versucht, jeden Knoten herunterzuskalieren, der unter den Schwellenwert für die Nutzung herunterskaliert wird, wodurch alle verbleibenden Pods auf dem Knoten unterbrochen werden. Dies kann verhindert werden, indem sichergestellt wird, dass Pods, deren Räumung teuer ist, durch ein Label geschützt sind, das vom Cluster Autoscaler erkannt wird.

Stellen Sie Folgendes sicher:

Fortschrittliche Anwendungsfälle

EBS-Volumes

Persistenter Speicher ist entscheidend für die Erstellung zustandsorientierter Anwendungen wie Datenbanken oder verteilter 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 AZs verteilt werden, wobei für jede AZ ein separates EBS-Volume verwendet wird. Der Cluster Autoscaler kann dann die Skalierung der EC2-Autoscaling-Gruppen ausgleichen.

Stellen Sie Folgendes sicher:

Co-Scheduling

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 Sie die Pod-Affinität für alle gleichzeitig geplanten Pods festlegen oder die Node-Affinität mithilfe von verwenden. 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-Gruppen zuweisen, eine pro Availability Zone, um ein Failover für den gesamten gemeinsam geplanten Workload zu ermöglichen.

Stellen Sie Folgendes sicher:

Accelerators

Einige Cluster nutzen spezielle Hardwarebeschleuniger wie GPUs. Beim Scaling Out kann es mehrere Minuten dauern, bis das Accelerator-Geräte-Plug-In dem Cluster die Ressource bekannt gibt. Der Cluster Autoscaler hat simuliert, dass dieser Knoten über den Beschleuniger verfügen wird. Bis der Beschleuniger jedoch bereit ist und die verfügbaren Ressourcen des Knotens aktualisiert, können keine ausstehenden Pods auf dem Knoten geplant werden. Dies kann zu wiederholtem unnötigem Aufskalieren führen.

Darüber hinaus werden Knoten mit Beschleunigern und hoher CPU- oder Speicherauslastung nicht für eine Downskalierung in Betracht gezogen, selbst wenn der Beschleuniger ungenutzt ist. Dieses Verhalten kann aufgrund der relativen Kosten von Beschleunigern kostspielig sein. Stattdessen kann der Cluster Autoscaler spezielle Regeln anwenden, um Knoten beim Herunterskalieren in Betracht zu ziehen, wenn sie über unbelegte 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 mit einem Label versehen wird, bevor er dem Cluster beitritt. Der Cluster Autoscaler verwendet diesen Label-Selektor, um das beschleunigeroptimierte Verhalten auszulösen.

Stellen Sie Folgendes sicher:

Skalierung von 0 aus

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

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 Cluster Autoscaler-Präsentationen und -Demos. Wenn Sie hier eine Präsentation oder Demo hinzufügen möchten, senden Sie bitte eine Pull-Anfrage.

Referenzen