Aidez à améliorer cette page
Vous souhaitez contribuer à ce guide de l'utilisateur ? Faites défiler cette page vers le bas et sélectionnez Modifier cette page sur GitHub. Vos contributions aideront à améliorer notre guide de l'utilisateur pour tous.
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 nouvelleAMI. 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 passer à la dernière version d'Amazon EKS optimisée AMI pour un appareil existant Kubernetes version.
Important
Cette rubrique couvre les mises à jour des nœuds pour les groupes de nœuds autogérés. Pour obtenir des informations sur l'utilisation d'Simplifiez le cycle de vie des nœuds avec des groupes de nœuds gérés, veuillez consulter Mettre à jour un groupe de nœuds gérés pour votre cluster.
Le dernier AWS CloudFormation modèle de EKS nœud Amazon par défaut est configuré pour lancer une instance avec le nouveau AMI dans votre cluster avant de supprimer l'ancien, un par un. Cette configuration permet de garantir que vous disposez toujours du nombre d'instances actives souhaité de votre groupe Auto Scaling dans votre cluster lors de la propagation des mises à jour.
Note
Cette méthode n'est pas prise en charge pour les groupes de nœud créés avec eksctl
. 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.
Pour mettre à jour un groupe de nœuds existant
-
Déterminez le DNS fournisseur 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 DNS résolution, mais il se peut que votre cluster revienne à la
kube-dns
place. Votre sortie peut être différente selon la version dekubectl
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
aveccordens
si votre sortie de commande précédente le renvoyait à la place.kube-dns
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 actuel de nœuds. 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 à l'adresse https://console.aws.amazon.com/cloudformation.
-
Sélectionnez votre pile de groupe de nœuds, puis choisissez Update (Mettre à jour).
-
Sélectionnez Remplacer le modèle actuel, puis Amazon S3 URL.
-
Pour Amazon S3 URL, collez ce qui suit URL 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 type d'instance, consultez Choisissez un type d'instance de EC2 nœud Amazon optimal. Chaque type d'EC2instance 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 de Amazon VPC CNI plugin for Kubernetes
sont affiché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 Amazon VPC CNI. Important
Certains types d'instances peuvent ne pas être disponibles dans tous les cas Régions AWS.
-
NodeImageIdSSMParam— Le paramètre Amazon EC2 Systems Manager de l'AMIID que vous souhaitez mettre à jour. La valeur suivante utilise la dernière version d'Amazon EKS optimisée AMI pour Kubernetes version
1.31
./aws/service/eks/optimized-ami/
1.31
/amazon-linux-2
/recommended/image_idVous pouvez le
remplacer par un support Kubernetes version 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 le1.31
remplacer par un autre AMI type. Pour de plus amples informations, veuillez consulter Récupérez le système Amazon Linux recommandé AMI IDs.amazon-linux-2
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 AMI identifiant. Si votre AWS CloudFormation pile utilise cette valeur, toute mise à jour de la pile lance toujours la dernière version recommandée d'Amazon, EKS optimisée AMI pour votre compte Kubernetes version. C'est le cas même si vous ne modifiez aucune valeur dans le modèle.
-
NodeImageId— Pour utiliser votre propre personnalisationAMI, entrez l'identifiant 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 isableIMDSv 1 — Par défaut, chaque nœud prend en charge les versions 1 du service de métadonnées d'instance (IMDSv1) etIMDSv2. Cependant, vous pouvez le désactiverIMDSv1. Sélectionnez vrai si vous ne voulez aucun nœud ou aucun Pods planifié dans le groupe de nœuds à utiliserIMDSv1. Pour plus d'informationsIMDS, consultez la section Configuration du service de métadonnées d'instance. Si vous avez implémenté IAM des rôles 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 y accéder IMDS pour d'autres raisons, telles que la récupération du courant Région 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 Révision, passez en revue vos informations, reconnaissez que la pile est susceptible de créer IAM des ressources, puis choisissez 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 DNS fournisseur 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 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 Amazon VPC CNI plugin for 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 Amazon VPC CNI.