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.
Vous souhaitez contribuer à ce guide de l'utilisateur ? Choisissez le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tout le monde.
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.
Mettre à jour une pile de AWS CloudFormation nœuds
Cette rubrique décrit comment mettre à jour une pile de nœuds AWS CloudFormation autogérés existante avec une nouvelle AMI. Vous pouvez utiliser cette procédure pour mettre à jour vos nœuds vers une nouvelle version de Kubernetes suite à une mise à jour du cluster. Sinon, vous pouvez effectuer la mise à jour vers la dernière AMI optimisée pour Amazon EKS pour une application existante Kubernetes version.
Important
Cette rubrique couvre les mises à jour des nœuds pour les groupes de nœuds autogérés. Pour plus d'informations sur l'utilisation de Simplifier le cycle de vie des nœuds avec des groupes de nœuds gérés, consultezMettre à jour un groupe de nœuds gérés pour votre cluster.
Le dernier AWS CloudFormation modèle de nœud Amazon EKS par défaut est configuré pour lancer une instance avec la nouvelle AMI dans votre cluster avant de supprimer l'ancienne, une par une. Cette configuration garantit que vous disposez toujours du nombre d'instances actives souhaité par votre groupe Auto Scaling dans votre cluster lors de la mise à jour continue.
Note
Cette méthode n'est pas prise en charge pour les groupes de nœuds créés aveceksctl
. Si vous avez créé votre cluster ou votre groupe de nœuds avec eksctl
, consultez Migrer les applications vers un nouveau groupe de nœuds.
-
Déterminez le fournisseur DNS de votre cluster.
kubectl get deployments -l k8s-app=kube-dns -n kube-system
L'exemple qui suit illustre un résultat. Ce cluster utilise CoreDNS pour la résolution DNS, mais votre cluster peut revenir à la
kube-dns
place. Votre sortie peut sembler différente selon la versionkubectl
que vous utilisez.NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m
-
Si votre déploiement actuel exécute moins de deux réplicas, dimensionnez le déploiement à deux réplicas. Remplacez
coredns
parkube-dns
si la sortie de votre commande a plutôt renvoyé cette valeur.kubectl scale deployments/coredns --replicas=2 -n kube-system
-
(Facultatif) Si vous utilisez le Kubernetes Cluster Autoscaler
, réduisez le déploiement à zéro (0) répliques pour éviter des actions de dimensionnement contradictoires. kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system
-
Déterminez le type d'instance et le nombre d'instances souhaité pour votre groupe de nœuds actuel. Vous saisirez ces valeurs ultérieurement lorsque vous mettrez à jour le AWS CloudFormation modèle du groupe.
-
Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/
. -
Dans le panneau de navigation de gauche, sélectionnez Launch Configurations (Configurations du lancement) et notez le type d'instance pour votre configuration actuelle de lancement des nœuds.
-
Dans le panneau de navigation de gauche, sélectionnez Auto Scaling Groups (Groupes Auto Scaling) et notez le nombre d'instances souhaité pour le groupe Auto Scaling actuel des nœuds.
-
-
Ouvrez la AWS CloudFormation console
. -
Sélectionnez votre pile de groupe de nœuds, puis choisissez Update (Mettre à jour).
-
Sélectionnez Replace current template (Remplacer le modèle actuel) et sélectionnez Amazon S3 URL (URL Amazon S3).
-
Pour l'URL Amazon S3, collez l'URL suivante dans la zone de texte pour vous assurer que vous utilisez la dernière version du AWS CloudFormation modèle de nœud. Ensuite, sélectionnez Next (Suivant) :
https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml
-
Sur la page Specify stack details (Spécifier les détails de la pile), renseignez les paramètres suivants, puis choisissez Next (Suivant) :
-
NodeAutoScalingGroupDesiredCapacity— Entrez le nombre d'instances souhaité que vous avez enregistré lors d'une étape précédente. Ou saisissez le nouveau nombre de nœuds souhaité pour la mise à l'échelle lorsque votre pile sera mise à jour.
-
NodeAutoScalingGroupMaxSize— Entrez le nombre maximum de nœuds auxquels votre groupe Auto Scaling de nœuds peut s'étendre. Cette valeur doit être supérieure d'au moins un nœud à votre capacité souhaitée. Ceci afin de pouvoir effectuer une mise à jour continue de vos nœuds sans réduire votre nombre de nœuds pendant la mise à jour.
-
NodeInstanceType— Choisissez le type d'instance que vous avez enregistré à l'étape précédente. Vous pouvez également choisir un type d'instance différent pour vos nœuds. Avant de choisir un autre type d'instance, consultez Choisir un type d'instance de EC2 nœud Amazon optimal. Chaque type d' EC2 instance Amazon prend en charge un nombre maximum d'interfaces réseau élastiques (interface réseau) et chaque interface réseau prend en charge un nombre maximum d'adresses IP. Parce que chaque nœud de travail et Pod , se voit attribuer sa propre adresse IP, il est important de choisir un type d'instance qui prendra en charge le nombre maximum de Pods que vous souhaitez exécuter sur chaque EC2 nœud Amazon. Pour une liste du nombre d'interfaces réseau et d'adresses IP pris en charge par les types d'instances, consultez adresses IP par interface réseau et par type d'instance. Par exemple, le type d'
m5.large
instance prend en charge un maximum de 30 adresses IP pour le nœud de travail et Pods.Note
Les types d'instances pris en charge pour la dernière version du plugin Amazon VPC CNI pour Kubernetes sont présentés dans vpc_ip_resource_limit.go
sur GitHub. Vous devrez peut-être mettre à jour votre Amazon VPC CNI plugin for Kubernetes version pour utiliser les derniers types d'instances pris en charge. Pour de plus amples informations, veuillez consulter Attribuer IPs à Pods avec le Amazon VPC CNI. Important
Certains types d'instances peuvent ne pas être disponibles dans toutes les AWS régions.
-
NodeImageIdSSMParam— Le paramètre Amazon EC2 Systems Manager de l'ID AMI vers lequel vous souhaitez effectuer la mise à jour. La valeur suivante utilise la dernière AMI optimisée pour Amazon EKS pour Kubernetes version
1.31
./aws/service/eks/optimized-ami/1.31/amazon-linux-2/recommended/image_id
Vous pouvez le
1.31
remplacer par une version compatible de Kubernetes identique. Ou bien, il doit s'agir d'une version antérieure à Kubernetes version exécutée sur votre plan de contrôle. Nous vous recommandons de conserver vos nœuds dans la même version que votre plan de contrôle. Vous pouvez également le remplaceramazon-linux-2
par un autre type d'AMI. Pour de plus amples informations, veuillez consulter Récupérez l'AMI Amazon Linux recommandée IDs.Note
L'utilisation du paramètre Amazon EC2 Systems Manager vous permet de mettre à jour vos nœuds à l'avenir sans avoir à rechercher et à spécifier un ID AMI. Si votre AWS CloudFormation pile utilise cette valeur, toute mise à jour de la pile lance toujours l'AMI optimisée Amazon EKS la plus récente recommandée pour votre compte Kubernetes version. C'est même le cas même si vous ne modifiez aucune valeur dans le modèle.
-
NodeImageId— Pour utiliser votre propre AMI personnalisée, entrez l'ID de l'AMI à utiliser.
Important
Cette valeur remplace toute valeur spécifiée pour NodeImageIdSSMParam. Si vous souhaitez utiliser la NodeImageIdSSMParamvaleur, assurez-vous que la valeur pour NodeImageIdest vide.
-
Désactiver IMDSv1 : par défaut, chaque nœud prend en charge les versions 1 du service de métadonnées d'instance (IMDSv1) et IMDSv2. Cependant, vous pouvez le désactiver IMDSv1. Sélectionnez vrai si vous ne voulez aucun nœud ou aucun Pods planifié dans le groupe de nœuds à utiliser IMDSv1. Pour de plus amples informations au sujet d'IMDS, consultez Configuration du service des métadonnées d'instance. Si vous avez implémenté des rôles IAM pour les comptes de service, attribuez les autorisations nécessaires directement à tous Pods qui nécessitent un accès aux AWS services. De cette façon, non Pods dans votre cluster, vous devez accéder à l'IMDS pour d'autres raisons, telles que la récupération de la région actuelle AWS . Ensuite, vous pouvez également désactiver l'accès IMDSv2 à Pods qui n'utilisent pas le réseau hôte. Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master
.
-
-
(Facultatif) Sur la page Options (Options), étiquetez les ressources de votre pile. Choisissez Next (Suivant).
-
Sur la page Review (Vérification), vérifiez vos informations, acceptez que la pile puisse créer des ressources IAM, puis choisissez Update stack (Mettre à jour la pile).
Note
La mise à jour de chaque nœud du cluster prend plusieurs minutes. Attendez que la mise à jour de tous les nœuds soit terminée avant d'effectuer les étapes suivantes.
-
Si le fournisseur DNS de votre cluster l'est
kube-dns
, adaptez lekube-dns
déploiement à une seule réplique.kubectl scale deployments/kube-dns --replicas=1 -n kube-system
-
(Facultatif) Si vous utilisez le Kubernetes Cluster Autoscaler
, réduisez le déploiement à la quantité de répliques souhaitée. kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system
-
(Facultatif) Vérifiez que vous utilisez la dernière version du plugin Amazon VPC CNI
pour Kubernetes. Vous devrez peut-être mettre à jour votre Amazon VPC CNI plugin for Kubernetes version pour utiliser les derniers types d'instances pris en charge. Pour de plus amples informations, veuillez consulter Attribuer IPs à Pods avec le Amazon VPC CNI.