Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen

Von Amazon EKS verwaltete Knotengruppen automatisieren die Bereitstellung und das Lebenszyklusmanagement von Knoten ( EC2 Amazon-Instances) für Amazon EKS Kubernetes-Cluster.

Mit Amazon EKS-verwalteten Knotengruppen müssen Sie die EC2 Amazon-Instances, die Rechenkapazität für die Ausführung Ihrer Kubernetes-Anwendungen bereitstellen, nicht separat bereitstellen oder registrieren. Sie können Knoten für Ihren Cluster mit einem einzigen Vorgang erstellen, aktualisieren oder beenden. Knotenaktualisierungen und -beendigungen entleeren Knoten automatisch, um sicherzustellen, dass Ihre Anwendungen verfügbar bleiben.

Jeder verwaltete Knoten wird als Teil einer Amazon EC2 Auto Scaling Scaling-Gruppe bereitgestellt, die von Amazon EKS für Sie verwaltet wird. Jede Ressource, einschließlich der Instances und Auto Scaling Scaling-Gruppen, wird in Ihrem AWS Konto ausgeführt. Jede Knotengruppe wird in mehreren Availability Zones ausgeführt, die Sie definieren.

Verwaltete Knotengruppen können optional auch die automatische Knotenreparatur nutzen, die den Zustand der Knoten kontinuierlich überwacht. Sie reagiert automatisch auf erkannte Probleme und ersetzt Knoten, wenn möglich. Dies unterstützt die Gesamtverfügbarkeit des Clusters mit minimalen manuellen Eingriffen. Weitere Informationen finden Sie unter Aktivieren der automatischen Knotenreparatur und Untersuchen von Problemen mit dem Zustand des Knotens.

Sie können mithilfe der Amazon EKS-Konsole, AWS CLI, eksctl AWS API oder Infrastruktur als Code-Tools eine verwaltete Knotengruppe zu neuen oder vorhandenen Clustern hinzufügen, einschließlich AWS CloudFormation. Knoten, die als Teil einer verwalteten Knotengruppe gestartet werden, werden vom Kubernetes Cluster Autoscaler automatisch für die automatische Erkennung mit Tags versehen. Sie können die Knotengruppe verwenden, um Kubernetes-Labels auf Knoten anzuwenden und sie jederzeit zu aktualisieren.

Für die Nutzung von Amazon EKS-verwalteten Knotengruppen fallen keine zusätzlichen Kosten an. Sie zahlen nur für die AWS Ressourcen, die Sie bereitstellen. Dazu gehören EC2 Amazon-Instances, Amazon EBS-Volumes, Amazon EKS-Cluster-Stunden und jede andere AWS Infrastruktur. Es fallen keine Mindestgebühren oder Vorauszahlungen an.

Weitere Informationen zu den ersten Schritten mit einem neuen Amazon-EKS-Cluster und einer verwalteten Knotengruppe finden Sie unter Erste Schritte mit Amazon EKS — AWS-Managementkonsole und AWS CLI.

Informationen zum Hinzufügen einer verwalteten Knotengruppe zu einem bestehenden Cluster finden Sie unter Eine verwaltete Knotengruppe für Ihren Cluster erstellen.

Konzepte für verwaltete Knotengruppen

• Von Amazon EKS verwaltete Knotengruppen erstellen und verwalten EC2 Amazon-Instances für Sie.

• Jeder verwaltete Knoten wird als Teil einer Amazon EC2 Auto Scaling Scaling-Gruppe bereitgestellt, die von Amazon EKS für Sie verwaltet wird. Darüber hinaus werden alle Ressourcen, einschließlich EC2 Amazon-Instances und Auto Scaling Scaling-Gruppen, in Ihrem AWS Konto ausgeführt.

• Die Auto-Scaling-Gruppe einer verwalteten Knotengruppe umfasst alle Subnetze, die Sie beim Erstellen der Gruppe angeben.

