Hilf mit, diese Seite zu verbessern
Möchten Sie zu diesem Benutzerhandbuch beitragen? Scrollen Sie zum Ende dieser Seite und wählen Sie Diese Seite bearbeiten am aus GitHub. Ihre Beiträge werden dazu beitragen, unser Benutzerhandbuch für alle zu verbessern.
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.
Vereinfachen Sie den Knotenlebenszyklus mit verwalteten Knotengruppen
Von Amazon EKS verwaltete Knotengruppen automatisieren die Bereitstellung und das Lebenszyklusmanagement von Knoten (EC2Amazon-Instances) für EKS Kubernetes Amazon-Cluster.
Bei von 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-Gruppen, wird in Ihrem AWS -Konto ausgeführt. Jede Knotengruppe wird in mehreren Availability Zones ausgeführt, die Sie definieren.
Sie können eine verwaltete Knotengruppe zu neuen oder vorhandenen Clustern hinzufügen, indem Sie die EKS Amazon-Konsole, eksctl
AWS API, AWS CLI; oder Infrastruktur als Codetools verwenden, einschließlich AWS CloudFormation. Knoten, die als Teil einer verwalteten Knotengruppe gestartet werden, werden vom Kubernetes Cluster Autoscaler automatisch für die automatische Erkennung gekennzeichnet. Sie können die Knotengruppe verwenden, um Kubernetes-Labels auf Knoten anzuwenden und sie jederzeit zu aktualisieren.
Für die Nutzung von Amazon EKS Managed Node Groups fallen keine zusätzlichen Kosten an. Sie zahlen nur für die AWS Ressourcen, die Sie bereitstellen. Dazu gehören EC2 Amazon-Instances, EBS Amazon-Volumes, EKS Amazon-Cluster-Stunden und jede andere AWS Infrastruktur. Es fallen keine Mindestgebühren oder Vorauszahlungen an.
Informationen zu den ersten Schritten mit einem neuen EKS Amazon-Cluster und einer neuen verwalteten Knotengruppe finden Sie unterStarten Sie mit Amazon EKS — AWS Management Console und AWS CLI.
Informationen zum Hinzufügen einer verwalteten Knotengruppe zu einem bestehenden Cluster finden Sie unter Erstellen Sie eine verwaltete Knotengruppe für Ihren Cluster.
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 so, dass sie für die Verwendung des Kubernetes Cluster Autoscaler konfiguriert sind.
Wichtig
Wenn Sie eine statusbehaftete Anwendung in mehreren Availability Zones ausführen, die von EBS Amazon-Volumes unterstützt wird, und die verwenden KubernetesSkalieren Sie Cluster-Computing mit Karpenter und Cluster Autoscaler, sollten Sie mehrere Knotengruppen konfigurieren, die jeweils auf eine einzelne Availability Zone beschränkt sind. 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. Sie können beispielsweise zusätzliche
kubelet
Argumente angeben und ein benutzerdefiniertes Argument verwenden. AMI Weitere Informationen finden Sie unter Passen Sie verwaltete Knoten mit Startvorlagen an. 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 auf verwalteten Knoten eine für Amazon EKS optimierte Version ausgeführt wirdAMI, EKS ist Amazon dafür verantwortlich, gepatchte Versionen von zu erstellenAMI, wenn Bugs oder Probleme gemeldet werden. Wir können eine Korrektur veröffentlichen. Sie sind jedoch dafür verantwortlich, diese gepatchten AMI Versionen in Ihren verwalteten Knotengruppen bereitzustellen. Wenn auf verwalteten Knoten ein benutzerdefiniertes System ausgeführt wirdAMI, sind Sie dafür verantwortlich, gepatchte Versionen von zu erstellen, AMI wenn Bugs oder Probleme gemeldet werden, und diese dann bereitzustellen. AMI Weitere Informationen finden Sie unter Aktualisieren Sie eine verwaltete Knotengruppe für Ihren Cluster.
-
Von Amazon EKS verwaltete Knotengruppen können sowohl in öffentlichen als auch in 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 ameksctl
oder nach dem 26. März 2020 mithilfe der von Amazon EKS verkauften 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 öffentlichenIPv4
-Adressierungsattributs für Ihr Subnetz. -
Wenn Sie eine verwaltete Knotengruppe in privaten Subnetzen bereitstellen, müssen Sie sicherstellen, dass sie auf Amazon zugreifen kann, ECR 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:
-
ECRAPIAmazon-Endpunktschnittstelle —
com.amazonaws.
region-code
.ecr.api -
APIEndpunktschnittstelle für die 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 Stellen Sie private Cluster mit eingeschränktem Internetzugang bereit.
-
-
Verwaltete Knotengruppen können nicht in AWS Outposts AWS Wavelength oder in AWS Local Zones bereitgestellt werden.
-
Sie können mehrere verwaltete Knotengruppen innerhalb eines einzelnen Clusters erstellen. Sie können beispielsweise eine Knotengruppe mit dem standardmäßigen, von Amazon EKS optimierten Amazon Linux AMI für einige Workloads und eine weitere mit der GPU Variante für Workloads, die Unterstützung benötigenGPU, erstellen.
-
Wenn Ihre verwaltete Knotengruppe auf einen Fehler bei der Überprüfung des EC2 Amazon-Instance-Status stößt, EKS gibt Amazon 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. Diesen von Amazon EKS bereitgestellten Etiketten wird ein Präfix vorangestellt
eks.amazonaws.com
. -
Amazon EKS entleert Knoten Kubernetes API bei Terminierungen oder Updates automatisch mithilfe von.
-
Die Budgets für Pod-Disruptionen werden nicht eingehalten, wenn ein Knoten mit
AZRebalance
beendet oder die Anzahl der gewünschten Knoten reduziert wird. Bei diesen Aktionen wird versucht, Pods auf dem Knoten zu bereinigen. 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
auftrue
eingestellt sein. -
Aktualisierungen verwalteter Knotengruppen respektieren die Pod-Disruptions-Budgets, die Sie für Ihre Pods festgelegt haben. Weitere Informationen finden Sie unter Verstehen Sie jede Phase der Knotenaktualisierungen.
-
Für die Verwendung von von Amazon EKS verwalteten Knotengruppen fallen keine zusätzlichen Kosten an. Sie zahlen nur für die AWS Ressourcen, die Sie bereitstellen.
-
Wenn Sie EBS Amazon-Volumes für Ihre Knoten verschlüsseln möchten, können Sie die Knoten mithilfe einer Startvorlage bereitstellen. Um verwaltete Knoten mit verschlüsselten EBS Amazon-Volumes bereitzustellen, ohne eine Startvorlage zu verwenden, verschlüsseln Sie alle neuen EBS Amazon-Volumes, die in Ihrem Konto erstellt wurden. Weitere Informationen finden Sie unter Standardverschlüsselung im EC2Amazon-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 fehlertolerante 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.
Funktionsweise
Standardmäßig: Wenn Sie keinen Capacity Type (Kapazitätstyp) 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 bestimmen anhand der Reihenfolge der übergebenen Instance-Typen, welcher Instance-Typ bei der API Bereitstellung von On-Demand-Kapazität zuerst verwendet werden soll. Sie können beispielsweise drei Instance-Typen in der folgenden Reihenfolge angeben:c5.large
,c4.large
, undc3.large
. Wenn Ihre On-Demand-Instances gestartet werden, erfüllt die verwaltete Knotengruppe On-Demand-Kapazität beginnend mitc5.large
, dannc4.large
, und dannc3.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 das folgende Kubernetes Label hinzu, das 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 EC2Amazon-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 EKS Amazon-Cluster ausgeführt werden.
Funktionsweise
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 Version1.28
oder höher ist die Zuweisungsstrategie aufprice-capacity-optimized
eingestellt. Die Zuweisungsstrategie wird jedoch nicht für Knotengruppen geändert, die bereits erstellt wurden,capacity-optimized
bevor die Unterstützung durch Amazon EKS verwaltete Knotengruppen begannPCO. -
capacity-optimized
(CO) – Beim Erstellen neuer Knotengruppen in einem Cluster mit Kubernetes-Version1.27
oder niedriger ist die Zuweisungsstrategie aufcapacity-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 Ihre Spot-Knoten problemlos entleeren und neu verteilen EKS kann, um Anwendungsunterbrechungen zu minimieren, wenn für einen Spot-Knoten ein erhöhtes Ausfallrisiko besteht. Weitere Informationen finden Sie unter Amazon EC2 Auto Scaling Capacity Rebalancing im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.
-
Wenn ein Spot-Node eine Empfehlung zur Neuverteilung erhält, versucht Amazon EKS automatisch, einen neuen Ersatz-Spot-Node zu starten.
-
Wenn eine zweiminütige Spot-Unterbrechungsbenachrichtigung eingeht, bevor sich der Ersatz-Spot-Knoten in einem
Ready
Zustand befindet, EKS beginnt Amazon mit der Entleerung des Spot-Knotens, der die Empfehlung zur Neuverteilung erhalten hat. Amazon EKS entleert den Knoten nach bestem Wissen und Gewissen. Daher gibt es keine Garantie dafür, dass Amazon EKS wartet, bis der Ersatzknoten dem Cluster beitritt, bevor der bestehende Knoten entleert wird. -
Wenn ein Ersatz-Spot-Knoten gebootet wird und sich im eingeschalteten
Ready
Zustand befindetKubernetes, EKS sperrt Amazon den Spot-Knoten ab und entleert ihn, der die Empfehlung zur Neuverteilung erhalten hat. 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 Löschen des Spot-Knotens wird sichergestellt, dass laufende Pods anmutig entfernt werden.
-
-
Amazon EKS fügt allen Knoten in Ihrer verwalteten Knotengruppe das folgende Kubernetes Label hinzu, das den Kapazitätstyp angibt:
eks.amazonaws.com/capacityType: SPOT
. Sie können dieses Label verwenden, um fehlertolerante Anwendungen auf Spot-Knoten zu planen.
Überlegungen zur Auswahl eines Kapazitätstyps
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 EndgeräteAPI. 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, empfehlen wir die Verwendung eines flexiblen Satzes von Instance-Typen mit derselben Menge an V- und Speicherressourcen. CPU Dies soll sicherstellen, dass die Knoten in Ihrem Cluster wie erwartet skalieren. Wenn Sie beispielsweise vier vCPUs und acht GiB Arbeitsspeicher benötigen, verwenden Sie
c3.xlarge
,c4.xlarge
,c5.xlarge
,c5d.xlarge
,c5a.xlarge
c5n.xlarge
, oder andere ähnliche Instance-Typen. -
Um die Anwendungsverfügbarkeit zu verbessern, empfehlen wir Ihnen, mehrere Spot-verwaltete Knotengruppen bereitzustellen. Zu diesem Zweck sollte jede Gruppe einen flexiblen Satz von Instance-Typen verwenden, die über dieselben V CPU - und Speicherressourcen verfügen. Wenn Sie beispielsweise 4 vCPUs und 8 GiB Arbeitsspeicher benötigen, empfehlen wir Ihnen, eine verwaltete Knotengruppe mit
c3.xlarge
,,,c4.xlarge
,c5.xlarge
c5d.xlarge
c5a.xlarge
c5n.xlarge
, oder anderen ähnlichen Instanztypen und eine zweite verwaltete Knotengruppe mitm3.xlarge
,,,m4.xlarge
,m5.xlarge
m5d.xlarge
m5a.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 unterPassen Sie verwaltete Knoten mit Startvorlagen anaus.
-