Mettre à jour une pile de nœuds AWS CloudFormation - Amazon EKS

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub qui se trouve dans le volet droit de chaque page.

Mettre à jour une pile de nœuds AWS CloudFormation

Cette rubrique décrit comment mettre à jour une pile de nœuds autogérée AWS CloudFormation 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 une mise à jour vers la dernière AMI optimisée pour Amazon EKS pour une version Kubernetes existante.

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, consultez Mettre à jour un groupe de nœuds gérés pour votre cluster.

Le dernier modèle AWS CloudFormation 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 souhaité d’instances actives de votre groupe Auto Scaling dans votre cluster pendant la mise à jour propagée.

Note

Cette méthode n’est pas prise en charge pour les groupes de nœuds créés avec eksctl. Si vous avez créé votre cluster ou votre groupe de nœuds avec eksctl, consultez Migrer des applications vers un nouveau groupe de nœuds.

  1. 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 renvoyer kube-dns à la place. Votre sortie peut être différente selon la version de kubectl que vous utilisez.

    NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
coredns   1         1         1            1           31m

  2. Si votre déploiement actuel exécute moins de deux réplicas, dimensionnez le déploiement à deux réplicas. Remplacez coredns par kube-dns si la sortie de votre commande a plutôt renvoyé cette valeur.

    kubectl scale deployments/coredns --replicas=2 -n kube-system

  3. (Facultatif) Si vous utilisez l’outil Cluster Autoscaler de Kubernetes, réduisez verticalement le déploiement à zéro (0) réplicas afin d’éviter tout conflit entre les actions de mise à l’échelle.

    kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system

  4. Déterminez le type d’instance et le nombre d’instances souhaité pour votre groupe de nœuds actuel. Vous entrerez ces valeurs ultérieurement, lorsque vous mettrez à jour le modèle AWS CloudFormation pour le groupe.

    1. Ouvrez la console Amazon EC2 à l’adresse https://console.aws.amazon.com/ec2/.

    2. 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.

    3. 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.

  5. Ouvrez la console AWS CloudFormation.

  6. Sélectionnez votre pile de groupe de nœuds, puis choisissez Update (Mettre à jour).

  7. Sélectionnez Replace current template (Remplacer le modèle actuel) et sélectionnez Amazon S3 URL (URL Amazon S3).

  8. Pour URL Amazon S3, collez l’URL suivante dans la zone de texte afin de vous assurer que vous utilisez la dernière version du modèle AWS CloudFormation du nœud. Ensuite, sélectionnez Next (Suivant) :

    https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml

  9. Sur la page Specify stack details (Spécifier les détails de la pile), renseignez les paramètres suivants, puis choisissez Next (Suivant) :

    • NodeAutoScalingGroupDesiredCapacity : saisissez le nombre d'instances souhaité que vous avez noté dans 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 : saisissez le nombre maximum de nœuds que votre groupe Auto Scaling de nœuds peut comporter. 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 noté à une é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 nœud Amazon EC2 optimal. Chaque type d'instance Amazon EC2 prend en charge un nombre maximal d'interfaces réseau Elastic (interface réseau) et chaque interface réseau prend en charge un nombre maximal d'adresses IP. Étant donné que chaque composant master et chaque pod se voit attribuer sa propre adresse IP, il est important de choisir un type d’instance qui prendra en charge le nombre maximal de pods que vous voulez exécuter sur chaque nœud Amazon EC2. 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’instance m5.large prend en charge un maximum de 30 adresses IP pour le composant master et les pods.

      Note

      Les types d'instance pris en charge pour la dernière version du plugin CNI d'Amazon VPC pour Kubernetes sont indiqués dans vpc_ip_resource_limit.go sur GitHub. Vous devrez peut-être mettre à jour votre plug-in CNI Amazon VPC pour la version Kubernetes afin d’utiliser les derniers types d’instance pris en charge. Pour de plus amples informations, consultez Attribuer des adresses IP aux pods avec Amazon VPC CNI.

      Important

      Certains types d’instance peuvent ne pas être disponibles dans toutes les régions AWS.

    • NodeImageIdSSMParam : le paramètre Amazon EC2 Systems Manager de l'ID d'AMI auquel vous souhaitez vous mettre à jour. La valeur suivante utilise la dernière AMI optimisée Amazon EKS pour la version 1.33 de Kubernetes.

      /aws/service/eks/optimized-ami/1.33/amazon-linux-2/recommended/image_id

      Vous pouvez remplacer 1.33 par une plateforme-version identique. Ou bien, elle doit être antérieure d'une version au maximum à la version Kubernetes 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 remplacer amazon-linux-2 par un autre type d’AMI. Pour de plus amples informations, consultez Récupération des ID d’AMI Amazon Linux recommandés.

      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 d'AMI. Si votre pile AWS CloudFormation utilise cette valeur, toute mise à jour de la pile lance toujours la dernière AMI optimisée Amazon EKS recommandée pour la version Kubernetes que vous avez spécifiée. C’est 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 valeur NodeImageIdSSMParam, assurez-vous que la valeur de NodeImageId est vide.

    • DisableIMDSv1 : par défaut, chaque nœud prend en charge le service de métadonnées d'instance version 1 (IMDSv1) et IMDSv2. Cependant, vous pouvez désactiver IMDSv1. Sélectionnez true si vous ne voulez pas que les nœuds ou les pods planifiés dans le groupe de nœuds utilisent 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 les pods qui nécessitent un accès aux services AWS. De cette manière, aucun pod de votre cluster n’aura besoin d’accéder à IMDS pour d’autres raisons, telles que la récupération de la région AWS actuelle. Vous pouvez également désactiver l’accès à IMDSv2 pour les pods qui n’utilisent pas la mise en réseau hôte. Pour plus d'informations, consultez Restreindre l'accès au profil d'instance affecté au composant master.

  10. (Facultatif) Sur la page Options (Options), étiquetez les ressources de votre pile. Choisissez Next (Suivant).

  11. 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.

  12. Si le fournisseur DNS de votre cluster est kube-dns, réduisez horizontalement le déploiement kube-dns à une réplica.

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system

  13. (Facultatif) Si vous utilisez le composant Cluster Autoscaler de Kubernetes, redimensionnez le déploiement à la quantité souhaitée de réplicas.

    kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system

  14. (Facultatif) Vérifiez que vous utilisez la dernière version du plug-in CNI Amazon VPC pour Kubernetes. Vous devrez peut-être mettre à jour votre plug-in CNI Amazon VPC pour la version Kubernetes afin d’utiliser les derniers types d’instance pris en charge. Pour de plus amples informations, consultez Attribuer des adresses IP aux pods avec Amazon VPC CNI.