• Amazon EKS kennzeichnet verwaltete Knotengruppenressourcen, sodass sie für die Verwendung des Kubernetes Cluster Autoscaler konfiguriert sind.

  Wichtig

  Wenn Sie eine zustandsbehaftete Anwendung über mehrere Availability Zones hinweg ausführen, die von Amazon-EBS-Volumes gesichert wird und den Kubernetes Cluster Autoscaler verwendet, sollten Sie mehrere Knotengruppen konfigurieren, die jeweils für eine einzelne Availability Zone gelten. Außerdem sollten Sie das --balance-similar-node-groups-Feature aktivieren.

• Sie können eine benutzerdefinierte Startvorlage für ein höheres Maß an Flexibilität und Anpassung bei der Bereitstellung verwalteter Knoten verwenden. Zum Beispiel können Sie zusätzliche kubelet-Argumente angeben und ein benutzerdefiniertes AMI verwenden. Weitere Informationen finden Sie unter Verwaltete Knoten mit Startvorlagen anpassen. Wenn Sie beim ersten Erstellen einer verwalteten Knotengruppe keine benutzerdefinierte Startvorlage verwenden, gibt es eine automatisch generierte Startvorlage. Ändern Sie diese automatisch generierte Vorlage nicht manuell sonst treten Fehler auf.

• Amazon EKS folgt dem Modell der gemeinsamen Verantwortung für CVEs und Sicherheitspatches auf verwalteten Knotengruppen. Wenn verwaltete Knoten ein für Amazon EKS optimiertes AMI ausführen, ist Amazon EKS für die Erstellung von Patch-Versionen des AMI verantwortlich, wenn Fehler oder Probleme gemeldet werden. Wir können eine Korrektur veröffentlichen. Sie sind jedoch dafür verantwortlich, diese Patch-AMI-Versionen für Ihre verwalteten Knotengruppen bereitzustellen. Wenn verwaltete Knoten ein benutzerdefiniertes AMI ausführen, sind Sie für die Erstellung von Patch-Versionen des AMI verantwortlich, wenn Fehler oder Probleme gemeldet werden, und für die anschließende Bereitstellung des AMI. Weitere Informationen finden Sie unter Eine verwaltete Knotengruppe für Ihren Cluster aktualisieren.

• Von Amazon EKS verwaltete Knotengruppen können sowohl in öffentlichen als auch privaten Subnetzen gestartet werden. Wenn Sie eine verwaltete Knotengruppe am oder nach dem 22. April 2020 in einem öffentlichen Subnetz starten, muss MapPublicIpOnLaunch für das Subnetz auf „Wahr“ gesetzt sein, damit die Instances einem Cluster hinzugefügt werden können. Wenn das öffentliche Subnetz am eksctl oder nach dem 26. März 2020 mithilfe der von Amazon EKS bereitgestellten AWS CloudFormation Vorlagen erstellt wurde, ist diese Einstellung bereits auf true gesetzt. Wenn die öffentlichen Subnetze vor dem 26. März 2020 erstellt wurden, müssen Sie die Einstellung manuell ändern. Weitere Informationen finden Sie unter Ändern des Attributs für die öffentliche IPv4 Adressierung für Ihr Subnetz.

• Wenn Sie eine verwaltete Knotengruppe in privaten Subnetzen bereitstellen, müssen Sie sicherstellen, dass diese auf Amazon ECR zugreifen kann, um Container-Images abzurufen. Sie können dies tun, indem Sie ein NAT-Gateway mit der Routing-Tabelle des Subnetzes verbinden oder indem Sie die folgenden AWS PrivateLink -VPC-Endpunkte hinzufügen:

  • Amazon-ECR-API-Endpunktschnittstelle – com.amazonaws.region-code.ecr.api

  • API-Endpunktschnittstelle der Amazon-ECR-Docker-Registrierung – com.amazonaws.region-code.ecr.dkr

  • Amazon-S3-Gateway-Endpunkt – com.amazonaws.region-code.s3

  Weitere häufig verwendete Services und Endpunkte finden Sie unter Bereitstellung privater Cluster mit eingeschränktem Internetzugang.

