Mise à jour d'une version Kubernetes de cluster Amazon EKS
Dès qu'une nouvelle version Kubernetes est disponible dans Amazon EKS, vous pouvez mettre à jour votre cluster Amazon EKS vers la version la plus récente.
Important
Une fois que vous avez mis à niveau un cluster, vous ne pouvez pas le rétrograder vers une version antérieure. Nous vous recommandons, avant de mettre à jour vers une nouvelle version de Kubernetes, de consulter les informations dans Versions Kubernetes Amazon EKS et également de consulter les étapes de mise à jour de cette rubrique.
Les nouvelles versions de Kubernetes introduisent parfois des modifications importantes. Nous vous recommandons donc de tester le comportement de vos applications par rapport à la nouvelle version de Kubernetes avant de procéder à la mise à jour sur vos clusters de production. Pour ce faire, créez un flux d'intégration continue afin de tester le comportement de votre application avant de passer à une nouvelle version Kubernetes.
Dans le processus de mise à jour, Amazon EKS lance de nouveaux nœuds de serveur d'API avec la version de Kubernetes mise à jour pour remplacer les versions existantes. Amazon EKS effectue des surveillances de l'état de disponibilité et de l'infrastructure standard pour le trafic réseau sur ces nouveaux nœuds pour vérifier qu'ils fonctionnent comme prévu. Cependant, une fois que vous avez commencé la mise à niveau du cluster, vous ne pouvez ni la suspendre ni l'arrêter. Si l'une de ces vérifications échoue, Amazon EKS annule le déploiement de l'infrastructure, et votre cluster reste dans la version Kubernetes précédente. Les applications en cours d'exécution ne sont pas affectées, et votre cluster n'est jamais laissé dans un état non déterministe ou irrécupérable. Amazon EKS sauvegarde régulièrement tous les clusters gérés, et des mécanismes existent pour récupérer des clusters si nécessaire. Nous évaluons et améliorons en permanence nos processus de gestion de l'infrastructure Kubernetes.
Pour mettre à jour le cluster, Amazon EKS requiert jusqu'à cinq adresses IP disponibles correspondant aux sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Amazon EKS crée de nouvelles interfaces réseau élastiques de cluster (interfaces réseau) dans l'un des sous-réseaux que vous avez spécifiés. Les interfaces réseau peuvent être créées dans des sous-réseaux différents de ceux dans lesquels se trouvent vos interfaces réseau existantes. Assurez-vous donc que les règles de votre groupe de sécurité autorisent la communication de cluster requise pour tous les sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Si l'un des sous-réseaux que vous avez spécifiés lors de la création du cluster n'existe pas, ne dispose pas de suffisamment d'adresses IP disponibles ou de règles de groupe de sécurité permettant la communication nécessaire avec le cluster, la mise à jour peut échouer.
Note
Afin d'assurer une disponibilité constante du point de terminaison du serveur d'API de votre cluster, Amazon EKS déploie un plan de contrôle Kubernetes hautement disponible et effectue des mises à jour continues des instances du serveur d'API pendant les opérations de mise à jour. Afin de tenir compte des modifications d'adresses IP des instances de serveurs d'API qui prennent en charge votre point de terminaison de serveur d'API Kubernetes, il est important de vous assurer que les clients de votre serveur d'API gèrent les reconnexions de manière efficace. Les versions récentes de kubectl
et les bibliothèques
Mise à jour de la version Kubernetes de votre cluster Amazon EKS
Pour mettre à jour la version Kubernetes de votre cluster
-
Comparez la version Kubernetes de votre plan de contrôle de cluster à la version Kubernetes de vos nœuds.
-
Obtenez la version Kubernetes du plan de contrôle de votre cluster.
kubectl version
-
Obtenez la version Kubernetes de vos nœuds. Cette commande renvoie tous les nœuds Amazon EC2 et Fargate autogérés et gérés. Chaque Pod Fargate est répertorié comme son propre nœud.
kubectl get nodes
Avant de mettre à jour votre plan de contrôle vers une nouvelle version de Kubernetes, assurez-vous que la version mineure de Kubernetes des nœuds gérés et des nœuds Fargate de votre cluster est identique à la version de votre plan de contrôle. Par exemple, si votre plan de contrôle exécute la version
1.27
et que l'un de vos nœuds exécute la version1.26
, vous devez mettre à jour vos nœuds vers la version1.27
avant de mettre à jour votre plan de contrôle vers la version 1.28. Nous vous recommandons également de mettre à jour vos nœuds autogérés vers la même version que votre plan de contrôle avant de mettre à jour le plan de contrôle. Pour plus d'informations, consultez Mise à jour d'un groupe de nœuds gérés et Mises à jour des nœuds autogérés. Si vous avez des nœuds Fargate dont la version mineure est inférieure à la version du plan de contrôle, supprimez d'abord le Pod représenté par le nœud. Mettez ensuite à jour votre plan de contrôle. Tous les Pods restants seront mis à jour vers la nouvelle version une fois que vous les aurez redéployés. -
-
Si la version de Kubernetes avec laquelle vous avez initialement déployé votre cluster était Kubernetes version
1.25
ou ultérieure, ignorez cette étape.Par défaut, le contrôleur d'admission de politique de sécurité du Pod est activé sur les clusters Amazon EKS. Avant de mettre à jour votre cluster, assurez-vous que des politiques de sécurité de Pod appropriées sont en place. Il s'agit ainsi d'éviter les problèmes de sécurité potentiels. Vous pouvez vérifier la politique par défaut à l'aide de la commande
kubectl get psp eks.privileged
.kubectl get psp eks.privileged
Si vous recevez l'erreur suivante, veuillez consulter Stratégie de sécurité de Pod Amazon EKS par défaut avant de continuer.
Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found
-
Si la version de Kubernetes avec laquelle vous avez initialement déployé votre cluster était Kubernetes version
1.18
ou ultérieure, ignorez cette étape.Vous devrez peut-être supprimer un terme abandonné de votre manifeste CoreDNS.
-
Vérifiez si votre manifeste CoreDNS a une ligne qui n'a que le mot
upstream
.kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream
Si aucune sortie n'est renvoyée, cela signifie que votre manifeste n'a pas la ligne. Dans ce cas, passez à l'étape suivante. Si le mot
upstream
est retourné, supprimez la ligne. -
Supprimez la ligne près du haut du fichier qui ne contient que le mot
upstream
dans le fichier configmap. Ne changez rien d'autre dans le fichier. Une fois la ligne supprimée, enregistrez les modifications.kubectl edit configmap coredns -n kube-system -o yaml
-
-
Mettez à jour votre cluster en utilisant
eksctl
, le AWS Management Console ou le AWS CLI.Important
-
Si vous effectuez une mise à jour vers la version
1.23
et utilisez des volumes Amazon EBS dans votre cluster, alors vous devez installer le pilote Amazon EBS CSI dans votre cluster avant de mettre celui-ci à jour vers la version1.23
afin d'éviter les perturbations liées à la charge de travail. Pour plus d'informations, consultez Kubernetes 1,23 et Pilote CSI Amazon EBS. -
Kubernetes
1.24
et versions ultérieures utilisentcontainerd
comme environnement d'exécution du conteneur par défaut. Si vous passez à l’exécutioncontainerd
et que vous avez déjà configuré Fluentd pour Container Insights, vous devez effectuer la migration de Fluentd vers Fluent Bit avant de mettre à jour votre cluster. Les analyseurs Fluentd sont configurés pour analyser uniquement les messages du journal au format JSON. Contrairement àdockerd
, l’exécution du conteneurcontainerd
a des messages de journal qui ne sont pas au format JSON. Si vous ne migrez pas vers Fluent Bit, certains des analyseurs Fluentd's configurés généreront un grand nombre d'erreurs à l'intérieur du conteneur Fluentd. Pour plus d'informations sur la migration, consultez Configurer Fluent Bit en tant que DaemonSet pour l'envoi de journaux à CloudWatch Logs. -
Dans la mesure où Amazon EKS exécute un plan de contrôle hautement disponible, vous devez mettre à jour une seule version mineure à la fois. Pour plus d'informations sur cette exigence, consultez Politique de prise en charge des versions et versions asymétriques de Kubernetes
. Supposez que la version actuelle de votre cluster soit la version 1.26
et que vous souhaitiez la mettre à jour vers la version1.28
. Vous devez d'abord mettre à jour la version1.26
de votre cluster vers la version1.27
, puis mettre à jour la version1.27
de votre cluster vers la version1.28
. -
Assurez-vous que le
kubelet
sur vos nœuds gérés et Fargate sont à la même version Kubernetes que votre plan de contrôle avant la mise à jour. Nous recommandons que vos nœuds autogérés soient à la même version que le plan de contrôle. Ils ne peuvent avoir qu'une seule version de retard sur la version actuelle du plan de contrôle. -
Si votre cluster est configuré avec une version d' Amazon VPC CNI plugin for Kubernetes antérieure à la version
1.8.0
, nous vous recommandons de mettre à jour le plugin à la dernière version avant de mettre à jour votre cluster. Pour mettre à jour le plugin, consultez Utilisation du module complémentaire Amazon VPC CNI plugin for Kubernetes Amazon EKS. -
Si vous mettez à jour votre cluster vers la version
1.25
ou vers une version ultérieure et que vous avez déployé le AWS Load Balancer Controller dans votre cluster, mettez à jour le contrôleur vers la version2.4.7
ou vers une version ultérieure avant de mettre à jour votre cluster vers la version1.25
. Pour plus d'informations, consultez les notes de mise à jour de Kubernetes1,25.
-
-
Une fois la mise à jour de votre cluster terminée, mettez à jour vos nœuds vers la même version mineure Kubernetes que celle de votre cluster mis à jour. Pour plus d'informations, consultez Mises à jour des nœuds autogérés et Mise à jour d'un groupe de nœuds gérés. Tous les nouveaux Pods lancés sur Fargate ont une version
kubelet
correspondant à la version de votre cluster. Les Pods Fargate existants ne sont pas modifiés. -
(Facultatif) Si vous avez déployé Kubernetes Cluster Autoscaler sur votre cluster avant de mettre à jour le cluster, mettez ce composant à jour vers la version la plus récente correspondant à la version majeure et mineure de Kubernetes vers laquelle vous avez effectué la mise à jour.
-
Ouvrez la page des versions
de Cluster Autoscaler dans un navigateur web et recherchez la dernière version de Cluster Autoscaler qui correspond aux versions majeure et mineure Kubernetes de votre cluster. Par exemple, si la version Kubernetes de votre cluster est 1.28
, recherchez la version la plus récente du Cluster Autoscaler qui commence par1.28
. Enregistrez le numéro de version sémantique (1.28.n
, par exemple) de cette version à utiliser à l'étape suivante. -
Identifiez l'image Cluster Autoscaler sur la version que vous avez enregistrée à l'étape précédente avec la commande suivante. Si nécessaire, remplacez
par votre propre valeur.1.28
.n
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:v
1.28
.n
-
-
(Clusters avec des nœuds GPU uniquement) Si votre cluster comporte des groupes de nœuds avec prise en charge de GPU (par exemple
p3.2xlarge
), vous devez mettre à jour le contrôleur DaemonSet du plugin de périphérique NVIDIA pour Kubernetessur votre cluster. Remplacez
par la version NVIDIA/k8s-device-pluginvX.X.X
souhaitée avant d'exécuter la commande suivante. kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/
vX.X.X
/nvidia-device-plugin.yml -
Mettez à jour les modules complémentaires Amazon VPC CNI plugin for Kubernetes, CoreDNS et
kube-proxy
. Nous vous recommandons de mettre à jour les modules complémentaires avec les versions minimales répertoriées dans les jetons de compte de service.-
Si vous utilisez des modules complémentaires Amazon EKS, dans la console Amazon EKS, sélectionnez Clusters, puis le nom du cluster que vous avez mis à jour dans le volet gauche. Les notifications s'affichent dans la console. Elles vous informent qu'une nouvelle version est disponible pour chaque module complémentaire disposant d'une mise à jour disponible. Pour mettre à jour un module complémentaire, sélectionnez l'onglet Add-ons (Modules complémentaires). Dans l'une des zones d'un module complémentaire dont une mise à jour est disponible, sélectionnez Update now (Mettre à jour maintenant), sélectionnez une version disponible, puis cliquez sur Update (Mise à jour).
-
Vous pouvez également utiliser la AWS CLI ou
eksctl
pour mettre à jour les modules complémentaires. Pour de plus amples informations, veuillez consulter Mise à jour d'un module complémentaire.
-
-
Si nécessaire, mettez à jour votre version de
kubectl
. Vous devez utiliser une versionkubectl
qui se situe à une différence de version mineure près du plan de contrôle de votre cluster Amazon EKS. Par exemple, un clientkubectl
1.27
doit utiliser des clusters Kubernetes,1.26
,1.27
et1.28
. Vous pouvez vérifier votre version installée à l'aide de la commande suivante.kubectl version --client