Comment planifier une mise à niveau pour mon cluster Amazon EKS ?

Résolution

Comprendre l'effet d'une mise à niveau

Les nouvelles versions de Kubernetes peuvent apporter des modifications importantes à votre cluster Amazon EKS. Une fois votre cluster mis à niveau, aucune option ne permet de revenir à une version plus ancienne.

Si vous effectuez une mise à niveau vers une version ultérieure de Kubernetes, il n'est pas nécessaire d'effectuer une mise à niveau de cluster sur place. À la place, vous pouvez migrer vers un nouveau cluster. Si vous migrez vers un nouveau cluster, il est recommandé d'utiliser des outils de sauvegarde et de restauration du cluster, tels que Velero. Pour en savoir plus, consultez la page Velero sur le site Web de GitHub.

Pour les versions actuelles et antérieures de Kubernetes, consultez le calendrier de publication d'Amazon EKS Kubernetes.

Répondre aux exigences de mise à niveau

Pour mettre à niveau votre cluster, vous devez répondre aux exigences suivantes :

• Vous devez disposer d’au moins cinq adresses IP disponibles provenant des sous-réseaux que vous avez spécifiés lors de la création de votre cluster.
• Le rôle Gestion des identités et des accès AWS (AWS IAM) et le groupe de sécurité de votre cluster doivent existent dans votre compte AWS.
• Si vous activez le chiffrement des secrets, le rôle IAM du cluster doit disposer des autorisations de clé AWS Key Management Service (AWS KMS).

Examiner les mises à jour majeures d’Amazon EKS et de Kubernetes

Effectuez les opérations suivantes :

• Passez en revue toutes les modifications documentées pour la version de mise à niveau, puis notez toutes les étapes de mise à niveau requises.
• Examinez également les exigences ou procédures spécifiques aux clusters gérés d’Amazon EKS.

Pour plus d'informations sur les mises à jour majeures des versions de plateforme des clusters Amazon EKS et des versions de Kubernetes, consultez la documentation suivante :

• Comprendre le cycle de vie des versions de Kubernetes sur Amazon EKS
• Consulter les versions de la plateforme Amazon EKS pour chaque version de Kubernetes
• Mettre à jour le cluster existant vers la nouvelle version de Kubernetes

Pour obtenir des informations sur les versions en amont et les mises à jour majeures de Kubernetes, consultez la documentation suivante :

• Notes relatives aux versions de Kubernetes sur le site Web de Kubernetes
• Journal des modifications de Kubernetes sur le site Web de GitHub

Comprendre et vérifier les API abandonnées

Lorsque Kubernetes met à niveau une API, Kubernetes supprime également l'API précédente.

Pour gérer les API abandonnées, procédez comme suit :

• Pour comprendre comment Kubernetes supprime les API dans une version ultérieure de Kubernetes, consultez la politique de dépréciation de Kubernetes sur le site Web de Kubernetes.
• Pour vérifier les versions d'API abandonnées dans votre cluster, utilisez l'outil Kube No Trouble (kubent). Pour plus d'informations, consultez la page kube-no-trouble sur le site Web de GitHub. Si vous utilisez des versions d’API abandonnées, mettez à niveau vos charges de travail avant de mettre à niveau votre cluster Kubernetes.
• Pour convertir les fichiers manifestes Kubernetes entre différentes versions d’API, utilisez le plug-in kubectl convert. Pour en savoir plus, consultez la page Installer le plug-in kubectl convert sur le site Web de Kubernetes.

Savoir à quoi s’attendre lors de la mise à niveau de Kubernetes

Lorsque vous mettez à niveau votre cluster, Amazon EKS lance de nouveaux nœuds de serveur d’API avec la version mise à niveau de Kubernetes pour remplacer les nœuds existants. Amazon EKS effectue également une série de vérifications internes. Si une vérification échoue, Amazon EKS annule le déploiement de l’infrastructure et votre cluster reste sur la version précédente de Kubernetes. La restauration n'affecte pas les applications en cours d'exécution et vous pouvez récupérer les clusters.