• Verwaltete Knotengruppen können nicht in AWS Outposts oder in AWS Wavelength bereitgestellt werden. Verwaltete Knotengruppen können AWS Local Zones erstellt werden. Weitere Informationen finden Sie unter Starten Sie EKS-Cluster mit geringer Latenz in AWS Local Zones..

• Sie können mehrere verwaltete Knotengruppen innerhalb eines einzelnen Clusters erstellen. So können Sie beispielsweise eine Knotengruppe mit dem standardmäßig für Amazon EKS optimierten Amazon Linux AMI für einige Workloads und eine andere mit der GPU-Variante für Workloads erstellen, die GPU-Unterstützung erfordern.

• Wenn Ihre verwaltete Knotengruppe auf einen Fehler bei der Überprüfung des EC2 Amazon-Instance-Status stößt, gibt Amazon EKS einen Fehlercode zurück, der Ihnen bei der Diagnose des Problems hilft. Weitere Informationen finden Sie unter Fehlercodes bei verwalteten Knotengruppen.

• Amazon EKS fügt Kubernetes-Labels zu verwalteten Knotengruppen-Instances hinzu. Diese von Amazon EKS bereitgestellten Labels sind mit dem Präfix eks.amazonaws.com versehen.

• Amazon EKS leert Knoten automatisch mit der Kubernetes-API während Beendigungs- oder Aktualisierungsvorgängen.

• Die Budgets für Pod-Unterbrechung werden nicht eingehalten, wenn ein Knoten mit AZRebalance beendet oder die Anzahl der gewünschten Knoten reduziert wird. Diese Aktionen versuchen, Pods auf dem Knoten zu entfernen. Wenn dies jedoch länger als 15 Minuten dauert, wird der Knoten beendet, unabhängig davon, ob alle Pods auf dem Knoten beendet sind. Um den Zeitraum bis zum Beenden des Knotens zu verlängern, fügen Sie der Auto-Scaling-Gruppe einen Lebenszyklus-Hook hinzu. Weitere Informationen finden Sie unter Hinzufügen von Lifecycle-Hooks im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.

• Damit der Draining-Prozess nach Erhalt einer Benachrichtigung über eine Spot-Unterbrechung oder eine Kapazitätsumverteilung korrekt ausgeführt werden kann, muss CapacityRebalance auf true eingestellt sein.

• Aktualisierungen verwalteter Knotengruppen respektieren die Budgets für Pod-Unterbrechung, die Sie für Ihre Pods festgelegt haben. Weitere Informationen finden Sie unter Alle Phasen der Knotenaktualisierung verstehen.

• Für die Verwendung verwalteter Amazon-EKS-Knotengruppen fallen keine zusätzlichen Kosten an. Sie zahlen nur für die AWS Ressourcen, die Sie bereitstellen.

• Wenn Sie Amazon-EBS-Volumes für Ihre Knoten verschlüsseln möchten, können Sie die Knoten mithilfe einer Startvorlage bereitstellen. Um verwaltete Knoten mit verschlüsselten Amazon-EBS-Volumes ohne Verwendung einer Startvorlage bereitzustellen, verschlüsseln Sie alle neuen Amazon-EBS-Volumes, die in Ihrem Konto erstellt wurden. Weitere Informationen finden Sie unter Standardverschlüsselung im EC2 Amazon-Benutzerhandbuch.

Kapazitätstypen für verwaltete Knotengruppen

