**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 unter, 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. # Versionshinweise zu EKS Auto Mode überprüfen Diese Seite dokumentiert Aktualisierungen von Amazon EKS Auto Mode. Auf dieser Seite finden Sie regelmäßig Ankündigungen zu neuen Features, Fehlerbehebungen, bekannten Problemen und veralteten Funktionen. Um Benachrichtigungen über alle Änderungen an den Quelldateien dieser spezifischen Dokumentationsseite zu erhalten, können Sie die folgende URL mit einem RSS-Reader abonnieren: ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom ``` ## 1. Oktober 2026 **Feature**: Ab EKS 1.37 verwenden neu erstellte Auto-Mode-Knotenpools standardmäßig `consolidationPolicy: Balanced` statt. `WhenEmptyOrUnderutilized` Die Workloads eines Nodes werden zwar immer dann `WhenEmptyOrUnderutilized` unterbrochen, wenn ein Ersatzkandidat gefunden wird, der zu Kosteneinsparungen führt (nur 0,01 USD pro Stunde), `Balanced` genehmigt die Unterbrechung jedoch, wenn die stündlichen Kosteneinsparungen die Kosten für die Unterbrechung der Pods auf diesem Knoten wert sind. Sie sollten weniger Pod-Räumungen zu ungefähr den gleichen Kosten erleben. Um das vorherige Standardverhalten auf einem neuen EKS 1.37 Auto Mode Node Pool beizubehalten, legen Sie es explizit fest: ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: example spec: ... disruption: consolidationPolicy: WhenEmptyOrUnderutilized ``` Wenn Sie Auto-Mode-Knotenpools verwalten über GitOps (zum Beispiel Argo CD oder Flux): + Manifeste, die weggelassen `consolidationPolicy` werden, werden nach 1.37 `Balanced` auf dem Live-Objekt angezeigt, solange deine Git-Quelle immer noch keinen Wert hat. Lege in deinen Manifesten `consolidationPolicy` explizit fest, ob Git und Cluster übereinstimmen sollen. + Die Standardeinstellung wird nur bei der Erstellung der Ressource angewendet. Eine GitOps Synchronisation, bei der ein nicht festgelegter Auto-Mode-Knotenpool (oder ein neuer Cluster, der auf 1.37 gebootet wurde) gelöscht und neu erstellt wird, wird `Balanced` auch dann wieder aufgenommen, wenn zuvor der „gleiche“ Auto-Mode-Knotenpool verwendet wurde. `WhenEmptyOrUnderutilized` Stellen Sie das Feld so ein, dass bei der Neuerstellung ein leises Umschalten vermieden wird. EKS 1.37 aktualisiert auch die beiden EKS-Node-Pools im automatischen Modus (allgemein, System) auf. `consolidationPolicy: Balanced` Da EKS Auto diese stündlich abgleicht, können Sie dieses Feld nicht für sie an Ort und Stelle überschreiben. Wenn für eine bestimmte Arbeitslast das vorherige `WhenEmptyOrUnderutilized` Verhalten erforderlich ist, aktualisieren Sie die Arbeitslast auf Ziel a [ NodePool](associate-workload.md), das festgelegt `consolidationPolicy: WhenEmptyOrUnderutilized` ist. ## 14. September 2026 **Veraltet**: Das [`volume-modifier-for-k8s`](https://github.com/awslabs/volume-modifier-for-k8s) Projekt wurde zugunsten der nativen Kubernetes-API eingestellt. [`VolumeAttributesClass`](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/) Dieses Projekt wurde verwendet, um Anmerkungen auf einem zu ändern, um ein EBS-Volume zu modifizieren. PersistentVolumeClaim Nach dem 31. Oktober 2026 unterstützt der automatische Modus von Amazon EKS diese Anmerkungen nicht mehr. Verwenden Sie stattdessen die `VolumeAttributesClass` Kubernetes-API, um EBS-Volumes nach diesem Datum zu ändern. Weitere Informationen finden Sie unter [Erstellen einer Speicherklasse](create-storage-class.md). ## 17. August 2026 **Dokumentation**: Es wurden Anweisungen hinzugefügt, um den von EKS Auto Mode verwalteten Controllern über die `eks:managed` Gruppe im automatisch erstellten Zugriffseintrag zusätzliches Kubernetes-RBAC zu gewähren. `AWSServiceRoleForAmazonEKS` Dadurch werden Anwendungsfälle wie das Gewähren des Zugriffs auf einen bestimmten Load Balancer-Controller freigeschaltet, `Secret` sodass dieser die OIDC-Konfiguration auf einem ALB auflösen kann. `Ingress` Weitere Informationen finden Sie unter und die exemplarische Vorgehensweise unter[Gewähren Sie verwalteten EKS Auto Mode-Controllern zusätzliche Kubernetes-RBAC](auto-managed-rbac.md). [Gewähren Sie dem EKS Auto Mode Load Balancer-Controller Zugriff auf ein bestimmtes Secret](auto-managed-rbac-example.md) ## 12. August 2026 **Feature**: Der Amazon EKS Auto Mode Load Balancer-Controller unterstützt jetzt Funktionen vom Load AWS Balancer Controller bis Version 3.4. Beachten Sie, dass die Gateway-API noch nicht unterstützt wird. + JWT-Validierung für Ingress — Validieren Sie JSON Web Tokens (JWTs) auf der Listener-Regelebene des Application Load Balancer (ALB), bevor Anfragen Ihr Backend erreichen, mithilfe einer neuen Aktion. Ingress-level Weitere Informationen finden Sie unter [ Application Load Balancer unterstützt jetzt den Fluss von Client-Anmeldeinformationen mit JWT-Überprüfung. ](https://aws.amazon.com/about-aws/whats-new/2025/11/application-load-balancer-jwt-verification/) + Gewichtete Zielgruppen mit Network Load Balancer (NLB) — Verteilen Sie den Datenverkehr in einem NLB-Dienst nach Gewichtung auf mehrere Zielgruppen. Dies unterstützt blaugrüne und kanarische Bereitstellungsmuster, einschließlich einer Gewichtung von 0, wenn mindestens eine andere Zielgruppe eine Gewichtung ungleich Null hat. Weitere Informationen finden Sie unter [ Network Load Balancer unterstützen jetzt gewichtete Zielgruppen. ](https://aws.amazon.com/blogs/networking-and-content-delivery/network-load-balancers-now-support-weighted-target-groups/) + TargetGroupBinding Abstimmungsereignisse — Amazon EKS gibt jetzt Kubernetes-Ereignisse aus, wenn der TargetGroupBinding Abgleich fehlschlägt, sodass Probleme mit der Zielregistrierung nicht nur in den Controller-Protokollen, sichtbar sind`kubectl describe`. + Subnetzreihenfolge beibehalten — Die `aws-load-balancer-subnets` Anmerkung berücksichtigt jetzt die von Ihnen angegebene Reihenfolge, anstatt die Subnetze intern neu anzuordnen. + Cross-zone Load Balancing für ALB — Sie können das zonenübergreifende Load Balancing jetzt explizit auf Application Load Balancers deaktivieren. ## 5. August 2026 **Feature**: Der Amazon EKS Auto Mode Load Balancer-Controller unterstützt jetzt Multi-Cluster-Zielgruppen und entspricht damit dem Verhalten des AWS Load Balancer Controllers. Mit dieser Funktion können Sie denselben Zielgruppen-ARN für mehrere `TargetGroupBinding` Ressourcen verwenden, sodass eine einzelne Zielgruppe mehrere Kubernetes-Cluster (in derselben VPC) bedienen oder Ziele aus anderen Quellen akzeptieren kann. Weitere Informationen finden Sie unter [Multi-Cluster-Zielgruppen konfigurieren](auto-multi-cluster-target-groups.md). ## 27. Juli 2026 **Feature**: Der Auto Mode Load Balancer-Controller von Amazon Elastic Kubernetes Service (Amazon EKS) unterstützt jetzt Funktionen aus Load Balancer Controller v2.13 und AWS v2.14. + URL Rewrite von Application Load Balancer (ALB) — Sie können jetzt Anforderungs-URLs und Host-Header transformieren, bevor Anfragen Ihre Back-End-Dienste erreichen, ohne Ihre Anwendung zu ändern. Weitere Informationen finden Sie unter [ Einführung in das Rewrite von URLs und Host-Headern mit Application Load Balancers. AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-url-and-host-header-rewrite-with-aws-application-load-balancers/) + PrefixListsIDs und LoadBalancerName in IngressClassParams — Sie können jetzt Präfixlisten für Sicherheitsgruppen und einen benutzerdefinierten Load Balancer-Namen für Ihren Application Load Balancer einrichten. Beide werden als Ingress-Annotationen und als Felder in IngressClassParams (PrefixListSids und load) unterstützt. BalancerName Wenn diese Option aktiviert ist IngressClassParams, gilt die Konfiguration für alle Ingresses in der. IngressClass Sie müssen nicht mehr jede Ingress-Ressource einzeln mit Anmerkungen versehen. + Frontend-NLB für Ingress — Sie können jetzt einen Network Load Balancer (NLB) vor einem Application Load Balancer platzieren. Dies kombiniert statische NLB-IP-Adressen AWS PrivateLink mit den Layer-7-Routing-Funktionen von ALB. Aktivieren Sie diese Funktion mit alb.ingress.kubernetes. io/enable-Frontend-NLB-Anmerkung. Weitere Informationen finden Sie unter [ Application Load Balancer-type Target Group für Network Load Balancer. ](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) + TCP\_UDP-Listener-Unterstützung — NLB-Dienste können jetzt TCP\_UDP-Listener verwenden, die sowohl TCP- als auch UDP-Verkehr auf demselben Port zulassen. Aktivieren Sie diese Funktion mit service.beta.kubernetes. io/aws-load-balancer-enable-tcp-udp-listener-Anmerkung. + Per-target-group Proxy-Protokoll — Sie können jetzt Proxy Protocol v2-Header auf der Ebene der einzelnen Zielgruppen konfigurieren, indem Sie service.beta.kubernetes verwenden. io/aws-load-balancer-proxy-protocol-per-target-group-Annotation, anstatt die Konfiguration einheitlich auf alle Zielgruppen anzuwenden. + TargetType-Feld in IngressClassParams — Sie können den Standard-Zieltyp (Instance oder IP) jetzt direkt angeben, sodass Sie nicht jede Ingress-Ressource einzeln annotieren müssen. IngressClassParams + Subnetzerkennung anhand der Erreichbarkeit — Die Subnetzauswahl erfordert nicht mehr unbedingt Kubernetes. io/role Stichwörter. Der Controller greift jetzt auf die Erreichbarkeitsanalyse zurück, die auf Routentabellen basiert, wenn keine Tags vorhanden sind. Der Controller unterstützt diesen Fallback derzeit nicht für Load Balancer mit dem IP-Adresstyp Dualstack. + IPv4-IP-Adressmanager (IPAM) -Unterstützung für ALB — Ein ALB mit Internetanschluss kann seine öffentlichen IPv4-Adressen jetzt aus einem IPAM-Pool von Amazon Virtual Private Cloud (Amazon VPC) beziehen, anstatt aus verwalteten Adressbereichen. AWS Dadurch erhalten Sie vorhersehbare IP-Adressblöcke für Zulassungslisten. Geben Sie den Pool mit alb.ingress.kubernetes an. io/ipam-ipv4-Pool-ID-Anmerkung. Weitere Informationen finden Sie unter [ Vereinfachen Sie die öffentliche IP-Adresszuweisung von ALB mit VPC IPAM. ](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-albs-public-ip-address-assignment-with-vpc-ipam/) **Feature**: Die `Balanced` Konsolidierungsrichtlinie für den EKS-Automatikmodus wurde hinzugefügt. NodePools Bei der Einstellung `spec.disruption.consolidationPolicy: Balanced` wird jede Konsolidierungsaktion bewertet, indem die Einsparungen bei den Rechenkosten gegen die Ausfallkosten abgewogen werden. Aktionen, bei denen die Störung die Einsparungen überwiegt, werden übersprungen. Wenn Sie die `WhenEmpty` aktuelle Version verwenden, können Sie zu dieser wechseln, `Balanced` um die Kosteneinsparungen der Konsolidierung zu nutzen. Wenn Sie die `WhenEmptyOrUnderutilized` aktuelle Version verwenden, können Sie zu dieser wechseln, um Unterbrechungen bei der Pod-Nutzung `Balanced` zu vermeiden und nur geringfügige Vorteile zu erzielen. `WhenEmpty`und `WhenEmptyOrUnderutilized` sind unverändert und bestehende NodePools behalten ihr aktuelles Verhalten bei. Weitere Informationen finden Sie unter [Erstellen eines Knotenpools für EKS Auto Mode](create-node-pool.md) und [ Disruption ](https://karpenter.sh/docs/concepts/disruption/) in der Karpenter Dokumentation. ## 21. Juli 2026 **Feature**: Unterstützung für die Konfiguration statischer Netzwerkschnittstellen hinzugefügt. NodeClass Sie können jetzt Elastic Fabric Adapter (EFA) -Netzwerkschnittstellen konfigurieren, indem Sie sowohl dynamische als auch statische Kapazitätsbereitstellung verwenden`advancedNetworking.networkInterfaces`, sodass EFA-ready Knoten für verteilte Trainings- und Inferenz-Workloads genutzt werden können. Weitere Informationen finden Sie unter [Konfiguration der statischen Netzwerkschnittstelle](create-node-class.md#static-network-interfaces). ## 30. Juni 2026 **Feature**: Der EKS Auto Mode Load Balancer-Controller unterstützt jetzt Funktionen aus Load AWS Balancer Controller v2.10, v2.11 und v2.12. Aus Upstream v2.12.0: + Prioritätsverwaltung für Listener-Regeln — Der Controller kann jetzt explizit Prioritäten für Listener-Regeln festlegen und neu anordnen. Dadurch werden Ordnungskonflikte gelöst, wenn mehrere Ingress-Regeln auf denselben Listener abzielen Aus Upstream-Version 2.11.0: + Reservierung von Load Balancer Capacity Unit (LCU) — Sie können jetzt Kapazitätseinheiten sowohl auf Application Load Balancers (ALBs) als auch auf Network Load Balancers (NLBs) reservieren, um eine vorhersehbare Leistung für Workloads mit bekannten Verkehrsmustern sicherzustellen Aus Upstream-Version 2.10.0: + ALB Shield Advanced-Schutz — ALB-Ressourcen können jetzt mit AWS Shield Advanced über alb.ingress.kubernetes geschützt werden. io/shield-Anmerkung zum erweiterten Schutz + Bringen Sie Ihre eigenen Anforderungen mit TargetGroupBinding — Sie können jetzt auf bereits bestehende Zielgruppen verweisen, die nicht vom Controller erstellt wurden, was die Integration in eine extern verwaltete Infrastruktur ermöglicht + UDP-Unterstützung für Dual-Stack-NLB auf IPv6-Clustern — NLB-Dienste auf IPv6-Clustern unterstützen jetzt UDP-Protokoll-Listener + ALB-HTTP- und HTTPS-Listener-Attribute — Fine-grained Steuerung von Attributen auf Listener-Ebene (z. B. Routing-Verhalten, Header-Änderungen) über Anmerkungen ### Aktuelle Informationen zu verwalteten Richtlinien AWS wurde aktualisiert AmazonEKSServiceRolePolicy und AmazonEKSLoadBalancingPolicy unterstützt diese neuen Funktionen. ### Für Kunden, die benutzerdefinierte IAM-Richtlinien verwenden, sind Maßnahmen erforderlich Wenn Sie Ihre eigene benutzerdefinierte IAM-Richtlinie für die EKS-Clusterrolle Auto Mode angeben, anstatt die AWS-managed zu verwenden, müssen Sie sicherstellen AmazonEKSLoadBalancingPolicy, dass Ihre Richtlinie die oben aufgeführten Berechtigungen enthält. Wenn Sie Ihre benutzerdefinierte Richtlinie nicht aktualisieren, wird bei der Verwendung der neuen Funktionen der Fehler „Zugriff verweigert“ angezeigt. Um die Parität zu überprüfen, vergleichen Sie Ihre benutzerdefinierte Richtlinie mit der [ neuesten Version von AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html). Stellen Sie insbesondere sicher, dass Ihre Richtlinie Folgendes beinhaltet: + elasticloadbalancing:ModifyCapacityReservation, elasticloadbalancing:, elasticloadbalancing: ModifyIpPools und elasticloadbalancing: ModifyListenerAttributes SetRulePriorities + DescribeIpamPools ec2: und ec2: DescribeRouteTables + Schild:CreateProtection, Schild: DeleteProtection und Schild: TagResource ## 9. Juni 2026 **Feature**: Die Überwachung des Instanzstatus wurde zum EKS-Automatikmodus hinzugefügt. Der Compute Controller fragt jetzt EC2 ab`DescribeInstanceStatus`, um geplante Wartungsereignisse und Fehler bei der Instance- oder Systemstatusüberprüfung zu erkennen und defekte Knoten automatisch zu ersetzen. ## 4. Juni 2026 **Dokumentation**: Es wurden Anleitungen zur Kontrolle der Rechenkosten im EKS-Auto-Modus hinzugefügt, einschließlich der Funktionsweise der Konsolidierung, der Hindernisse und der empfohlenen Muster für überlastete Workloads. Weitere Informationen finden Sie unter [ Kostenoptimierung im EKS-Automatikmodus. ](auto-cost-control.md) ## 3. Juni 2026 **Feature**: Unterstützung für unterbrechbare Kapazitätsreservierungen im EKS-Automatikmodus hinzugefügt. Weitere Informationen finden Sie unter [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md). ## 5. Mai 2026 **Feature**: Unterstützung für EC2-Platzierungsgruppen im EKS-Automatikmodus hinzugefügt. Weitere Informationen finden Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec). ## 10. April 2026 **Neue unterstützte Instanztypen**: p6-b200, p6-b300, p5e, p5en, trn2, hpc8a, x8aedz, x8i. Die vollständige Liste der unterstützten Instanzen finden Sie unter. [Weitere Informationen zu von Amazon EKS Auto Mode verwalteten Instances](automode-learn-instances.md) ## 2. April 2026 **Aufgabe**: Bei der NodeClass Probelauf-Validierung werden jetzt dynamisch ausgewählte Instanztypen verwendet, die auf verknüpften Instanzen basieren. NodePools ## 2. Februar 2026 **Feature**: Unterstützung hinzugefügt, um den V4Egress-Verkehr von IPv6-Pods in EKS-IPv6-Clustern im automatischen Modus zu deaktivieren. Weitere Informationen finden Sie unter [Deaktivieren Sie den IPv4-Ausgang von IPv6-Pods in IPv6-Clustern.](create-node-class.md#enableV4Egress). ## 19. Dezember 2025 **Feature**: Unterstützung für den sekundären IP-Modus hinzugefügt, der sekundäre IP-Adressen anstelle von Präfixen für Auto-Knoten bereitstellt. Der Modus verwaltet eine sekundäre IP als MinimalIPTarget und spart IP-Ressourcen für Kunden, die keine weiteren sekundären IP-Adressen oder Präfixe aufwärmen müssen. Weitere Informationen erhalten Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec) und [Sekundärer IP-Modus für Pods](create-node-class.md#secondary-IP-mode). ## 19. November 2025 **Feature**: Das parallele Abrufen und Entpacken von Seekable OCI (SOCI) für Instances der G-, P- und Trn-Familie mit lokalem NVMe-Speicher wurde aktiviert. SOCI Parallel Pull and Unpack wird für diese Instance-Familien im EKS-Auto-Modus immer verwendet, und es sind keine Konfigurationsänderungen erforderlich, um ihn zu aktivieren. Weitere Informationen zu SOCI finden Sie im [ Launch-Blog. ](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/) ## 19. November 2025 **Feature**: Unterstützung für Knotenpools mit statischer Kapazität hinzugefügt, die eine feste Anzahl von Knoten verwalten. Weitere Informationen finden Sie unter [Statische Kapazitätsknotenpools im automatischen EKS-Modus](auto-static-capacity.md). ## 23. Oktober 2025 **Feature: ** Benutzer mit Clustern in US-Regionen können jetzt die Verwendung von FIPS-kompatiblen AMIs anfordern, indem sie dies `spec.advancedSecurity.fips` in ihrer NodeClass Definition angeben. ## 1. Oktober 2025 **Feature: Der ** EKS-Automatikmodus unterstützt jetzt die Bereitstellung von Knoten in AWS lokalen Zonen. Weitere Informationen finden Sie unter [Stellen Sie EKS-Automodus-Knoten in Local Zones bereit](auto-local-zone.md). ## 30. September 2025 **Feature: Unterstützung für InstanceProfile ** wurde hinzugefügt, NodeClass `spec.instanceProfile` was sich gegenseitig aus dem `spec.role` Feld ausschließt. ## 29. September 2025 DRA wird derzeit nicht vom EKS-Automatikmodus unterstützt. ## 10. September 2025 **Aufgabe:** Vom Auto-Mode-Compute-Controller ausgelöste Ereignisse verwenden jetzt den Namen `eks-auto-mode/compute` statt `karpenter`. ## 24. August 2025 **Fehlerbehebung:** VPCs, die eine DHCP-Option mit einem benutzerdefinierten Domain-Namen mit Großbuchstaben verwendeten, führten dazu, dass Knoten aufgrund der Generierung eines ungültigen Host-Namens nicht dem Cluster beitreten konnten. Dieses Problem wurde behoben, und Domain-Namen mit Großbuchstaben funktionieren nun korrekt. ## 15. August 2025 **Fehlerbehebung:** Der Pod Identity Agent überwacht nun ausschließlich die lokale IPv4-Link-Adresse in einem IPv4-EKS-Cluster, um Probleme zu vermeiden, bei denen der Pod die IPv6-Adresse nicht erreichen kann. ## 06. August 2025 **Feature: ** Es wurde eine neue Konfiguration hinzugefügt NodeClass `spec.advancedNetworking.associatePublicIPAddress`, mit der verhindert werden kann, dass öffentliche IP-Adressen EKS-Knoten im automatischen Modus zugewiesen werden ## 30. Juni 2025 **Feature: ** Der Auto-Modus verwendet NodeClass jetzt zusätzlich zum Datenvolume den konfigurierten benutzerdefinierten KMS-Schlüssel, um das schreibgeschützte Root-Volume der Instance zu verschlüsseln. read/write Zuvor wurde der benutzerdefinierte KMS-Schlüssel nur zum Verschlüsseln des Daten-Volumes verwendet. ## 20. Juni 2025 **Feature: ** Unterstützung für die Steuerung der Bereitstellung von Workloads in On-Demand EC2-Kapazitätsreservierungen (ODCRs). Dadurch wird der optionale Schlüssel `capacityReservationSelectorTerms` hinzugefügt NodeClass, sodass Sie explizit steuern können, welche ODCRs Ihre Workloads verwenden. Weitere Informationen finden Sie unter [Steuern Sie die Bereitstellung von Workloads in Kapazitätsreservierungen mit EKS Auto Mode.](auto-odcr.md). ## 13. Juni 2025 **Feature:** Unterstützung für separate Pod-Subnetze in `NodeClass`. Dadurch werden die optionalen Schlüssel `podSubnetSelectorTerms` und `podSecurityGroupSelectorTerms` hinzugefügt, um die Subnetze und Sicherheitsgruppen für die Pods festzulegen. Weitere Informationen finden Sie unter [Separate Subnetze und Sicherheitsgruppen für Pods](create-node-class.md#pod-subnet-selector). ## 30. April 2025 **Feature:** Unterstützung für weitergeleitete Netzwerk-Proxys in `NodeClass`. Dadurch wird der optionale Schlüssel `advancedNetworking` zum Festlegen Ihres HTTPS-Proxys hinzugefügt. Weitere Informationen finden Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec). ## 18. April 2025 **Feature:** Unterstützung für die Auflösung von .local-Domains (in der Regel für Multicast-DNS reserviert) über Unicast-DNS. ## 11. April 2025 **Feature:** `certificateBundles` und `ephemeralStorage.kmsKeyID` zu `NodeClass` hinzugefügt. Weitere Informationen finden Sie unter [Knotenklassen-Spezifikation](create-node-class.md#auto-node-class-spec). **Feature:** Verbesserte Image-Abrufgeschwindigkeit, insbesondere für Instance-Typen mit lokalem Instance-Speicher, welche die schnellere Image-Dekomprimierung nutzen können. **Fehlerbehebung: Es ** wurde eine Rennbedingung behoben FailedCreatePodSandBox , die zu einem Fehler beim Wählen führte: Wählen Sie TCP 127.0.0. 1:50051: Verbinden: Die Verbindung verweigerte manchmal, wenn Pods sofort beim Start auf einen Knoten warteten. ## 4. April 2025 **Feature:** `registryPullQPS` von 5 auf 25 und `registryBurst` von 10 auf 50 erhöhen, um die vom Client erzwungene Drosselung des Image-Pulls zu reduzieren (`Failed to pull image xyz: pull QPS exceeded`) ## 31. März 2025 **Fehlerbehebung:** Behebt ein Problem, bei dem, wenn ein Kern-DNS-Pod in einem Knoten im Automatikmodus ausgeführt wird, DNS-Anfragen von Pods auf dem Knoten diesen Kern-DNS-Pod anstelle des lokalen DNS-Servers des Knotens erreichen. DNS-Anfragen von Pods in einem Knoten im Automatikmodus werden nun stets an den lokalen DNS-Server des Knotens weitergeleitet. ## 21. März 2025 **Fehlerbehebung:** Knoten im Automatikmodus lösen `kube-dns.kube-system.svc.cluster.local` nun korrekt auf, wenn kein `kube-dns`-Service im Cluster installiert ist. Behebt GitHub Problem [ \#2546](https://github.com/aws/containers-roadmap/issues/2546). ## 14. März 2025 **Feature**: `IPv4`-Ausgang in `IPv6`-Clustern aktiviert. Der `IPv4`-Datenverkehr, der aus `IPv6`-Clustern im Automatikmodus ausgegeben wird, wird nun automatisch in die `v4`-Adresse der primären ENI des Knotens übersetzt.