Remarque : Au cours du processus de mise à niveau, il est possible que vous subissiez des interruptions de service mineures.

Mettre à niveau les plans de contrôle et de données

Pour mettre à niveau un cluster, vous devez mettre à jour le plan de contrôle et le plan de données.

Pour mettre à jour les avions, choisissez l'une des méthodes suivantes :

• Mise à niveau du cluster sur place
• Mise à niveau bleu/vert ou canary
• Mise à niveau d'un groupe de nœuds gérés

Mise à niveau du cluster sur place

Important : Pour les mises à niveau sur place, il est uniquement possible d’effectuer une mise à niveau vers la prochaine version mineure de Kubernetes. S’il existe plusieurs versions entre la version actuelle de votre cluster et la version de destination, vous devez effectuer une mise à niveau vers chaque version successivement.

Pour chaque mise à niveau d’un cluster Kubernetes sur place, vous devez effectuer les étapes suivantes :

1. Mettez à jour vos manifestes Kubernetes et les API abandonnées.
2. Mettez à niveau le plan de contrôle du cluster.
3. Mettez à niveau les nœuds de votre cluster.
4. Mettez à jour vos modules complémentaires Kubernetes et vos contrôleurs personnalisés.

Pour en savoir plus, consultez la section Planification et exécution des mises à niveau de la version Kubernetes dans Amazon EKS sur la page Planification des mises à niveau de Kubernetes avec Amazon EKS. Consultez également la section Bonnes pratiques pour les mises à niveau du cluster.

Mise à niveau bleu/vert ou canary

Pour effectuer une mise à niveau bleu/vert ou canary, consultez la page Migration des clusters bleu/vert ou canary EKS pour les charges de travail ArgoCD sans état.

Mise à niveau d'un groupe de nœuds gérés

Important : Le kubelet d’un nœud ne peut pas être plus récent que kube-apiserver. En outre, le kubelet ne peut pas remonter à plus de deux versions mineures antérieures à kube-apiserver. Par exemple, si kube-apiserver est en version 1.24, Amazon EKS ne prend en charge un kubelet qu'en versions 1.24, 1.23 et 1.22.

Pour mettre à niveau un groupe de nœuds gérés, mettez à jour vos nœuds du groupe de nœuds gérés.

Migrer vers des groupes de nœuds gérés Amazon EKS

Si vous utilisez des groupes de nœuds autogérés, vous pouvez migrer votre charge de travail vers des groupes de nœuds gérés Amazon EKS sans durée d’indisponibilité.

Identifier et mettre à jour des dépendances en aval

Les clusters peuvent contenir des modules complémentaires et des outils tiers, tels que des contrôleurs d'entrée, des systèmes de diffusion continue, des outils de surveillance et d'autres flux de travail. Si vous mettez à jour votre cluster, vous devez également mettre à jour vos modules complémentaires et vos outils tiers. Assurez-vous de comprendre comment les modules complémentaires fonctionnent avec votre cluster et de quelle façon ils sont mis à jour.

Remarque : Il est recommandé d’utiliser des modules complémentaires gérés plutôt que des modules complémentaires autogérés.

Consultez les exemples suivants de modules complémentaires courants et la documentation de mise à niveau :