Beim Erstellen einer verwalteten Knotengruppe können Sie entweder den Kapazitätstyp On-Demand oder Spot-Kapazität auswählen. Amazon EKS stellt eine verwaltete Knotengruppe mit einer Amazon EC2 Auto Scaling Scaling-Gruppe bereit, die entweder nur On-Demand-Instances oder nur Amazon EC2 Spot-Instances enthält. Sie können Pods für Fehlertoleranz-Anwendungen für verwaltete Spot-Knotengruppen und fehlerintolerante Anwendungen für On-Demand-Knotengruppen in einem einzelnen Kubernetes-Cluster planen. Standardmäßig stellt eine verwaltete Knotengruppe EC2 On-Demand-Amazon-Instances bereit.

On-Demand

Mit On-Demand-Instances zahlen Sie für Rechenkapazität bis zur zweiten Stunde ohne langfristige Verpflichtungen.

Standardmäßig: Wenn Sie keinen Capacity Type festlegen, wird die verwaltete Knotengruppe mit On-Demand-Instances bereitgestellt. Eine verwaltete Knotengruppe konfiguriert in Ihrem Namen eine Amazon EC2 Auto Scaling Scaling-Gruppe, wobei die folgenden Einstellungen angewendet werden:

• Die Allokationsstrategie zur Bereitstellung von On-Demand-Kapazität ist auf prioritized eingestellt. Verwaltete Knotengruppen verwenden die Reihenfolge der in der API übergebenen Instance-Typen, um zu bestimmen, welcher Instance-Typ bei der Erfüllung der On-Demand-Kapazität zuerst verwendet werden soll. Sie können beispielsweise drei Instance-Typen in der folgenden Reihenfolge angeben: c5.large, c4.large, und c3.large. Wenn Ihre On-Demand-Instances gestartet werden, erfüllt die verwaltete Knotengruppe On-Demand-Kapazität beginnend mit c5.large, dann c4.large, und dann c3.large. Weitere Informationen finden Sie unter Amazon EC2 Auto Scaling Scaling-Gruppe im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.

• Amazon EKS fügt allen Knoten in Ihrer verwalteten Knotengruppe die folgende Kubernetes-Bezeichnung hinzu, die den Kapazitätstyp angibt: eks.amazonaws.com/capacityType: ON_DEMAND. Sie können dieses Label verwenden, um statusbehaftete oder fehlerintolerante Anwendungen auf On-Demand-Knoten zu planen.

Spot-Instances

Amazon EC2 Spot-Instances sind freie EC2 Amazon-Kapazitäten, die erhebliche Rabatte gegenüber den On-Demand-Preisen bieten. Amazon EC2 Spot-Instances können mit einer zweiminütigen Unterbrechungsbenachrichtigung unterbrochen werden, wenn die Kapazität wieder EC2 benötigt wird. Weitere Informationen finden Sie unter Spot-Instances im EC2 Amazon-Benutzerhandbuch. Sie können eine verwaltete Knotengruppe mit Amazon EC2 Spot-Instances konfigurieren, um die Kosten für die Rechenknoten zu optimieren, die in Ihrem Amazon EKS-Cluster ausgeführt werden.

Um Spot-Instances in einer verwalteten Knotengruppe zu verwenden, müssen Sie eine verwaltete Knotengruppe erstellen, indem Sie den Kapazitätstyp als spot einstellen. Eine verwaltete Knotengruppe konfiguriert in Ihrem Namen eine Amazon EC2 Auto Scaling Scaling-Gruppe, wobei die folgenden bewährten Spot-Methoden angewendet werden:

• Um sicherzustellen, dass Ihre Spot-Knoten in den optimalen Spot-Kapazitätspools bereitgestellt werden, ist die Zuweisungsstrategie auf eine der folgenden Optionen eingestellt:

  • price-capacity-optimized (PCO) – Beim Erstellen neuer Knotengruppen in einem Cluster mit Kubernetes-Version 1.28 oder höher ist die Zuweisungsstrategie auf price-capacity-optimized eingestellt. Allerdings wird die Zuweisungsstrategie für Knotengruppen nicht geändert, die bereits mit capacity-optimized erstellt wurden, bevor von Amazon EKS verwaltete Knotengruppen PCO unterstützt hatten.

  • capacity-optimized (CO) – Beim Erstellen neuer Knotengruppen in einem Cluster mit Kubernetes-Version 1.27 oder niedriger ist die Zuweisungsstrategie auf capacity-optimized eingestellt.

  Um die Anzahl der Spot-Kapazitätspools zu erhöhen, die für die Zuweisung von Kapazität verfügbar sind, konfigurieren Sie eine verwaltete Knotengruppe für die Verwendung mehrerer Instance-Typen.

