**Aidez à améliorer cette page** Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub ** lien ** Modifier cette page qui se trouve dans le volet droit de chaque page. Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Consultation des notes de mise à jour du mode automatique EKS Cette page présente les mises à jour du mode automatique Amazon EKS. Vous pouvez la consulter régulièrement pour suivre les annonces concernant les nouvelles fonctionnalités, les correctifs, les problèmes connus et les fonctionnalités obsolètes. Pour recevoir des notifications concernant toutes les modifications apportées aux fichiers sources de cette page de documentation spécifique, vous pouvez vous abonner à l’URL suivante à l’aide d’un lecteur RSS : ``` https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/automode/auto-change.adoc.atom ``` ## 1er octobre 2026 **Fonctionnalité ** : À partir d'EKS 1.37, les pools de nœuds en mode automatique nouvellement créés sont remplacés par défaut par. `consolidationPolicy: Balanced` `WhenEmptyOrUnderutilized` Tout en `WhenEmptyOrUnderutilized` perturbant les charges de travail d'un nœud chaque fois qu'il voit un candidat de remplacement qui permet de réaliser des économies de coûts (aussi peu que 0,01 USD par heure), `Balanced` approuve l'interruption lorsque les économies de coûts horaires valent le coût de la perturbation des Pods sur ce nœud. Vous devriez assister à moins d'expulsions de Pod à peu près au même coût. Pour conserver le comportement par défaut précédent sur un nouveau pool de nœuds en mode automatique EKS 1.37, définissez-le explicitement : ``` apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: example spec: ... disruption: consolidationPolicy: WhenEmptyOrUnderutilized ``` Si vous gérez les pools de nœuds en mode automatique via GitOps (par exemple, Argo CD ou Flux) : + Les manifestes qui `consolidationPolicy` omettent s'afficheront `Balanced` sur l'objet actif après la version 1.37 alors que votre source Git n'a toujours aucune valeur. Définissez `consolidationPolicy` explicitement dans vos manifestes si vous souhaitez que Git et cluster correspondent. + La valeur par défaut est appliquée uniquement au moment de la création de la ressource. Une GitOps synchronisation qui supprime et recrée un pool de nœuds en mode automatique non configuré (ou un nouveau cluster démarré en 1.37) reprend `Balanced` même si le « même » pool de nœuds en mode automatique existait auparavant. `WhenEmptyOrUnderutilized` Réglez le champ pour éviter un retournement silencieux lors de la recréation. EKS 1.37 met également à jour les deux pools de nœuds EKS en mode automatique (à usage général, système) vers. `consolidationPolicy: Balanced` Comme EKS Auto les réconcilie toutes les heures, vous ne pouvez pas modifier ce champ sur ceux qui sont en place. Si une charge de travail spécifique nécessite le `WhenEmptyOrUnderutilized` comportement précédent, mettez-la à jour pour cibler [ NodePool ](associate-workload.md) celle qui est définie`consolidationPolicy: WhenEmptyOrUnderutilized`. ## 14 septembre 2026 **Obsolète ** : le [`volume-modifier-for-k8s`](https://github.com/awslabs/volume-modifier-for-k8s) projet a été abandonné au profit de l'API Kubernetes native. [`VolumeAttributesClass`](https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/) Ce projet a été utilisé pour définir des annotations sur un volume EBS PersistentVolumeClaim afin de modifier un volume EBS. Après le 31 octobre 2026, le mode automatique Amazon EKS ne prend plus en charge ces annotations. Pour modifier les volumes EBS après cette date, utilisez plutôt l'API `VolumeAttributesClass` Kubernetes. Pour plus d’informations, consultez [Création d’une classe de stockage](create-storage-class.md). ## 17 août 2026 **Documentation ** : Ajout d'instructions pour accorder aux contrôleurs gérés en mode automatique EKS Auto Mode un Kubernetes RBAC supplémentaire via le `eks:managed` groupe sur l'entrée d'accès créée automatiquement. `AWSServiceRoleForAmazonEKS` Cela permet de débloquer des cas d'utilisation tels que l'octroi au contrôleur d'équilibrage de charge d'accéder à un élément spécifique `Secret` afin qu'il puisse résoudre la configuration OIDC sur un ALB. `Ingress` Pour plus d'informations, consultez [Accordez un Kubernetes RBAC supplémentaire aux contrôleurs gérés EKS Auto Mode](auto-managed-rbac.md) et la procédure pas à [Autoriser le contrôleur d'équilibrage de charge en mode automatique EKS à accéder à un secret spécifique](auto-managed-rbac-example.md) pas à l'adresse. ## 12 août 2026 **Fonctionnalité ** : Le contrôleur d'équilibrage de charge Amazon EKS Auto Mode prend désormais en charge les fonctionnalités allant du AWS Load Balancer Controller à la version 3.4. Notez que l'API Gateway n'est pas encore prise en charge. + Validation JWT pour Ingress : validez les jetons Web JSON (JWT) au niveau de la règle d'écoute de l'Application Load Balancer (ALB) avant que les demandes n'atteignent votre backend, via une nouvelle action. Ingress-level Pour plus d'informations, voir [ Application Load Balancer prend désormais en charge le flux d'informations d'identification des clients avec la vérification JWT. ](https://aws.amazon.com/about-aws/whats-new/2025/11/application-load-balancer-jwt-verification/) + Groupes cibles pondérés par Network Load Balancer (NLB) : répartissez le trafic entre plusieurs groupes cibles en fonction du poids sur un service NLB. Cela prend en charge les modèles de déploiement bleu-vert et canari, y compris un poids de 0 lorsqu'au moins un autre groupe cible a un poids différent de zéro. Pour plus d'informations, consultez la section Les équilibreurs de charge [ réseau prennent désormais en charge les groupes ](https://aws.amazon.com/blogs/networking-and-content-delivery/network-load-balancers-now-support-weighted-target-groups/) cibles pondérés. + TargetGroupBinding événements de réconciliation : Amazon EKS émet désormais des événements Kubernetes en cas d'échec de TargetGroupBinding réconciliation, ce qui permet de rendre les problèmes d'enregistrement des cibles visibles dans les journaux du contrôleur `kubectl describe` plutôt que dans les journaux du contrôleur uniquement. + Ordre des sous-réseaux préservé : l'`aws-load-balancer-subnets`annotation respecte désormais l'ordre que vous spécifiez, au lieu de réorganiser les sous-réseaux en interne. + Cross-zone équilibrage de charge pour ALB : vous pouvez désormais désactiver explicitement l'équilibrage de charge entre zones sur les équilibreurs de charge des applications. ## 5 août 2026 **Fonctionnalité ** : Le contrôleur d'équilibrage de charge Amazon EKS Auto Mode prend désormais en charge des groupes cibles multi-clusters, conformément au comportement du contrôleur d'équilibrage de AWS charge. Grâce à cette fonctionnalité, vous pouvez partager le même ARN de groupe cible sur plusieurs `TargetGroupBinding` ressources, de sorte qu'un seul groupe cible puisse desservir plusieurs clusters Kubernetes (dans le même VPC) ou accepter des cibles provenant d'autres sources. Pour plus d’informations, consultez [Configuration de groupes cibles multi-clusters](auto-multi-cluster-target-groups.md). ## 27 juillet 2026 **Fonctionnalité ** : Le contrôleur d'équilibrage de charge en mode automatique Amazon Elastic Kubernetes Service (Amazon EKS) prend désormais en charge les fonctionnalités de Load Balancer Controller v2.13 et AWS v2.14. + Réécriture d'URL de l'équilibreur de charge des applications (ALB) : vous pouvez désormais transformer les URL des requêtes et les en-têtes d'hôte avant que les demandes n'atteignent vos services principaux, sans modifier votre application. Pour plus d'informations, consultez [ Présentation de la réécriture des URL et des en-têtes d'hôte avec les ](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-url-and-host-header-rewrite-with-aws-application-load-balancers/) équilibreurs de charge AWS d'application. + PrefixListsIDs et LoadBalancerName dans IngressClassParams — Vous pouvez désormais définir des listes de préfixes de groupes de sécurité et un nom d'équilibreur de charge personnalisé pour votre équilibreur de charge d'application. Les deux sont pris en charge en tant qu'annotations d'entrée et en tant que champs dans IngressClassParams (PrefixListSids et load). BalancerName Lorsqu'elle est définie IngressClassParams, la configuration s'applique à toutes les entrées du IngressClass. Vous n'avez plus besoin d'annoter chaque ressource Ingress individuellement. + NLB frontal pour Ingress — Vous pouvez désormais placer un équilibreur de charge réseau (NLB) devant un équilibreur de charge d'application. Cela combine les adresses IP statiques NLB et les capacités AWS PrivateLink de routage de couche 7 d'ALB. Activez cette fonctionnalité avec alb.ingress.kubernetes. io/enableannotation -frontend-nlb. Pour plus d'informations, consultez la section Groupe Balancer-type cible de charge des [ applications pour l'équilibreur ](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) de charge réseau. + Prise en charge des auditeurs TCP\_UDP — Les services NLB peuvent désormais utiliser des écouteurs TCP\_UDP, qui autorisent le trafic TCP et UDP sur le même port. Activez cette fonctionnalité avec le service.beta.kubernetes. io/awsAnnotation -load-balancer-enable-tcp-udp-listener. + Per-target-group protocole proxy : vous pouvez désormais configurer les en-têtes du protocole proxy v2 au niveau du groupe cible individuel à l'aide du service.beta.kubernetes. io/awsannotation -load-balancer-proxy-protocol-per-target-group, plutôt que d'appliquer la configuration à tous les groupes cibles de manière uniforme. + Champ TargetType dans IngressClassParams — Vous pouvez désormais définir le type de cible par défaut (instance ou IP) directement dans IngressClassParams, ce qui vous évite d'avoir à annoter chaque ressource Ingress individuellement. + Découverte de sous-réseaux par accessibilité — La sélection de sous-réseaux ne nécessite plus strictement Kubernetes. io/role balises. Le contrôleur revient désormais à une analyse d'accessibilité basée sur une table de routage lorsque les balises sont absentes. Le contrôleur ne prend pas actuellement en charge cette solution de secours pour les équilibreurs de charge avec un type d'adresse IP dualstack. + Prise en charge du gestionnaire d'adresses IP IPv4 (IPAM) pour ALB — Un ALB connecté à Internet peut désormais extraire ses adresses IPv4 publiques d'un pool IPAM Amazon Virtual Private Cloud (Amazon VPC) plutôt que de plages d'adresses gérées. AWS Cela vous donne des blocs d'adresses IP prévisibles pour les listes d'autorisation. Spécifiez le pool avec le fichier alb.ingress.kubernetes. io/ipamAnnotation -ipv4-pool-id. Pour plus d'informations, consultez la section [ Simplifier l'attribution d'adresses IP publiques d'ALB avec VPC IPAM. ](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-albs-public-ip-address-assignment-with-vpc-ipam/) **Fonctionnalité ** : Ajout de la politique de `Balanced` consolidation pour le mode automatique EKS NodePools. Définissez des `spec.disruption.consolidationPolicy: Balanced` scores pour chaque action de consolidation en évaluant les économies de coûts de calcul par rapport aux coûts liés aux interruptions. Il ignore les actions lorsque les perturbations l'emportent sur les économies. Si vous l'utilisez `WhenEmpty` aujourd'hui, vous pouvez passer à l'option `Balanced` pour réaliser les économies de coûts liées à la consolidation. Si vous l'utilisez `WhenEmptyOrUnderutilized` aujourd'hui, vous pouvez passer à une solution pour `Balanced` éviter toute interruption des capsules pour des avantages marginaux. `WhenEmpty`et `WhenEmptyOrUnderutilized` sont inchangés, et les existants NodePools conservent leur comportement actuel. Pour plus d'informations, consultez [Création d’un pool de nœuds pour le mode automatique EKS](create-node-pool.md) la section [ Disruption ](https://karpenter.sh/docs/concepts/disruption/) dans la documentation de Karpenter. ## 21 juillet 2026 **Fonctionnalité ** : Ajout de la prise en charge de la configuration de l'interface réseau statique sur NodeClass. Vous pouvez désormais configurer les interfaces réseau Elastic Fabric Adapter (EFA) `advancedNetworking.networkInterfaces` pour le provisionnement de capacité dynamique et statique, en activant les EFA-ready nœuds pour les charges de travail d'apprentissage et d'inférence distribuées. Pour plus d’informations, consultez [Configuration de l'interface réseau statique](create-node-class.md#static-network-interfaces). ## 30 juin 2026 **Fonctionnalité ** : Le contrôleur d'équilibrage de charge EKS Auto Mode prend désormais en charge les fonctionnalités de AWS Load Balancer Controller v2.10, v2.11 et v2.12. Depuis la version 2.12.0 en amont : + Gestion des priorités des règles des auditeurs — Le contrôleur peut désormais définir et réorganiser explicitement les priorités des règles des auditeurs, résolvant ainsi les conflits d'ordre lorsque plusieurs règles d'entrée ciblent le même écouteur Depuis la version 2.11.0 en amont : + Réservation d'unités de capacité de l'équilibreur de charge (LCU) : vous pouvez désormais réserver des unités de capacité à la fois sur les équilibreurs de charge des applications (ALB) et sur les équilibreurs de charge réseau (NLB), garantissant ainsi des performances prévisibles pour les charges de travail dont les modèles de trafic sont connus Depuis la version 2.10.0 en amont : + Protection avancée ALB Shield — Les ressources ALB peuvent désormais être protégées avec AWS Shield Advanced via alb.ingress.kubernetes. io/shield-annotation de protection avancée + Apportez votre propre personnalisation TargetGroupBinding  : vous pouvez désormais référencer des groupes cibles préexistants qui n'ont pas été créés par le contrôleur, ce qui permet l'intégration avec une infrastructure gérée en externe + Prise en charge UDP pour les NLB à double pile sur les clusters IPv6 — Les services NLB sur les clusters IPv6 prennent désormais en charge les auditeurs du protocole UDP + Attributs d'écouteur HTTP et HTTPS ALB : Fine-grained contrôle des attributs au niveau de l'auditeur (par exemple, comportement de routage, modifications d'en-tête) via des annotations ### Mise à jour des politiques gérées AWS a été mis à jour AmazonEKSServiceRolePolicy et AmazonEKSLoadBalancingPolicy prend en charge ces nouvelles fonctionnalités. ### Action requise pour les clients utilisant des politiques IAM personnalisées Si vous fournissez votre propre politique IAM personnalisée pour le rôle de cluster EKS Auto Mode au lieu d'utiliser le AWS-managed AmazonEKSLoadBalancingPolicy, vous devez vous assurer que votre politique inclut les autorisations répertoriées ci-dessus. L'absence de mise à jour de votre politique personnalisée entraînera des erreurs de refus d'accès lors de l'utilisation des nouvelles fonctionnalités. Pour vérifier la parité, comparez votre politique personnalisée à la [ dernière version de AmazonEKSLoadBalancingPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLoadBalancingPolicy.html). Plus précisément, assurez-vous que votre police inclut : + elasticloadbalancing :ModifyCapacityReservation, elasticloadbalancing :, elasticloadbalancing : et elasticloadbalancing : ModifyIpPools ModifyListenerAttributes SetRulePriorities + ec2 : DescribeIpamPools et ec2 : DescribeRouteTables + bouclier :CreateProtection, bouclier : DeleteProtection et bouclier : TagResource ## 9 juin 2026 **Fonctionnalité ** : Ajout de la surveillance de l'état des instances au mode EKS Auto. Le contrôleur informatique interroge désormais EC2 `DescribeInstanceStatus` pour détecter les événements de maintenance planifiés et les échecs de vérification de l'état de l'instance ou du système, remplaçant automatiquement les nœuds défectueux. ## 4 juin 2026 **Documentation ** : ajout de conseils sur le contrôle des coûts de calcul en mode automatique EKS, notamment sur le fonctionnement de la consolidation, les éléments qui la bloquent et les modèles recommandés pour les charges de travail en rafale. Pour plus d'informations, consultez la section Optimisation des [ coûts en mode automatique EKS](auto-cost-control.md). ## 3 juin 2026 **Fonctionnalité ** : Ajout de la prise en charge des réservations de capacité interruptible en mode automatique EKS. Pour plus d’informations, consultez [Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md). ## 5 mai 2026 **Fonctionnalité ** : Ajout de la prise en charge des groupes de placement EC2 en mode automatique EKS. Pour plus d’informations, consultez [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec). ## 10 avril 2026 **Nouveaux types d'instances pris en charge ** : p6-b200, p6-b300, p5e, p5en, trn2, hpc8a, x8aedz, x8i. Pour obtenir la liste complète des instances prises en charge, consultez[Informations sur les instances gérées par le mode automatique Amazon EKS](automode-learn-instances.md). ## 2 avril 2026 **Corvée ** : la validation à NodeClass sec utilisera désormais des types d'instances sélectionnés dynamiquement en fonction des liens NodePools. ## 2 février 2026 **Fonctionnalité ** : Ajout de la prise en charge de la désactivation du trafic v4egress provenant des pods IPv6 dans les clusters IPv6 en mode automatique EKS. Pour plus d’informations, consultez [Désactivez la sortie IPv4 depuis les pods IPv6 dans les clusters IPv6.](create-node-class.md#enableV4Egress). ## 19 décembre 2025 **Fonctionnalité ** : Ajout de la prise en charge du mode IP secondaire qui fournit des adresses IP secondaires au lieu de préfixes aux nœuds automatiques. Le mode conserve une adresse IP secondaire sous la forme MinimalIPTarget et permet d'économiser des ressources IP pour les clients qui n'ont pas besoin de configurer d'autres adresses IP ou préfixes secondaires. Pour plus d’informations, consultez [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec) et [Mode IP secondaire pour les pods](create-node-class.md#secondary-IP-mode). ## 19 novembre 2025 **Fonctionnalité ** : Activation de l'extraction et du déballage parallèles Seekable OCI (SOCI) pour les instances des familles G, P et Trn avec stockage NVMe local. L'extraction et le décompression parallèles SOCI sont toujours utilisés pour ces familles d'instances avec le mode EKS Auto et aucune modification de configuration n'est requise pour l'activer. Pour plus d'informations sur SOCI, consultez le blog [ de ](https://aws.amazon.com/blogs/containers/introducing-seekable-oci-parallel-pull-mode-for-amazon-eks/) lancement. ## 19 novembre 2025 **Fonctionnalité ** : Ajout de la prise en charge des pools de nœuds à capacité statique qui maintiennent un nombre fixe de nœuds. Pour plus d’informations, consultez [Pools de nœuds à capacité statique en mode automatique EKS](auto-static-capacity.md). ## 23 octobre 2025 **Fonctionnalité : ** Les utilisateurs possédant des clusters dans les régions des États-Unis peuvent désormais demander à utiliser des AMI compatibles FIPS en le spécifiant `spec.advancedSecurity.fips` dans leur NodeClass définition. ## 1er octobre 2025 **Fonctionnalité : Le mode automatique ** EKS prend désormais en charge le déploiement de nœuds dans AWS des zones locales. Pour plus d’informations, consultez [Déployer des nœuds EKS Auto Mode sur des Zones Locales](auto-local-zone.md). ## 30 septembre 2025 **Fonctionnalité : ** Ajout du support pour InstanceProfile NodeClass `spec.instanceProfile`, qui s'exclut mutuellement du `spec.role` terrain. ## 29 septembre 2025 Le DRA n'est actuellement pas pris en charge par le mode automatique EKS. ## 10 septembre 2025 **Tâche d’entretien :** les événements déclenchés par le contrôleur de calcul en mode automatique utiliseront désormais le nom `eks-auto-mode/compute` au lieu de `karpenter`. ## 24 août 2025 **Correction de bogue :** les VPC utilisant un jeu d’options DHCP avec un nom de domaine personnalisé contenant des lettres majuscules empêchaient les nœuds de rejoindre le cluster, car cela générait un nom d’hôte invalide. Ce problème est désormais résolu : les noms de domaine contenant des majuscules fonctionnent correctement. ## 15 août 2025 **Correction de bogue :** l’agent d’identité du pod écoute désormais uniquement sur l’adresse IPv4 Link-Local dans un cluster EKS IPv4, afin d’éviter les problèmes où le pod ne pouvait pas atteindre l’adresse IPv6. ## 6 août 2025 **Fonctionnalité : ** Ajout d'une nouvelle configuration NodeClass `spec.advancedNetworking.associatePublicIPAddress` qui peut être utilisée pour empêcher l'attribution d'adresses IP publiques aux nœuds en mode automatique EKS ## 30 juin 2025 **Fonctionnalité : ** Le mode automatique utilise NodeClass désormais la clé KMS personnalisée configurée pour chiffrer le volume racine en lecture seule de l'instance, en plus du read/write volume de données. Auparavant, la clé KMS personnalisée ne servait qu’au chiffrement du volume de données. ## 20 juin 2025 **Fonctionnalité : ** prise en charge du contrôle du déploiement des charges de travail dans les réservations de On-Demand capacité EC2 (ODCR). Cela ajoute la touche optionnelle `capacityReservationSelectorTerms` à la NodeClass, vous permettant de contrôler explicitement les ODCR que vos charges de travail utilisent. Pour plus d’informations, consultez [Contrôle du déploiement des charges de travail dans les réserves de capacité avec le mode automatique EKS](auto-odcr.md). ## 13 juin 2025 **Caractéristique :** prise en charge de sous-réseaux de pods distincts dans la `NodeClass`. Cela ajoute les clés facultatives `podSubnetSelectorTerms` et `podSecurityGroupSelectorTerms` permettant de définir les sous-réseaux et les groupes de sécurité pour les pods. Pour plus d’informations, consultez [Sous-réseaux et groupes de sécurité distincts pour les Pods](create-node-class.md#pod-subnet-selector). ## 30 avril 2025 **Caractéristique :** prise en charge des serveurs proxy réseau sortant dans la `NodeClass`. Cela ajoute la clé facultative `advancedNetworking` permettant de configurer votre proxy HTTPS. Pour plus d’informations, consultez [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec). ## 18 avril 2025 **Caractéristique :** prise en charge de la résolution des domaines .local (habituellement réservés au Multicast DNS) via DNS unicast. ## 11 avril 2025 **Caractéristique :** ajout des paramètres `certificateBundles` et `ephemeralStorage.kmsKeyID` à `NodeClass`. Pour plus d’informations, consultez [Spécification de la classe de nœuds](create-node-class.md#auto-node-class-spec). **Caractéristique :** amélioration de la vitesse d’extraction des images, en particulier pour les types d’instances disposant d’un stockage local permettant une décompression plus rapide des images. **Correction d'un bug : ** résolution d'un problème de concurrence qui provoquait FailedCreatePodSandBox une erreur lors de la numérotation : composez le numéro tcp 127.0.0. 1:50051 : connect : la connexion refusée se produisait parfois pour les Pods planifiant vers un nœud immédiatement au démarrage. ## 4 avril 2025 **Caractéristique :** augmentation de `registryPullQPS` de 5 à 25 et de `registryBurst` de 10 à 50 pour réduire la limitation de débit appliquée côté client lors de l’extraction des images (`Failed to pull image xyz: pull QPS exceeded`) ## 31 mars 2025 **Correction de bogue :** résolution d’un problème où, si un pod CoreDNS s’exécutait sur un nœud du mode automatique, les requêtes DNS des pods de ce nœud étaient envoyées à ce pod CoreDNS au lieu du serveur DNS local du nœud. Désormais, les requêtes DNS provenant de pods sur un nœud du mode automatique sont systématiquement dirigées vers le DNS local du nœud. ## 21 mars 2025 **Correction de bogue :** les nœuds du mode automatique résolvent désormais correctement le domaine `kube-dns.kube-system.svc.cluster.local` lorsqu’aucun service `kube-dns` n’est installé dans le cluster. Résout GitHub le problème [ \#2546](https://github.com/aws/containers-roadmap/issues/2546). ## 14 mars 2025 **Caractéristique** : activation de la sortie `IPv4` dans les clusters `IPv6`. Le trafic `IPv4` sortant depuis les clusters du mode automatique `IPv6` est désormais automatiquement traduit vers l’adresse `v4` de l’ENI primaire du nœud.