**Unterstützung für die Verbesserung dieser Seite beitragen** 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. Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link **Diese Seite bearbeiten auf**, der sich im rechten Bereich jeder Seite befindet. 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. # Weitere Informationen zur Funktionsweise von EKS Auto Mode In diesem Kapitel erfahren Sie, wie die Komponenten von Amazon-EKS-Auto-Mode-Clustern funktionieren. **Topics** + [Weitere Informationen zu von Amazon EKS Auto Mode verwalteten Instances](automode-learn-instances.md) + [Weitere Informationen zu Identität und Zugriff in EKS Auto Mode](auto-learn-iam.md) + [Weitere Informationen zu VPC-Netzwerke und Load Balancing in EKS Auto Mode](auto-networking.md) # Weitere Informationen zu von Amazon EKS Auto Mode verwalteten Instances In diesem Thema wird erklärt, wie Amazon EKS Auto Mode EC2 Amazon-Instances in Ihrem EKS-Cluster verwaltet. Wenn Sie den automatischen EKS-Modus aktivieren, werden die Rechenressourcen Ihres Clusters automatisch von EKS bereitgestellt und verwaltet, wodurch sich die Art und Weise ändert, wie Sie mit den EC2 Instances interagieren, die als Knoten in Ihrem Cluster dienen. Das Verständnis der Funktionsweise von Amazon EKS Auto Mode bei der Verwaltung von Instances ist für die Planung Ihrer Workload-Bereitstellungsstrategie und Ihrer Betriebsabläufe von entscheidender Bedeutung. Im Gegensatz zu herkömmlichen EC2 Instanzen oder verwalteten Knotengruppen folgen diese Instanzen einem anderen Lebenszyklusmodell, bei dem EKS die Verantwortung für viele betriebliche Aspekte übernimmt und gleichzeitig bestimmte Zugriffs- und Anpassungsarten einschränkt. Amazon EKS Auto Mode automatisiert Routineaufgaben zur Erstellung neuer EC2 Instances und fügt sie als Knoten an Ihren EKS-Cluster an. Der automatische Modus von EKS erkennt, wenn ein Workload nicht auf bestehende Knoten passt, und erstellt eine neue EC2 Instance. Amazon EKS Auto Mode ist für das Erstellen, Löschen und Patchen von EC2 Instances verantwortlich. Sie sind für die auf der Instance bereitgestellten Container und Pods verantwortlich. EC2 Mit EKS Auto Mode erstellte Instances unterscheiden sich von anderen EC2 Instances, es handelt sich um verwaltete Instances. Diese verwalteten Instances sind Eigentum von EKS und unterliegen strengeren Beschränkungen. Sie können nicht direkt auf von EKS Auto Mode verwaltete Instances zugreifen oder Software darauf installieren. AWS schlägt vor, entweder den EKS Auto Mode oder den selbstverwalteten Karpenter auszuführen. Sie können beide während einer Migration oder in einer erweiterten Konfiguration installieren. Wenn Sie beide installiert haben, konfigurieren Sie Ihre Knoten-Pools so, dass Workloads entweder Karpenter oder EKS Auto Mode zugeordnet sind. Weitere Informationen finden Sie unter Von [Amazon EC2 verwaltete Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) im EC2 Amazon-Benutzerhandbuch. ## Vergleichstabelle | EC2 Standardinstanz | Von EKS Auto Mode verwaltete Instance | | --- | --- | | Sie sind für das Patchen und Aktualisieren der Instance verantwortlich. | AWS patcht und aktualisiert die Instanz automatisch. | | EKS übernimmt keine Verantwortung für die Software auf der Instance. | EKS ist für bestimmte Software auf der Instance verantwortlich, wie `kubelet`, die Container-Laufzeitumgebung und das Betriebssystem. | | Sie können die EC2 Instanz mithilfe der EC2 API löschen. | EKS bestimmt die Anzahl der in Ihrem Konto bereitgestellten Instances. Wenn Sie eine Workload löschen, reduziert EKS die Anzahl der Instances in Ihrem Konto. | | Sie können SSH verwenden, um auf die EC2 Instance zuzugreifen. | Sie können Pods und Container auf der verwalteten Instance bereitstellen. | | Sie bestimmen das Betriebssystem und das Image (AMI). | AWS bestimmt das Betriebssystem und das Image. | | Sie können Workloads bereitstellen, die auf Windows- oder Ubuntu-Funktionalität basieren. | Sie können Container auf Linux-Basis bereitstellen, jedoch ohne spezifische Betriebssystemabhängigkeiten. | | Sie legen fest, welcher Instance-Typ und welche Instance-Familie gestartet werden soll. | AWS bestimmt, welcher Instance-Typ und welche Familie gestartet werden sollen. Sie können einen Knoten-Pool verwenden, um die Instance-Typen einzuschränken, aus denen EKS Auto Mode auswählt. | Die folgende Funktionalität funktioniert sowohl für verwaltete Instances als auch für EC2 Standard-Instances: + Sie können die Instanz in der AWS Konsole anzeigen. + Sie können den Instance-Speicher als flüchtigen Speicher für Workloads verwenden. ### AMI-Support AWS Bestimmt im EKS-Automatikmodus das Image (AMI), das für Ihre Rechenknoten verwendet wird. AWS überwacht die Einführung neuer EKS Auto Mode AMI-Versionen. Wenn Sie Probleme mit der Workload im Zusammenhang mit einer AMI-Version haben, erstellen Sie einen Support-Fall. Weitere Informationen finden Sie unter [Erstellen von Supportfällen und Fallmanagement](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) im AWS Support-Benutzerhandbuch. Im Allgemeinen veröffentlicht EKS jede Woche eine neue AMI, die CVE- und Sicherheitskorrekturen enthält. ## Unterstützte Instance-Referenz für EKS Auto Mode EKS Auto Mode erstellt ausschließlich Instances von unterstützten Typen, die eine Mindestgröße aufweisen. EKS Auto Mode unterstützt die folgenden Instance-Typen: | Familie | Instance-Typen | | --- | --- | | Für Datenverarbeitung optimiert (C ) | c8i, c8i-flex, c8gd, c8gn, c8g, c7a, c7g, c7gn, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 | | Allzweck (M) | m8i, m8i-flex, m8a, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7g, m7i-flex, m6a, m6i, m6in, m6in, m6in, m6idn, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 | | Speicheroptimiert (R ) | r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r7a, r7iz, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5ad, r5n d, r4 | | Mit Spitzenlast (T) | t4g, t3, t3a, t2 | | Hoher Arbeitsspeicher (Z/X) | z1d, x8g, x2gd | | Speicheroptimiert (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn | | P/G/Inf/TrnBeschleunigtes Rechnen () | p5, p4d, p4de, p3, p3dn, gr6, g6, g6e, g5g, g5, g4dn, inf2, inf1, trn1, trn1n | | Hochleistungs-Datenverarbeitung (X2) | x2iezn, x2iedn, x2idn | Darüber hinaus erstellt der automatische Modus von EKS nur EC2 Instanzen, die die folgenden Anforderungen erfüllen: + Mehr als 1 CPU + Die Instance-Größe ist nicht Nano, Mikro oder klein Weitere Informationen finden Sie unter [Benennungskonventionen für EC2 Amazon-Instance-Typen](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html). ## Instance-Metadatenservice + Im automatischen Modus von EKS gilt standardmäßig ein IMDSv2 Hop-Limit von 1, was den bewährten AWS Sicherheitsmethoden entspricht. + Diese Standardkonfiguration kann im Automatikmodus nicht geändert werden. + Geben Sie bei Add-Ons, für die normalerweise IMDS-Zugriff erforderlich ist, während der Installation Parameter (z. B. AWS Region) an, um IMDS-Abfragen zu vermeiden. Weitere Informationen finden Sie unter [Felder für die Anpassung von Amazon-EKS-Add-Ons festlegen](kubernetes-field-management.md). + Wenn ein Pod im Automatikmodus unbedingt IMDS-Zugriff benötigt, muss der Pod für die Ausführung mit `hostNetwork: true` konfiguriert werden. Dadurch kann der Pod direkt auf den Instance-Metadaten-Service zugreifen. + Berücksichtigen Sie die Sicherheitsauswirkungen, wenn Sie Pods Zugriff auf Instance-Metadaten gewähren. Weitere Informationen zum Amazon EC2 Instance Metadata Service (IMDS) finden [Sie unter Konfiguration der Optionen für den Instance-Metadaten-Service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) im * EC2 Amazon-Benutzerhandbuch*. ## Überlegungen + Wenn der konfigurierte flüchtige Speicher in der kleiner NodeClass ist als der NVMe lokale Speicher für die Instance, macht der automatische EKS-Modus eine manuelle Konfiguration überflüssig, indem automatisch die folgenden Aktionen ausgeführt werden: + Verwendet ein kleineres (20 GiB) Amazon-EBS-Daten-Volume, um die Kosten zu senken. + Formatiert und konfiguriert den NVMe lokalen Speicher für die Verwendung kurzlebiger Daten. Dies beinhaltet die Einrichtung eines RAID 0-Arrays, falls mehrere Laufwerke vorhanden sind. NVMe + Wenn `ephemeralStorage.size` die lokale NVMe Kapazität erreicht oder diese überschreitet, werden die folgenden Aktionen ausgeführt: + Automatikmodus überspringt das kleine EBS-Volume. + Die NVMe Laufwerke sind direkt für Ihre Arbeitslast verfügbar. + Der automatische Modus von Amazon EKS unterstützt die folgenden Aktionen des AWS Fault Injection Service nicht: + `ec2:RebootInstances` + `ec2:SendSpotInstanceInterruptions` + `ec2:StartInstances` + `ec2:StopInstances` + `ec2:TerminateInstances` + `ec2:PauseVolumeIO` + Amazon EKS Auto Mode unterstützt EKS-Pod-Aktionen des AWS Fault Injection Service. Weitere Informationen finden Sie unter [Managing Fault Injection Service Experiments](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) und [Use the AWS FIS aws:eks:pod actions](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) im Resilience Hub-Benutzerhandbuch. AWS + Sie brauchen das `Neuron Device Plugin` nicht in EKS-Auto-Mode-Knoten zu installieren. Wenn Sie andere Knotentypen in Ihrem Cluster haben, müssen Sie das Neuron-Geräte-Plugin so konfigurieren, dass es nicht in Knoten im Automatikmodus ausgeführt wird. Weitere Informationen finden Sie unter [Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird](associate-workload.md). # Weitere Informationen zu Identität und Zugriff in EKS Auto Mode In diesem Thema werden die Rollen und Berechtigungen des Identity and Access Management (IAM) beschrieben, die für die Verwendung von EKS Auto Mode erforderlich sind. EKS Auto Mode verwendet zwei primäre IAM-Rollen: eine Cluster-IAM-Rolle und eine Knoten-IAM-Rolle. Diese Rollen arbeiten in Verbindung mit EKS Pod Identity und EKS-Zugriffseinträgen, um eine umfassende Zugriffsverwaltung für Ihre EKS-Cluster zu gewährleisten. Wenn Sie den automatischen EKS-Modus konfigurieren, müssen Sie diese IAM-Rollen mit bestimmten Berechtigungen einrichten, die es AWS Diensten ermöglichen, mit Ihren Clusterressourcen zu interagieren. Dazu gehören Berechtigungen für die Verwaltung von Rechenressourcen, Speicher-Volumes, Load Balancern und Netzwerkkomponenten. Das Verständnis dieser Rollenkonfigurationen ist für den ordnungsgemäßen Betrieb und die Sicherheit des Clusters von entscheidender Bedeutung. Im automatischen EKS-Modus werden AWS IAM-Rollen über EKS-Zugriffseinträge automatisch den Kubernetes-Berechtigungen zugeordnet, sodass keine manuelle Konfiguration oder benutzerdefinierte Bindungen erforderlich sind. `aws-auth` ConfigMaps Wenn Sie einen neuen Auto-Mode-Cluster erstellen, erstellt EKS automatisch die entsprechenden Kubernetes-Berechtigungen mithilfe von Access-Einträgen und stellt so sicher, dass AWS Dienste und Clusterkomponenten sowohl innerhalb des Kubernetes-Autorisierungssystems als auch innerhalb des Kubernetes-Autorisierungssystems über die AWS entsprechenden Zugriffsebenen verfügen. Diese automatisierte Integration reduziert die Komplexität der Konfiguration und trägt dazu bei, Probleme im Zusammenhang mit Berechtigungen zu vermeiden, die bei der Verwaltung von EKS-Clustern häufig auftreten. ## Cluster-IAM-Rolle Die Cluster-IAM-Rolle ist eine AWS Identity and Access Management (IAM) -Rolle, die von Amazon EKS zur Verwaltung von Berechtigungen für Kubernetes-Cluster verwendet wird. Diese Rolle gewährt Amazon EKS die erforderlichen Berechtigungen für die Interaktion mit anderen AWS Services im Namen Ihres Clusters und wird mithilfe von EKS-Zugriffseinträgen automatisch mit Kubernetes-Berechtigungen konfiguriert. + Sie müssen dieser Rolle AWS IAM-Richtlinien zuordnen. + EKS Auto Mode weist dieser Rolle automatisch Kubernetes-Berechtigungen mithilfe von EKS-Zugriffseinträgen zu. + Schlägt AWS vor, im automatischen Modus von EKS eine einzelne Cluster-IAM-Rolle pro AWS Konto zu erstellen. + AWS schlägt vor, diese Rolle `AmazonEKSAutoClusterRole` zu benennen. + Diese Rolle erfordert Berechtigungen für mehrere AWS Dienste zur Verwaltung von Ressourcen, einschließlich EBS-Volumes, Elastic Load Balancers und EC2 Instances. + Die vorgeschlagene Konfiguration für diese Rolle umfasst mehrere AWS verwaltete IAM-Richtlinien, die sich auf die verschiedenen Funktionen von EKS Auto Mode beziehen. + `AmazonEKSComputePolicy` + `AmazonEKSBlockStoragePolicy` + `AmazonEKSLoadBalancingPolicy` + `AmazonEKSNetworkingPolicy` + `AmazonEKSClusterPolicy` Weitere Informationen zur Cluster-IAM-Rolle und den AWS verwalteten IAM-Richtlinien finden Sie unter: + [AWS verwaltete Richtlinien für Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Amazon-EKS-Cluster-IAM-Rolle](cluster-iam-role.md) Weitere Informationen zum Kubernetes-Zugriff finden Sie unter: + [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md) ## Knoten-IAM-Rolle Die Node-IAM-Rolle ist eine AWS Identity and Access Management (IAM) -Rolle, die von Amazon EKS verwendet wird, um Berechtigungen für Worker-Knoten in Kubernetes-Clustern zu verwalten. Diese Rolle gewährt EC2 Instances, die als Kubernetes-Knoten ausgeführt werden, die erforderlichen Berechtigungen für die Interaktion mit AWS Diensten und Ressourcen. Sie wird mithilfe von EKS-Zugriffseinträgen automatisch mit Kubernetes-RBAC-Berechtigungen konfiguriert. + Sie müssen dieser Rolle IAM-Richtlinien zuordnen AWS . + EKS Auto Mode weist dieser Rolle automatisch Kubernetes-RBAC-Berechtigungen zu, indem er EKS-Zugriffseinträge verwendet. + AWS schlägt vor, diese Rolle `AmazonEKSAutoNodeRole` zu benennen. + Schlägt AWS vor, im automatischen Modus von EKS eine einzelne Node-IAM-Rolle pro AWS Konto zu erstellen. + Diese Rolle verfügt über eingeschränkte Berechtigungen. Zu den wichtigsten Berechtigungen gehören das Übernehmen einer Pod-Identity-Rolle und das Abrufen von Images aus ECR. + AWS schlägt die folgenden AWS verwalteten IAM-Richtlinien vor: + `AmazonEKSWorkerNodeMinimalPolicy` + `AmazonEC2ContainerRegistryPullOnly` Weitere Informationen zur Cluster-IAM-Rolle und zu AWS verwalteten IAM-Richtlinien finden Sie unter: + [AWS verwaltete Richtlinien für Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md) + [Amazon-EKS-Knoten-IAM-Rolle](create-node-role.md) Weitere Informationen zum Kubernetes-Zugriff finden Sie unter: + [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md) ## Servicegebundene Rolle Amazon EKS verwendet für bestimmte Vorgänge eine serviceverknüpfte Rolle (SLR). Eine servicegebundene Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon EKS verknüpft ist. Servicebezogene Rollen sind von Amazon EKS vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen. AWS erstellt und konfiguriert die Spiegelreflexkamera automatisch. Sie können eine SLR erst löschen, nachdem Sie die zugehörigen Ressourcen gelöscht haben. Dies schützt Ihre Amazon-EKS-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können. Die SLR-Richtlinie gewährt Amazon EKS die Erlaubnis, zentrale Infrastrukturkomponenten zu beobachten und zu löschen: EC2 Ressourcen (Instances, Netzwerkschnittstellen, Sicherheitsgruppen), ELB-Ressourcen (Load Balancer, Zielgruppen), CloudWatch Funktionen (Protokollierung und Metriken) und IAM-Rollen mit dem Präfix „eks“. Sie ermöglicht auch private Endpunktnetzwerke durch VPC/hosted Zonenzuweisung und beinhaltet Berechtigungen für die EventBridge Überwachung und Bereinigung von mit EKS markierten Ressourcen. Weitere Informationen finden Sie unter: + [AWS verwaltete Richtlinie: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) + [Serviceverknüpfte Rollenberechtigungen für Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks) ## Benutzerdefinierte AWS Tags für EKS Auto-Ressourcen Standardmäßig erlauben die verwalteten Richtlinien im Zusammenhang mit dem automatischen Modus von EKS nicht das Anwenden von benutzerdefinierten Tags auf im automatischen Modus bereitgestellte AWS Ressourcen. Wenn Sie benutzerdefinierte Tags auf AWS Ressourcen anwenden möchten, müssen Sie der Cluster-IAM-Rolle zusätzliche Berechtigungen zuweisen, die über ausreichende Berechtigungen verfügen, um Tags auf AWS Ressourcen zu erstellen und zu ändern. Nachfolgend finden Sie ein Beispiel für eine Richtlinie, die uneingeschränkten Zugriff auf Tags gewährt: ### Beispiel für eine benutzerdefinierte Tag-Richtlinie anzeigen ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Compute", "Effect": "Allow", "Action": [ "ec2:CreateFleet", "ec2:RunInstances", "ec2:CreateLaunchTemplate" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-node-class-name": "*", "aws:RequestTag/eks:kubernetes-node-pool-name": "*" } } }, { "Sid": "Storage", "Effect": "Allow", "Action": [ "ec2:CreateVolume", "ec2:CreateSnapshot" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:snapshot/*" ], "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "Networking", "Effect": "Allow", "Action": "ec2:CreateNetworkInterface", "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" }, "StringLike": { "aws:RequestTag/eks:kubernetes-cni-node-name": "*" } } }, { "Sid": "LoadBalancer", "Effect": "Allow", "Action": [ "elasticloadbalancing:CreateLoadBalancer", "elasticloadbalancing:CreateTargetGroup", "elasticloadbalancing:CreateListener", "elasticloadbalancing:CreateRule", "ec2:CreateSecurityGroup" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldProtection", "Effect": "Allow", "Action": [ "shield:CreateProtection" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } }, { "Sid": "ShieldTagResource", "Effect": "Allow", "Action": [ "shield:TagResource" ], "Resource": "arn:aws:shield::*:protection/*", "Condition": { "StringEquals": { "aws:RequestTag/eks:eks-cluster-name": "${aws:PrincipalTag/eks:eks-cluster-name}" } } } ] } ``` ## Zugriffsrichtlinien-Referenz Weitere Informationen zu den von EKS Auto Mode verwendeten Kubernetes-Berechtigungen finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md). # Weitere Informationen zu VPC-Netzwerke und Load Balancing in EKS Auto Mode In diesem Thema wird erläutert, wie Sie die Netzwerk- und Load-Balancer-Features der Virtual Private Cloud (VPC) in EKS Auto Mode konfigurieren. Obwohl EKS Auto Mode die meisten Netzwerkkomponenten automatisch verwaltet, können Sie bestimmte Aspekte der Netzwerkkonfiguration Ihres Clusters dennoch über `NodeClass`-Ressourcen und Load-Balancer-Annotationen anpassen. Wenn Sie EKS Auto Mode verwenden, AWS verwaltet es die VPC Container Network Interface (CNI) -Konfiguration und die Load Balancer-Bereitstellung für Ihren Cluster. Sie können das Netzwerkverhalten beeinflussen, indem Sie `NodeClass`-Objekte definieren und bestimmte Annotationen auf Ihre Service- und Ingress-Ressourcen anwenden, während Sie gleichzeitig das automatisierte Betriebsmodell beibehalten, das EKS Auto Mode bereitstellt. ## Netzwerkfähigkeit EKS Auto Mode verfügt über eine neue Netzwerkfunktion, die das Netzwerk von Knoten und Pods verwaltet. Sie können es konfigurieren, indem Sie ein `NodeClass`-Kubernetes-Objekt erstellen. Die Konfigurationsoptionen für das vorherige AWS VPC-CNI gelten nicht für den EKS-Automatikmodus. ### Konfiguration des Netzwerks mit einer `NodeClass` Die `NodeClass`-Ressource in EKS Auto Mode ermöglicht es Ihnen, bestimmte Aspekte der Netzwerkfunktionen anzupassen. Über `NodeClass` können Sie Sicherheitsgruppen auswählen, die Platzierung von Knoten in VPC-Subnetzen steuern, SNAT-Richtlinien festlegen, Netzwerkrichtlinien konfigurieren und die Protokollierung von Netzwerkereignissen aktivieren. Dieser Ansatz behält das automatisierte Betriebsmodell von EKS Auto Mode bei und bietet gleichzeitig Flexibilität für die Anpassung des Netzwerks. Sie können eine `NodeClass` verwenden, um: + Sicherheitsgruppe für Knoten auswählen + Steuern, wie Knoten in VPC-Subnetzen platziert werden + SNAT-Richtlinie für den Knoten auf `random` oder `disabled` festlegen + Aktivieren Sie die *Kubernetes-Netzwerkrichtlinien*, einschließlich: + Einstellen der Netzwerkrichtlinie auf „Standardmäßig ablehnen“ oder „Standardmäßig zulassen“ + Aktivieren Sie die Protokollierung von Netzwerkereignissen in einer Datei. + Trennen Sie den Pod-Datenverkehr vom Knotendatenverkehr, indem Sie Pods an verschiedene Subnetze anfügen. Erfahren Sie, wie Sie [ein Amazon EKS erstellen NodeClass](create-node-class.md). ### Überlegungen EKS Auto Mode unterstützt: + EKS-Netzwerkrichtlinien. + Die `HostPort`- und `HostNetwork`-Optionen für Kubernetes-Pods. + Knoten und Pods in öffentlichen oder privaten Subnetzen. + Zwischenspeichern von DNS-Abfragen auf dem Knoten. EKS Auto Mode unterstützt Folgendes **nicht**: + Sicherheitsgruppen pro Pod (SGPP). Um separate Sicherheitsgruppen auf den Pod-Verkehr im Auto-Modus anzuwenden, verwenden Sie `NodeClass` stattdessen `podSecurityGroupSelectorTerms` in. Weitere Informationen finden Sie unter [Separate Subnetze und Sicherheitsgruppen für Pods](create-node-class.md#pod-subnet-selector). + Benutzerdefinierte Netzwerke in `ENIConfig`. Sie können Pods in mehreren Subnetzen platzieren oder sie mit [Separate Subnetze und Sicherheitsgruppen für Pods](create-node-class.md#pod-subnet-selector) exklusiv vom Knoten-Datenverkehr isolieren. + Warm-IP-, Warm-Präfix- und Warm-ENI-Konfigurationen. + Konfiguration für minimale IP-Ziele. + Andere Konfigurationen, die von der AWS Open-Source-VPC CNI unterstützt werden. + Konfigurationen der Netzwerkrichtlinien, wie beispielsweise die Anpassung des Conntrack-Timers (Standardwert ist 300 Sekunden). + Netzwerkereignisprotokolle exportieren nach. CloudWatch ### Netzwerk-Ressourcenmanagement Der automatische Modus von EKS kümmert sich um die Verwaltung von Präfixen, IP-Adressen und Netzwerkschnittstellen, indem er die NodeClass Ressourcen für Netzwerkkonfigurationen überwacht. Der Service führt mehrere wichtige Vorgänge automatisch aus: **Präfix-Delegierung** Der automatische Modus von EKS verwendet standardmäßig die Präfix-Delegierung (/28-Präfixe) für Pod-Netzwerke und verwaltet einen vordefinierten Warmpool von IP-Ressourcen, der auf der Grundlage der Anzahl der geplanten Pods skaliert wird. Wenn eine Fragmentierung des Pod-Subnetzes erkannt wird, stellt der automatische Modus sekundäre IP-Adressen (/32) bereit. Aufgrund dieses standardmäßigen Pod-Netzwerkalgorithmus berechnet der automatische Modus die maximale Anzahl von Pods pro Knoten auf der Grundlage der Anzahl ENIs und der IPs unterstützten pro Instanztyp (wobei der schlimmste Fall der Fragmentierung vorausgesetzt wird). Weitere Informationen zu Max ENIs und IPs pro Instance-Typ finden Sie unter [Maximale IP-Adressen pro Netzwerkschnittstelle](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) im EC2-Benutzerhandbuch. Die Anzahl der Instance-Familien der neueren Generation (Nitro v6 und höher) wurde generell IPs pro Instance-Typ erhöht, ENIs und der automatische Modus passt die Berechnung der maximalen Anzahl an Pods entsprechend an. Für IPv6 Cluster wird nur die Präfix-Delegierung verwendet, und der automatische Modus verwendet immer ein maximales Pod-Limit von 110 Pods pro Knoten. **Abkühlungs-Management** Der Dienst implementiert einen Cooldown-Pool für Präfixe oder sekundäre IPv4 Adressen, die nicht mehr verwendet werden. Nach Ablauf der Ruhephase werden diese Ressourcen wieder an die VPC zurückgegeben. Wenn Pods diese Ressourcen jedoch während der Ruhephase wiederverwenden, werden sie aus dem Abkühlungs-Pool wiederhergestellt. **IPv6 Support** Für IPv6 Cluster stellt EKS Auto Mode ein `/80` IPv6 Präfix pro Knoten auf der primären Netzwerkschnittstelle bereit. Bei Verwendung `podSubnetSelectorTerms` wird das Präfix stattdessen einer sekundären Netzwerkschnittstelle im Pod-Subnetz zugewiesen. Der Service gewährleistet außerdem die ordnungsgemäße Verwaltung und Garbage Collection aller Netzwerkschnittstellen. ## Lastausgleich Sie konfigurieren AWS Elastic Load Balancer, die vom EKS Auto Mode bereitgestellt werden, mithilfe von Anmerkungen zu Service- und Ingress-Ressourcen. Für weitere Informationen siehe [Erstellen Sie einen IngressClass , um einen Application Load Balancer zu konfigurieren](auto-configure-alb.md) oder [Verwendung von Service-Annotationen zur Konfiguration von Network Load Balancers](auto-configure-nlb.md). ### Überlegungen zum Load Balancing mit EKS Auto Mode + Der Standard- Zielmodus ist der IP-Modus, nicht der Instance-Modus. + EKS Auto Mode unterstützt nur den Sicherheitsgruppenmodus für Network Load Balancers. + AWS unterstützt nicht die Migration von Load Balancern vom selbstverwalteten AWS Load Balancer-Controller zur Verwaltung durch EKS Auto Mode. + Das Feld `networking.ingress.ipBlock` wird in der `TargetGroupBinding`-Spezifikation nicht unterstützt. + Wenn Ihre Worker-Knoten benutzerdefinierte Sicherheitsgruppen verwenden (kein `eks-cluster-sg- `-Benennungsmuster), benötigt Ihre Cluster-Rolle zusätzliche IAM-Berechtigungen. Die standardmäßige von EKS verwaltete Richtlinie berechtigt EKS lediglich zur Änderung von Sicherheitsgruppen mit dem Namen `eks-cluster-sg-`. Ohne die Erlaubnis, Ihre benutzerdefinierten Sicherheitsgruppen zu ändern, kann EKS die erforderlichen Eingangsregeln nicht hinzufügen, die es ermöglichen, dass der ALB/NLB Datenverkehr Ihre Pods erreicht. #### Überlegungen zu CoreDNS Der automatische EKS-Modus verwendet nicht die herkömmliche CoreDNS-Bereitstellung, um die DNS-Auflösung innerhalb des Clusters bereitzustellen. Stattdessen verwenden Auto-Mode-Knoten CoreDNS, das als Systemdienst direkt auf jedem Knoten ausgeführt wird. Wenn Sie einen herkömmlichen Cluster in den automatischen Modus umstellen, können Sie die CoreDNS-Bereitstellung aus Ihrem Cluster entfernen, sobald Ihre Workloads auf die Knoten im automatischen Modus verschoben wurden. **Wichtig** Wenn Sie planen, einen Cluster mit Knoten im automatischen Modus und ohne automatischen Modus zu verwalten, müssen Sie die CoreDNS-Bereitstellung beibehalten. Knoten ohne automatischen Modus verlassen sich bei der DNS-Auflösung auf die CoreDNS CoreDNS-Pods, da sie nicht auf den DNS-Dienst auf Knotenebene zugreifen können, den der automatische Modus bereitstellt.