|
Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar. |
EKS-Cluster-Konfiguration Referenz
Kontozugriff
Vervollständigen Sie jedes Dropdown-Menü und jedes Feld mit den Informationen, die Sie für Ihre IAM-Richtlinie erhalten haben.
| Einstellung | Beschreibung |
|---|---|
Region |
Wählen Sie aus dem Dropdown-Menü die geografische Region aus, in der Sie Ihren Cluster erstellen möchten. |
Cloud-Anmeldeinformationen |
Wählen Sie die Cloud-Anmeldeinformationen aus, die Sie für Ihre IAM-Richtlinie erstellt haben. Für weitere Informationen zur Erstellung von Cloud-Anmeldeinformationen in Rancher, siehe diese Seite. |
Dienstrolle
Wählen Sie eine Dienstrolle aus.
| Dienstrolle | Beschreibung |
|---|---|
Standard: Von Rancher generierte Dienstrolle |
Wenn Sie diese Rolle wählen, fügt Rancher automatisch eine Dienstrolle zur Verwendung mit dem Cluster hinzu. |
Benutzerdefiniert: Wählen Sie aus Ihren vorhandenen Dienstrollen |
Wenn Sie diese Rolle wählen, lässt Sie Rancher aus Dienstrollen wählen, die Sie bereits in AWS erstellt haben. Für weitere Informationen zur Erstellung einer benutzerdefinierten Dienstrolle in AWS, siehe die Amazon-Dokumentation. |
Verschlüsselung von Geheimnissen
Optional: Um Geheimnisse zu verschlüsseln, wählen Sie einen Schlüssel aus oder geben Sie einen Schlüssel ein, der in AWS Key Management Service (KMS) erstellt wurde.
API-Server-Endpunktzugriff
Die Konfiguration des öffentlichen/privaten API-Zugriffs ist ein fortgeschrittener Anwendungsfall. Für Details siehe die Dokumentation zur Zugriffskontrolle des EKS-Cluster-Endpunkts.
Nur private API-Endpunkte
Wenn Sie den privaten Zugriff aktivieren und den öffentlichen API-Endpunktzugriff beim Erstellen eines Clusters deaktivieren, müssen Sie einen zusätzlichen Schritt unternehmen, damit Rancher erfolgreich mit dem Cluster verbunden werden kann. In diesem Fall wird ein Pop-up angezeigt mit einem Befehl, den Sie im Cluster ausführen, um ihn bei Rancher zu registrieren. Sobald der Cluster bereitgestellt ist, können Sie den angezeigten Befehl überall dort ausführen, wo Sie eine Verbindung zur Kubernetes-API des Clusters herstellen können.
Es gibt zwei Möglichkeiten, diesen zusätzlichen manuellen Schritt zu vermeiden:
-
Sie können den Cluster mit sowohl privatem als auch öffentlichem API-Endpunktzugriff bei der Erstellung des Clusters erstellen. Sie können den öffentlichen Zugriff deaktivieren, nachdem der Cluster erstellt wurde und sich in einem aktiven Zustand befindet, und Rancher wird weiterhin mit dem EKS-Cluster kommunizieren.
-
Sie können sicherstellen, dass Rancher ein Subnetz mit dem EKS-Cluster teilt. Dann können Sicherheitsgruppen verwendet werden, um Rancher die Kommunikation mit dem API-Endpunkt des Clusters zu ermöglichen. In diesem Fall ist der Befehl zur Registrierung des Clusters nicht erforderlich, und Rancher wird in der Lage sein, mit Ihrem Cluster zu kommunizieren. Für weitere Informationen zur Konfiguration von Sicherheitsgruppen siehe die Sicherheitsgruppendokumentation.
Endpunkte für öffentlichen Zugriff
Optional den Zugriff auf den öffentlichen Endpunkt über explizite CIDR-Blöcke einschränken.
Wenn Sie den Zugriff auf bestimmte CIDR-Blöcke einschränken, wird empfohlen, auch den privaten Zugriff zu aktivieren, um den Verlust der Netzwerkkommunikation mit dem Cluster zu vermeiden.
Eines der Folgenden ist erforderlich, um den privaten Zugriff zu aktivieren:
-
Die IP von Rancher muss Teil eines erlaubten CIDR-Blocks sein
-
Der private Zugriff sollte aktiviert sein, und Rancher muss ein Subnetz mit dem Cluster teilen und Netzwerkzugang zum Cluster haben, was mit einer Sicherheitsgruppe konfiguriert werden kann.
Für weitere Informationen über den öffentlichen und privaten Zugriff auf den Clusterendpunkt verweisen Sie auf die Amazon EKS-Dokumentation.
IPv6 / Dual-Stack-Netzwerkbetrieb
Rancher unterstützt die Bereitstellung und Verwaltung von Amazon EKS-Clustern mit IPv6-Netzwerkrouting. Wenn IPv6 aktiviert ist, werden Kubernetes-Pods und -Dienste mit IPv6-Adressen zugewiesen. Die zugrunde liegenden EC2-Worker-Knoten arbeiten jedoch im Dual-Stack-Modus und erhalten sowohl IPv4- als auch IPv6-Adressen. Diese Dual-Stack-Architektur stellt sicher, dass die Knoten weiterhin über IPv4 mit der AWS-API und dem Kubernetes-Kontrollbereich kommunizieren können, während Ihre Anwendungen über IPv6 kommunizieren.
Um einen Dual-Stack-Cluster über die Rancher-Benutzeroberfläche bereitzustellen:
-
Erweitern Sie während der Cluster-Erstellung den Abschnitt Netzwerk.
-
Wählen Sie unter IP-Familie die Optionsschaltfläche IPv6 aus.
Ändern der IP-Familie löscht alle aktuellen Subnetzauswahlen, die Sie im Formular getroffen haben.
-
Wählen Sie unter VPCs und Subnetze entweder Automatisch ein neues VPC und Subnetz erstellen oder Aus bestehenden Subnetzen auswählen aus.
Warnung für benutzerdefinierte VPCsWenn Sie sich entscheiden, vorhandene Subnetze auszuwählen, müssen Sie Dual-Stack-Subnetze auswählen. Die ausgewählten Subnetze müssen sowohl über einen IPv4-CIDR-Block als auch über einen IPv6-CIDR-Block verfügen. Nur-IPv6-Subnetze werden nicht unterstützt.
-
Vervollständigen Sie den Rest der Cluster-Konfiguration (Knotengruppen usw.).
-
Klicken Sie auf Erstellen.
|
Die IP-Familieneinstellung ist unveränderlich. Nachdem ein EKS-Cluster erstellt wurde, können Sie einen IPv4-Cluster nicht in IPv6 umwandeln, noch können Sie einen IPv6-Cluster in IPv4 umwandeln. |
Importieren von vorhandenen IPv6-Clustern
Rancher unterstützt vollständig die Registrierung (Importierung) vorhandener Amazon EKS-Cluster, die außerhalb von Rancher (z. B. über Terraform oder die AWS-Konsole) mit IPv6-Netzwerkkonfiguration konfiguriert wurden.
Wenn Sie einen bestehenden EKS-Cluster registrieren:
-
Befolgen Sie den standardmäßigen Registrierungsprozess für Cluster (Cluster Management > Cluster hinzufügen > Allgemein).
-
Rancher fragt die AWS EKS API ab, um den Upstream-Zustand des Clusters zu lesen.
-
Rancher erkennt automatisch, ob der Cluster mit IPv6 bereitgestellt wurde.
Bei der Konfiguration eines IPv6-Clusters gelten mehrere automatisierte Verhaltensweisen und strenge Anforderungen:
-
Service CIDR: AWS weist automatisch die Service CIDR aus einem festen IPv6-Bereich zu (
fd00::/108). Sie können die Service CIDR für einen IPv6-Cluster nicht anpassen. -
OIDC-Anbieter (IRSA) Anforderung: In einem IPv6-Cluster erfordert das Amazon VPC CNI-Plugin strikt IAM-Berechtigungen, um IPv6-Präfixe an Elastic Network Interfaces (ENIs) zuzuweisen. Diese Authentifizierung erfolgt über IAM-Rollen für Dienstkonten (IRSA). Daher ist ein IAM OIDC-Anbieter obligatorisch und wird automatisch von Rancher aktiviert, wenn ein IPv6-Cluster bereitgestellt wird. Ohne ihn können Pods keine IP-Adressen erhalten.
EKSClusterConfig Referenzbeispiel (IPv6)
Wenn Sie EKS-Cluster programmgesteuert mit der eksclusterconfigs.eks.cattle.io benutzerdefinierten Ressource bereitstellen, können Sie IPv6 aktivieren, indem Sie das ipFamily-Feld auf ipv6 setzen.
Im Folgenden finden Sie ein Beispiel für eine minimale EKSClusterConfig, die für IPv6 konfiguriert ist. Beachten Sie, dass das ipFamily gesetzt ist und standardmäßige IPv4-Felder wie serviceCidr weggelassen werden, da AWS diese automatisch im IPv6-Modus verwaltet.
apiVersion: eks.cattle.io/v1
kind: EKSClusterConfig
metadata:
name: my-ipv6-cluster
namespace: cluster-fleet-default
spec:
amazonCredentialSecret: cattle-global-data/my-aws-credentials
displayName: my-ipv6-cluster
region: us-west-2
imported: false
kubernetesVersion: "1.33"
ipFamily: "ipv6" # Enables Dual-Stack IPv6 networking. Triggers automatic OIDC creation.
nodeGroups:
- nodegroupName: initial-nodegroup
desiredSize: 2
maxSize: 3
minSize: 1
instanceType: t3.medium
diskSize: 20
requestSpotInstances: false
version: "1.33"
privateAccess: false
publicAccess: true
secretsEncryption: false
Teilnetz
| Option | Beschreibung |
|---|---|
Standard: Von Rancher generiertes VPC und Subnetz |
Während der Bereitstellung Ihres Clusters stellt Rancher ein neues VPC mit 3 öffentlichen Subnetzen bereit. |
Benutzerdefiniert: Wählen Sie aus Ihrem vorhandenen VPC und Subnetzen |
Während der Bereitstellung Ihres Clusters stellt Rancher Ihren Control Plane und die Knoten so ein, dass ein VPC und Subnetz verwendet werden, die Sie bereits in AWS erstellt haben. |
Für weitere Informationen konsultieren Sie die AWS-Dokumentation zu Cluster VPC Überlegungen. Befolgen Sie eine der untenstehenden Anleitungen basierend auf Ihrer Auswahl aus dem vorherigen Schritt.
|
Warnung für benutzerdefinierte VPCs
Wenn Sie |
Protokollierung
Konfigurieren Sie die Protokolle des Control Planes, um an Amazon CloudWatch gesendet zu werden. Sie werden mit den standardmäßigen CloudWatch Logs-Datenaufnahme- und Speicherkosten für alle Protokolle belastet, die von Ihren Clustern an CloudWatch Logs gesendet werden.
Jeder Protokolltyp entspricht einer Komponente der Kubernetes-Steuerungsebene. Um mehr über diese Komponenten zu erfahren, siehe Kubernetes-Komponenten in der Kubernetes-Dokumentation.
Für weitere Informationen zur Protokollierung der EKS-Steuerungsebene konsultieren Sie die offizielle Dokumentation.
Verwaltete Knoten-Gruppen
Die verwalteten Knoten-Gruppen von Amazon EKS automatisieren die Bereitstellung und Lebenszyklusverwaltung von Knoten (Amazon EC2-Instanzen) für Amazon EKS Kubernetes-Cluster.
Für weitere Informationen darüber, wie Knoten-Gruppen funktionieren und wie sie konfiguriert werden, siehe die EKS-Dokumentation.
Benutzerdefinierte Startvorlagen
Sie können Ihre eigene ID und Version der Startvorlage angeben, um die EC2-Instanzen in einer Knoten-Gruppe zu konfigurieren. Wenn Sie die Startvorlage bereitstellen, können keine der Vorlageneinstellungen von Rancher konfiguriert werden. Sie müssen alle erforderlichen Optionen, die unten aufgeführt sind, in Ihrer Startvorlage festlegen.
Außerdem können Sie, wenn Sie die Startvorlage bereitstellen, nur die Versionsnummer der Vorlage aktualisieren, nicht die ID der Vorlage. Um eine neue Vorlagen-ID zu verwenden, erstellen Sie eine neue verwaltete Knoten-Gruppe.
| Option | Beschreibung | Erforderlich/optional |
|---|---|---|
Instanztyp |
Wählen Sie die Hardware-Spezifikationen für die Instanz, die Sie bereitstellen. |
required |
Bild-ID |
Geben Sie eine benutzerdefinierte AMI für die Knoten an. Benutzerdefinierte AMIs, die mit EKS verwendet werden, müssen ordnungsgemäß konfiguriert sein |
Optional |
Knotenspeichergröße |
Die Startvorlage muss ein EBS-Volume mit der gewünschten Größe angeben |
required |
SSH-Schlüssel |
Ein Schlüssel, der zu den Instanzen hinzugefügt wird, um SSH-Zugriff auf die Knoten zu ermöglichen |
Optional |
Benutzerdaten |
Cloud-Init-Skript im MIME-Multi-Part-Format |
Optional |
Instanzressourcen-Tags |
Taggen Sie jede EC2-Instanz und ihre Volumes in der Knoten-Gruppe |
Optional |
|
Sie können eine Knoten-Gruppe nicht direkt auf eine neuere Kubernetes-Version aktualisieren, wenn die Knoten-Gruppe aus einer benutzerdefinierten Startvorlage erstellt wurde. Sie müssen eine neue Startvorlage mit der richtigen Kubernetes-Version erstellen und die Knoten-Gruppe mit der neuen Vorlage verknüpfen. |
Von Rancher verwaltete Startvorlagen
Wenn Sie keine Startvorlage angeben, können Sie die oben genannten Optionen in der Rancher-Benutzeroberfläche konfigurieren, und alle können nach der Erstellung aktualisiert werden. Um alle diese Optionen nutzen zu können, wird Rancher eine Startvorlage für Sie erstellen und verwalten. Jeder Cluster in Rancher wird eine von Rancher verwaltete Startvorlage haben, und jede verwaltete Knoten-Gruppe, die keine angegebene Startvorlage hat, wird eine Version der verwalteten Startvorlage haben. Der Name dieser Startvorlage wird das Präfix "rancher-managed-lt-" gefolgt vom Anzeigenamen des Clusters haben. Darüber hinaus wird die von Rancher verwaltete Startvorlage mit dem Schlüssel "rancher-managed-template" und dem Wert "do-not-modify-or-delete" gekennzeichnet, um sie als von Rancher verwaltet zu identifizieren. Es ist wichtig, dass diese Startvorlage und ihre Versionen nicht geändert, gelöscht oder mit anderen Clustern oder verwalteten Knoten-Gruppen verwendet werden. Andernfalls könnte es dazu führen, dass Ihre Knoten-Gruppen "degradiert" werden und zerstört und neu erstellt werden müssen.
Benutzerdefinierte AMIs
Wenn Sie ein benutzerdefiniertes AMI angeben, sei es in einer Startvorlage oder in Rancher, muss das Image ordnungsgemäß konfiguriert sein und Sie müssen Benutzerdaten bereitstellen, um den Knoten neu zu starten. Dies wird als fortgeschrittener Anwendungsfall betrachtet, und das Verständnis der Anforderungen ist unerlässlich.
Wenn Sie eine Startvorlage angeben, die kein benutzerdefiniertes AMI enthält, wird Amazon das EKS-optimierte AMI für die Kubernetes-Version und die ausgewählte Region verwenden. Sie können auch eine GPU-fähige Instanz für Workloads auswählen, die davon profitieren würden.
|
Die Einstellung für GPU-fähige Instanzen in Rancher wird ignoriert, wenn ein benutzerdefiniertes AMI bereitgestellt wird, entweder im Dropdown-Menü oder in einer Startvorlage. |
Spot-Instanzen
Spot-Instanzen werden jetzt von EKS unterstützt. Wenn eine Startvorlage angegeben ist, empfiehlt Amazon, dass die Vorlage keinen Instanztyp angibt. Stattdessen empfiehlt Amazon, mehrere Instanztypen anzugeben. Wenn das Kontrollkästchen "Spot-Instanzen anfordern" für eine Knoten-Gruppe aktiviert ist, haben Sie die Möglichkeit, mehrere Instanztypen anzugeben.
|
Jede Auswahl, die Sie im Dropdown-Menü für den Instanztyp getroffen haben, wird in dieser Situation ignoriert, und Sie müssen mindestens einen Instanztyp im Abschnitt "Spot-Instanztypen" angeben. Darüber hinaus kann eine mit EKS verwendete Startvorlage keine Spot-Instanzen anfordern. Die Anforderung von Spot-Instanzen muss Teil der EKS-Konfiguration sein. |
Einstellungen der Knoten-Gruppe
Die folgenden Einstellungen sind ebenfalls konfigurierbar. Alle diese, mit Ausnahme des "Namen der Knoten-Gruppe", sind nach der Erstellung der Knoten-Gruppe bearbeitbar.
| Option | Beschreibung |
|---|---|
Name der Knoten-Gruppe |
Der Name der Knoten-Gruppe. |
Gewünschte ASG-Größe |
Die gewünschte Anzahl von Instanzen. |
Maximale ASG-Größe |
Die maximale Anzahl von Instanzen. Diese Einstellung tritt erst in Kraft, wenn der Cluster Autoscaler installiert ist. |
Minimale ASG-Größe |
Die minimale Anzahl von Instanzen. Diese Einstellung tritt erst in Kraft, wenn der Cluster Autoscaler installiert ist. |
Labels |
Kubernetes-Labels, die auf die Knoten in der verwalteten Knoten-Gruppe angewendet werden. |
Kennungen |
Dies sind Tags für die verwaltete Knoten-Gruppe und werden nicht auf die zugehörigen Ressourcen übertragen. |
Selbstverwaltete Amazon Linux-Knoten
Sie können einen EKS-Cluster registrieren, der selbstverwaltete Amazon Linux-Knoten enthält. Sie müssen diesen Typ von Cluster gemäß den Anweisungen in der offiziellen AWS-Dokumentation für das Starten selbstverwalteter Amazon Linux-Knoten konfigurieren. EKS-Cluster mit selbstverwalteten Amazon-Linux-Knoten werden normalerweise vom Karpenter-Projekt betrieben. Nachdem Sie einen EKS-Cluster mit selbstverwalteten Amazon-Linux-Knoten bereitgestellt haben, registrieren Sie den Cluster, damit er von Rancher verwaltet werden kann. Die Knoten sind jedoch nicht in der Rancher-Benutzeroberfläche sichtbar.
IAM-Rollen für Dienstkonten
Eine Anwendungsbereitstellung, die auf einem EKS-Cluster läuft, kann über IAM-Berechtigungen Anfragen an AWS-Dienste stellen. Diese Anwendungen müssen ihre Anfragen mit AWS-Anmeldeinformationen signieren. IAM-Rollen für Dienstkonten verwalten diese Anmeldeinformationen über einen AWS OIDC-Endpunkt. Anstatt AWS-Anmeldeinformationen an Container zu verteilen oder sich auf die Rolle einer EC2-Instanz zu verlassen, können Sie eine IAM-Rolle mit einem Kubernetes-Dienstkonto verknüpfen und Ihre Pods so konfigurieren, dass sie dieses Konto verwenden.
|
Die Verknüpfung mit einer IAM-Rolle wird für Rancher-Pods in einem EKS-Cluster nicht unterstützt. |
Um IAM-Rollen für Dienstkonten zu aktivieren:
Konfiguration der Bildwiederholrate
Die eks-refresh-cron-Einstellung ist veraltet. Sie wurde in die eks-refresh-Einstellung migriert, die eine Ganzzahl darstellt, die Sekunden repräsentiert.
Der Standardwert beträgt 300 Sekunden.
Das Synchronisierungsintervall kann durch Ausführen von kubectl edit setting eks-refresh geändert werden.
Wenn die eks-refresh-cron-Einstellung zuvor festgelegt war, erfolgt die Migration automatisch.
Je kürzer die Bildwiederholrate ist, desto unwahrscheinlicher treten Rennbedingungen auf, jedoch erhöht es die Wahrscheinlichkeit, auf Anforderungsgrenzen zu stoßen, die möglicherweise für AWS-APIs gelten.