• Amazon EC2 Spot Capacity Rebalancing ist aktiviert, sodass Amazon EKS Ihre Spot-Knoten problemlos entleeren und neu verteilen kann, um Anwendungsunterbrechungen zu minimieren, wenn ein Spot-Knoten einem erhöhten Unterbrechungsrisiko ausgesetzt ist. Weitere Informationen finden Sie unter Amazon EC2 Auto Scaling Capacity Rebalancing im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.

  • Wenn ein Spot-Knoten eine Neuausgleichsempfehlung erhält, versucht Amazon EKS automatisch, einen neuen Ersatz-Spot-Knoten zu starten.

  • Wenn ein Spot-Unterbrechungsnachweis in zwei Minuten eintrifft, bevor sich der Ersatz-Spot-Knoten in einemReady, beginnt Amazon EKS mit dem Entleeren des Spot-Knotens, der die Neuausgleichsempfehlung erhalten hat. Amazon EKS entleert den Knoten nach bestem Wissen. Daher gibt es keine Garantie dafür, dass Amazon EKS wartet, bis der Ersatzknoten dem Cluster beitritt, bevor der vorhandene Knoten entleert wird.

  • Wenn ein Ersatz-Spot-Knoten gestartet wird und in dem Ready Zustand auf Kubernetes ist, sperrt Amazon EKS den Spot-Knoten, der die Neuausgleichs-Empfehlung erhalten hat, und entleert ihn. Durch das Cordoning des Spot-Knotens wird sichergestellt, dass der Service-Controller keine neuen Anforderungen an diesen Spot-Knoten sendet. Es entfernt sie auch aus der Liste der gesunden, aktiven Spot-Knoten. Durch das Entleeren des Spot-Knotens wird sichergestellt, dass ausgeführte Pods reibungslos entsorgt werden.

• Amazon EKS fügt allen Knoten in Ihrer verwalteten Knotengruppe die folgende Kubernetes-Bezeichnung hinzu, die den Kapazitätstyp angibt: eks.amazonaws.com/capacityType: SPOT. Sie können dieses Label verwenden, um fehlertolerante Anwendungen auf Spot-Knoten zu planen.

  Wichtig

  EC2 gibt zwei Minuten vor dem Beenden Ihrer Spot-Instance eine Benachrichtigung zur Spot-Unterbrechung aus. Pods auf Spot-Knoten erhalten jedoch möglicherweise nicht das volle 2-minütige Zeitfenster für ein ordnungsgemäßes Herunterfahren. Wenn Amazon EC2 EKS die Benachrichtigung ausgibt, gibt es eine Verzögerung, bis Amazon EKS mit der Räumung von Pods beginnt. Räumungen erfolgen sequenziell, um den Kubernetes-API-Server zu schützen. Bei mehreren gleichzeitigen Spot-Rückforderungen kann es also vorkommen, dass einige Pods verspätete Räumungsbenachrichtigungen erhalten. Pods können ohne Empfang von Kündigungssignalen gewaltsam beendet werden, insbesondere auf Knoten mit hoher Pod-Dichte, bei gleichzeitigen Rückforderungen oder bei Verwendung langer Kündigungsfristen. Für Spot-Workloads empfehlen wir, Anwendungen unterbrechungstolerant zu gestalten, Übergangsfristen von 30 Sekunden oder weniger zu verwenden, lang andauernde PreStop-Hooks zu vermeiden und die Pod-Räumungsmetriken zu überwachen, um die tatsächlichen Kulanzfristen in Ihren Clustern zu ermitteln. Für Workloads, die eine garantierte ordentliche Kündigung erfordern, empfehlen wir, stattdessen On-Demand-Kapazität zu verwenden.

