Migrer les applications vers un nouveau groupe de nœuds

Récupérez le nom de vos groupes de nœuds existants, en remplaçant my-cluster par le nom de votre cluster.

eksctl get nodegroups --cluster=my-cluster

L'exemple qui suit illustre un résultat.

CLUSTER      NODEGROUP          CREATED               MIN SIZE      MAX SIZE     DESIRED CAPACITY     INSTANCE TYPE     IMAGE ID
default      standard-nodes   2019-05-01T22:26:58Z  1             4            3                    t3.medium         ami-05a71d034119ffc12

Lancez un nouveau groupe de nœuds avec eksctl à l'aide de la commande suivante. Dans la commande, remplacez chaque example value par vos propres valeurs. Le numéro de version ne peut pas être postérieur à la version Kubernetes de votre plan de contrôle. De plus, il ne peut pas y avoir plus de deux versions mineures antérieures à la version de Kubernetes pour votre plan de contrôle. Nous vous recommandons d'utiliser la même version que votre plan de contrôle.

Nous recommandons de bloquer l'accès du Pod à l'IMDS si les conditions suivantes sont réunies :

eksctl create nodegroup \
  --cluster my-cluster \
  --version 1.32 \
  --name standard-nodes-new \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 4 \
  --managed=false

Lorsque la commande précédente se termine, vérifiez que tous vos nœuds ont atteint l'état Ready à l'aide de la commande suivante :

kubectl get nodes

Supprimez le groupe de nœuds d'origine avec la commande suivante. Dans la commande, remplacez chaque example value par les noms de votre cluster et de votre groupe de nœuds :

eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old

Lancez un nouveau groupe de nœuds en suivant les étapes décrites dans Créer des nœuds Amazon Linux autogérés.

Lorsque la création de votre pile est terminée, sélectionnez la pile dans la console et choisissez Outputs (Sorties).

Enregistrez le NodeInstanceRolepour le groupe de nœuds créé. Vous en aurez besoin pour ajouter les nouveaux nœuds Amazon EKS à votre cluster.

Mettez à jour les groupes de sécurité pour les deux groupes de nœuds afin qu'ils puissent communiquer entre eux. Pour de plus amples informations, veuillez consulter Afficher les exigences relatives aux groupes de sécurité Amazon EKS pour les clusters.

Modifiez la configmap aws-auth afin de mapper le nouveau rôle d'instance des nœuds dans RBAC.

kubectl edit configmap -n kube-system aws-auth

Ajoutez une nouvelle entrée mapRoles pour le nouveau groupe de nœuds.

apiVersion: v1
data:
  mapRoles: |
    - rolearn: ARN of instance role (not instance profile)
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes>
    - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Remplacez l'ARN of instance role (not instance profile)extrait par la NodeInstanceRolevaleur que vous avez enregistrée lors d'une étape précédente. Ensuite, enregistrez et fermez le fichier pour appliquer le configmap mise à jour.

Vérifiez le statut de vos nœuds et attendez que vos nouveaux nœuds rejoignent votre cluster et affichent le statut Ready.

kubectl get nodes --watch

(Facultatif) Si vous utilisez le Kubernetes Cluster Autoscaler, réduisez le déploiement à zéro (0) répliques afin d'éviter des actions de dimensionnement contradictoires.

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

Utilisez la commande suivante pour rejeter chacun des nœuds que vous souhaitez supprimer avec NoSchedule. Cela permet d'éviter que les nouveaux pods ne soient planifiés ou reprogrammés sur les nœuds que vous remplacez. Pour plus d'informations, consultez Taints and Tolerations dans la documentation de Kubernetes.

kubectl taint nodes node_name key=value:NoSchedule

Si vous mettez à niveau vos nœuds vers une nouvelle version de Kubernetes, vous pouvez identifier et altérer tous les nœuds d'une version particulière de Kubernetes (dans ce cas,1.30) à l'aide de l'extrait de code suivant. Le numéro de version ne peut pas être postérieur à la version Kubernetes de votre plan de contrôle. Il ne peut pas non plus y avoir plus de deux versions mineures antérieures à la version Kubernetes de votre plan de contrôle. Nous vous recommandons d'utiliser la même version que votre plan de contrôle.

K8S_VERSION=1.30
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
    echo "Tainting $node"
    kubectl taint nodes $node key=value:NoSchedule
done

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 kube-dns renvoyer à la place) :

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 par kubedns si la sortie de votre commande a plutôt renvoyé cette valeur.

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

Drainez chacun des nœuds que vous souhaitez supprimer de votre cluster à l'aide de la commande suivante :

kubectl drain node_name --ignore-daemonsets --delete-local-data

Si vous mettez à niveau vos nœuds vers une nouvelle version de Kubernetes, identifiez et videz tous les nœuds d'une version particulière de Kubernetes (dans ce cas,1.30) à l'aide de l'extrait de code suivant.

K8S_VERSION=1.30
nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}")
for node in ${nodes[@]}
do
    echo "Draining $node"
    kubectl drain $node --ignore-daemonsets --delete-local-data
done

Une fois que vos anciens nœuds ont été purgés, révoquez les règles d'entrée du groupe de sécurité que vous avez autorisées précédemment. Supprimez ensuite la AWS CloudFormation pile pour mettre fin aux instances.

Modifiez la configmap aws-auth afin de supprimer l'ancien rôle d'instance des nœuds dans RBAC.

kubectl edit configmap -n kube-system aws-auth

Supprimez l'entrée mapRoles de l'ancien groupe de nœuds.

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws: iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws: iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes>

Enregistrez et fermez le fichier afin d'appliquer la configmap mise à jour.

(Facultatif) Si vous utilisez le composant Cluster Autoscaler de Kubernetes, dimensionnez le déploiement à un réplica.

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 version de CNI pour utiliser les derniers types d'instances pris en charge. Pour de plus amples informations, veuillez consulter Attribuer IPs à des pods avec l'Amazon VPC CNI.

Si votre cluster utilise la résolution kube-dns DNS (voir[migrate-determine-dns-step]), adaptez le kube-dns déploiement à une seule réplique.

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