Comprendre le cycle de vie des versions de Kubernetes sur EKS

Conformément au support de la communauté Kubernetes pour les versions Kubernetes, Amazon EKS s’engage à offrir un support pour au moins trois versions Kubernetes à tout moment. Nous annoncerons la date de fin du support standard d’une version mineure donnée de Kubernetes au moins 60 jours à l’avance. En raison du processus de qualification et de publication d’Amazon EKS pour les nouvelles versions de Kubernetes, la date de fin du support standard d’une version de Kubernetes sur Amazon EKS sera postérieure à la date à laquelle le projet Kubernetes cessera de prendre en charge la version en amont.

Une version de Kubernetes bénéficie du support standard pendant 14 mois après sa première mise à disposition sur Amazon EKS. Cela vaut même si Kubernetes en amont ne prend plus en charge une version disponible sur Amazon EKS. Nous rétroportons les correctifs de sécurité applicables aux versions de Kubernetes prises en charge sur Amazon EKS.

Oui. Si l'un des clusters de votre compte exécute la version dont le support approche de la fin, Amazon EKS envoie une notification via le AWS Health Dashboard environ 12 mois après la sortie de la version Kubernetes sur Amazon EKS. L'avis indique la date de fin de la prise en charge. Le délai est d'au moins 60 jours à compter de la date de l'avis.

Amazon EKS prend en charge toutes les fonctionnalités disponibles pour tous (GA) de l’API Kubernetes. Les nouvelles versions bêta APIs ne sont pas activées dans les clusters par défaut. Cependant, la version bêta existante APIs et les nouvelles versions de la version bêta existante APIs continuent d'être activées par défaut. Les fonctionnalités alpha ne sont pas prises en charge.

Non. Un groupe de nœuds géré crée des EC2 instances Amazon dans votre compte. Ces instances ne sont pas automatiquement mises à niveau lorsque vous ou Amazon EKS mettez à jour votre plan de contrôle. Pour de plus amples informations, veuillez consulter Mettre à jour un groupe de nœuds gérés pour votre cluster. Nous vous recommandons de conserver la même version Kubernetes sur votre plan de contrôle et vos nœuds.

Non. Un groupe de nœuds autogéré inclut des EC2 instances Amazon dans votre compte. Ces instances ne sont pas mises à niveau automatiquement lorsque la version du plan de contrôle est mise à jour par vous ou par Amazon EKS en votre nom. Un groupe de nœuds autogérés n’a aucune indication dans la console qu’il doit être mis à jour. Vous pouvez afficher la version kubelet installée sur un nœud en sélectionnant le nœud dans la boîte de dialogue Nœuds dans la Présentation de votre cluster pour déterminer quels nœuds doivent être mis à jour. Vous devez mettre à jour les nœuds manuellement. Pour de plus amples informations, veuillez consulter Mettez à jour les nœuds autogérés de votre cluster.

Le projet Kubernetes teste la compatibilité entre le plan de contrôle et les nœuds pour un maximum de trois versions mineures. Par exemple, les nœuds 1.30 continuent à fonctionner tant qu'ils sont orchestrés par un plan de contrôle 1.33. Cependant, il n’est pas recommandé d’exécuter un cluster avec des nœuds qui ont trois versions mineures de retard par rapport au plan de contrôle. Pour plus d'informations, consultez Version Kubernetes et politique de prise en charge d'asymétrie de version dans la documentation Kubernetes. Nous vous recommandons de conserver la même version Kubernetes sur votre plan de contrôle et vos nœuds.

Non. Nous recommandons fortement d’exécuter les pods Fargate dans le cadre d’un contrôleur de réplication, tel qu’un déploiement Kubernetes. Procédez ensuite à un redémarrage progressif de tous les pods Fargate. La nouvelle version du pod Fargate est déployée avec une version kubelet identique à celle de votre plan de contrôle de cluster mis à jour. Pour plus d'informations, consultez Déploiements dans la documentation Kubernetes.

Les nœuds hybrides Amazon EKS prennent en charge les mêmes versions de Kubernetes que les clusters Amazon EKS avec d’autres types de nœuds de calcul, y compris la prise en charge des versions standard et étendues de Kubernetes. Les nœuds hybrides ne sont pas automatiquement mis à niveau lorsque vous mettez à niveau votre version de plan de contrôle et vous êtes responsable de la mise à niveau de vos nœuds hybrides. Pour de plus amples informations, veuillez consulter Mettre à niveau les nœuds hybrides pour votre cluster.

Le support standard d’une version Kubernetes dans Amazon EKS commence lorsqu’Amazon EKS publie une version Kubernetes et prend fin 14 mois après la date de publication. Le support étendu pour une version Kubernetes commence immédiatement après la fin du support standard et prend fin 12 mois plus tard. Par exemple, le support standard pour la version 1.23 dans Amazon EKS a pris fin le 11 octobre 2023. Le support étendu pour la version 1.23 a commencé le 12 octobre 2023 et a pris fin le 11 octobre 2024.