• Déterminez le module complémentaire Amazon Virtual Private Cloud Container Network Interface (Amazon VPC CNI) à utiliser pour chaque version de cluster. Pour plus d'informations, consultez la section Attribuer des adresses IP à des pods avec l’Amazon VPC CNI. Consultez également la section Configurer le plug-in Amazon VPC CNI pour utiliser les rôles IAM pour les comptes de service (IRSA).
• Pour un module complémentaire kube-proxy autogéré, effectuez la mise à jour vers la dernière version d'image de conteneur kube-proxy disponible pour chaque version de cluster. Pour plus d'informations, consultez la section Gérer kube-proxy dans les clusters Amazon EKS.
• Pour CoreDNS, effectuez une mise à jour vers la dernière version d’image de conteneur CoreDNS disponible pour chaque version de cluster. Pour plus d'informations, consultez la section Gérer CoreDNS pour le DNS dans les clusters Amazon EKS.
• AWS Load Balancer Controller version 2.5.0 ou ultérieure requiert Kubernetes version 1.22 ou ultérieure. Pour en savoir plus, consultez la page Versions de l’AWS Load Balancer Controller sur le site Web de GitHub. Pour plus d'informations sur l'installation, consultez la section Acheminer le trafic Internet avec AWS Load Balancer Controller.
• La version 1.25.0 ou ultérieure du pilote CSI Amazon Elastic Block Store (Amazon EBS) requiert la version 1.23 ou ultérieure de Kubernetes. Pour plus d'informations, consultez la page aws-ebs-csi-driver sur le site Web de GitHub. Pour obtenir des informations sur l'installation et la mise à niveau, consultez la section Étape 2 : Obtenir le pilote CSI Amazon EBS.
• La version 1.5.8 ou ultérieure du pilote CSI Amazon Elastic File System (Amazon EFS) requiert Kubernetes version 1.22 ou ultérieure. Pour plus d'informations, consultez la page aws-efs-csi-driver sur le site Web de GitHub. Pour obtenir des informations sur l'installation et la mise à niveau, consultez la section Utiliser le stockage du système de fichiers Elastic avec Amazon EFS.

Mettre à niveau les nœuds Fargate

Pour mettre à jour un nœud AWS Fargate, procédez comme suit :

1. Supprimez le pod que représente votre nœud.
2. Mettez à jour votre plan de contrôle.
3. Redéployez le pod.

Les nouveaux pods que vous lancez sur Fargate ont désormais une version de kubelet qui correspond à la version de votre cluster. Votre mise à niveau n'affecte pas les pods Fargate existants.

Remarque : Amazon EKS doit régulièrement appliquer des correctifs aux pods Fargate pour garantir la sécurité des pods. Lors de la mise à jour des pods, Amazon EKS minimise les effets du correctif. Si Amazon EKS ne parvient pas à supprimer des pods, Amazon EKS supprime les pods. Pour minimiser les perturbations, consultez la section Définir des actions pour les événements d'application de correctifs au système d'exploitation AWS Fargate.

Mettre à niveau les nœuds non gérés créés par Karpenter

La valeur que vous définissez pour ttlSecondsUntilExpired active l'expiration du nœud. Lorsque les nœuds atteignent l’âge spécifié en secondes, Amazon EKS les supprime. La suppression se produit même lorsque les charges de travail ou les applications Amazon EKS utilisent les nœuds. Utilisez ttlSecondsUntilExpired pour remplacer les nœuds par des instances récemment provisionnées afin de pouvoir mettre à niveau les instances. Karpenter utilise les dernières Amazon Machine Images (AMI) optimisées pour Amazon EKS pour les nœuds remplacés. Pour plus d'informations sur la manière dont Karpenter perturbe les nœuds, consultez la page Perturbation sur le site Web de Karpenter.

L’exemple suivant montre un nœud dé-approvisionné avec ttlSecondsUntilExpired, puis remplacé par une instance mise à niveau :

apiVersion: karpenter.sh/v1alpha5kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000                               # optional, recommended to limit total provisioned CPUs
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set
  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set
  provider:
        subnetSelector:
      karpenter.sh/discovery/CLUSTER_NAME: '*'
    securityGroupSelector:
      kubernetes.io/cluster/CLUSTER_NAME: '*'

Remarque : Karpenter n'ajoute pas automatiquement de gigue à la valeur ttlSecondsUntilExpired. Si vous créez plusieurs instances en peu de temps, elles expirent presque en même temps. Pour éviter toute perturbation excessive de la charge de travail, définissez un budget de perturbation de pods. Pour en savoir plus, consultez la page Spécification d’un budget de perturbation pour votre application du site Web de Kubernetes.