Bei der Entscheidung, ob eine Knotengruppe mit On-Demand- oder Spot-Kapazität bereitgestellt werden soll, sollten Sie die folgenden Bedingungen berücksichtigen:

• Spot-Instances eignen sich gut für zustandslose, fehlertolerante, flexible Anwendungen. Dazu gehören Workloads für Batch- und Machine-Learning-Schulungen, Big Data ETLs wie Apache Spark, Anwendungen zur Verarbeitung von Warteschlangen und statusfreie API-Endpunkte. Da es sich bei Spot um freie EC2 Amazon-Kapazität handelt, die sich im Laufe der Zeit ändern kann, empfehlen wir, Spot-Kapazität für unterbrechungstolerante Workloads zu verwenden. Insbesondere eignet sich die Spot-Kapazität für Workloads, die Zeiten tolerieren können, in denen die erforderliche Kapazität nicht verfügbar ist.

• Es wird empfohlen, On-Demand für Anwendungen zu verwenden, die fehlerintolerant sind. Dazu gehören Cluster-Verwaltungs-Tools wie Überwachungs- und Betriebstools, Bereitstellungen, die StatefulSets erfordern, und zustandsbehaftete Anwendungen wie Datenbanken.

• Um die Verfügbarkeit Ihrer Anwendungen bei der Verwendung von Spot-Instances zu maximieren, wird empfohlen, eine verwaltete Spot-Knotengruppe für die Verwendung mehrerer Instance-Typen zu konfigurieren. Es wird empfohlen, die folgenden Regeln anzuwenden, wenn mehrere Instance-Typen verwendet werden:

  • Wenn Sie innerhalb einer verwalteten Knotengruppe den Cluster Autoscaler verwenden, wird empfohlen, einen flexiblen Satz von Instance-Typen mit der gleichen Menge an vCPU und Arbeitsspeicherressourcen zu verwenden. Dies soll sicherstellen, dass die Knoten in Ihrem Cluster wie erwartet skalieren. Wenn Sie beispielsweise vier V CPUs - und acht GiB Arbeitsspeicher benötigen, verwenden Siec3.xlarge,c4.xlarge,c5.xlarge,c5d.xlarge, c5a.xlargec5n.xlarge, oder andere ähnliche Instance-Typen.

  • Um die Anwendungsverfügbarkeit zu verbessern, empfehlen wir Ihnen, mehrere Spot-verwaltete Knotengruppen bereitzustellen. Dafür sollte jede Gruppe einen flexiblen Satz von Instance-Typen verwenden, die über die gleichen vCPU- und Speicherressourcen verfügen. Wenn Sie beispielsweise 4 V CPUs und 8 GiB Arbeitsspeicher benötigen, empfehlen wir Ihnen, eine verwaltete Knotengruppe mitc3.xlarge,,,c4.xlarge, c5.xlarge c5d.xlarge c5a.xlargec5n.xlarge, oder anderen ähnlichen Instanztypen und eine zweite verwaltete Knotengruppe mitm3.xlarge,,,m4.xlarge, m5.xlarge m5d.xlargem5a.xlarge, m5n.xlarge oder anderen ähnlichen Instanztypen zu erstellen.

  • Wenn Sie Ihre Knotengruppe mit dem Spot-Kapazitätstyp bereitstellen, der eine benutzerdefinierte Startvorlage verwendet, verwenden Sie die API, um mehrere Instance-Typen zu übergeben. Übergeben Sie keinen einzelnen Instance-Typ durch die Startvorlage. Weitere Informationen zum Bereitstellen einer Knotengruppe mithilfe einer Startvorlage finden Sie unterVerwaltete Knoten mit Startvorlagen anpassenaus.