Vous devrez activer le support étendu (voir Support étendu EKS) pour votre cluster en modifiant la politique de mise à niveau du cluster sur EXTENDED. Par défaut, pour tous les clusters nouveaux et existants, la politique de mise à niveau est définie sur EXTENDED, sauf indication contraire. Consultez Politique de mise à niveau des clusters pour connaître la politique de mise à niveau de votre cluster. Le support standard commencera lorsqu’Amazon EKS publiera une version de Kubernetes et prendra fin 14 mois après la date de publication. Le support étendu pour une version Kubernetes commence immédiatement après la fin du support standard et prend fin 12 mois plus tard.

Vous pouvez exécuter des clusters sur n'importe quelle version jusqu'à 12 mois après la fin du support standard pour cette version. Cela signifie que chaque version sera prise en charge pendant 26 mois dans Amazon EKS (14 mois de support standard plus 12 mois de support étendu).

Si vous ne voulez pas être automatiquement inscrit au support étendu, vous pouvez mettre à niveau votre cluster vers une version Kubernetes bénéficiant du support standard Amazon EKS. Pour désactiver le support étendu, consultez Désactiver le support étendu EKS. Remarque : si vous désactivez le support étendu, Amazon EKS mettra automatiquement à niveau votre cluster à la fin du support standard.

Amazon EKS mettra automatiquement à niveau vers la version suivante les clusters fonctionnant sur une version Kubernetes dont le cycle de vie de 26 mois (14 mois de support standard plus 12 mois de support étendu) est terminé. La mise à niveau automatique ne concerne que le plan de contrôle Kubernetes. Si vous disposez de nœuds du mode automatique EKS, ceux-ci peuvent être mis à jour automatiquement. Les nœuds autogérés et les groupes de nœuds gérés EKS resteront sur la version précédente.

Passé la date de fin de la période de support étendu, vous ne pouvez plus créer de nouveaux clusters Amazon EKS avec la version non prise en charge. Les plans de contrôle existants sont automatiquement mis à jour par Amazon EKS vers la version prise en charge la plus récente, par le biais d'un processus de déploiement progressif après la date de fin de la prise en charge. Après la mise à jour automatique du plan de contrôle, veillez à mettre à jour manuellement les modules complémentaires du cluster et EC2 les nœuds Amazon. Pour de plus amples informations, veuillez consulter Mettre à jour un cluster existant vers une nouvelle version de Kubernetes.

Amazon EKS n’est pas en mesure de fournir de délais précis. Les mises à jour automatiques peuvent intervenir à tout moment après la date de fin de la période de support étendu. Vous ne recevrez aucune notification avant la mise à jour. Nous vous recommandons de mettre à jour, de manière proactive, votre plan de contrôle sans vous fier au processus de mise à jour automatique Amazon EKS. Pour de plus amples informations, veuillez consulter Mettre à jour un cluster existant vers une nouvelle version de Kubernetes.

Non. La sécurité du cloud AWS est la priorité absolue. Au-delà d’un certain délai (généralement un an), la communauté Kubernetes cesse de publier des correctifs pour les vulnérabilités et expositions courantes (CVE) et décourage la soumission de CVE pour les versions non prises en charge. Cela signifie que les vulnérabilités spécifiques à une ancienne version de Kubernetes pourraient ne même pas être signalées. Les clusters sont dès lors exposés sans préavis et aucune option de remédiation en cas de vulnérabilité n'est possible. Dans ce contexte, Amazon EKS n’autorise pas les plans de contrôle à rester sur une version qui a atteint la fin du support étendu.

Oui, il y a un coût supplémentaire pour les clusters Amazon EKS fonctionnant sous support étendu. Pour en savoir plus sur les tarifs, consultez le support étendu d'Amazon EKS pour la tarification des versions Kubernetes sur le AWS blog ou sur notre page de tarification.

Les clusters Amazon EKS sous support étendu bénéficient de l’application de correctifs de sécurité continus pour le plan de contrôle Kubernetes. De plus, Amazon EKS publiera des correctifs pour les modules complémentaires CNI Amazon VPC, kube-proxy et CoreDNS pour les versions bénéficiant d’un support étendu. Amazon EKS publiera également des correctifs pour les versions AWS publiées d'Amazon EKS optimisées AMIs pour Amazon Linux, Bottlerocket et Windows, ainsi que pour les nœuds Amazon EKS Fargate pour ces versions. Tous les clusters concernés par le Support étendu continueront d'avoir accès au support technique auprès de AWS.

Bien que le support étendu couvre tous les composants spécifiques de Kubernetes AWS, il ne fournira à tout moment qu'un support pour AWS Amazon EKS publié et optimisé pour AMIs Amazon Linux, Bottlerocket et Windows. Cela signifie que vous aurez potentiellement de nouveaux composants (système d'exploitation ou noyau, par exemple) sur votre AMI optimisée pour Amazon EKS lorsque vous utiliserez le support étendu. Par exemple, une fois qu'Amazon Linux 2 aura atteint la fin de son cycle de vie en 2025, Amazon Linux optimisé pour Amazon EKS AMIs sera développé à l'aide d'un système d'exploitation Amazon Linux plus récent. Amazon EKS annoncera et documentera les divergences importantes en matière de cycle de vie du support, telles que celle-ci, pour chaque version de Kubernetes.

Oui.