Comment puis-je planifier une stratégie de mise à niveau pour un cluster Amazon EKS ?

Brève description

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. Lorsque vous effectuez une mise à niveau vers une version plus récente de Kubernetes, vous pouvez migrer vers de nouveaux clusters au lieu d’effectuer des mises à niveau de clusters sur place. Si vous choisissez de migrer vers de nouveaux clusters, des outils de sauvegarde et de restauration de clusters tels que Velero de VMware peuvent vous aider à effectuer la migration. Pour en savoir plus, consultez Velero sur le site Web de GitHub.

Pour connaître les versions actuelles et antérieures de Kubernetes disponibles pour Amazon EKS, consultez le calendrier des versions d’Amazon EKS Kubernetes.

Résolution

Préparation de la mise à niveau

Avant de commencer la mise à niveau de votre cluster, prenez note des exigences suivantes :

• Amazon EKS nécessite jusqu’à cinq adresses IP disponibles provenant des sous-réseaux que vous avez spécifiés lors de la création de votre cluster.
• Vérifiez que le rôle AWS Identity and Access Management (AWS IAM) et le groupe de sécurité du cluster 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).

Examen des mises à jour majeures d’Amazon EKS et de Kubernetes

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

Consultez les ressources suivantes pour connaître les mises à jour majeures des versions de plateforme pour les clusters d’Amazon EKS et des versions de Kubernetes :

• Mise à jour de la version de Kubernetes d’un cluster d’Amazon EKS
• Versions de Kubernetes d’Amazon EKS
• Versions de plateforme d’Amazon EKS

Pour en savoir plus 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
• Changelog sur le site Web de GitHub

Comprendre la politique d’obsolescence de Kubernetes

Lorsqu’une API est mise à niveau, l’API précédente devient obsolète avant d’être finalement supprimée. Pour comprendre comment les API peuvent devenir obsolètes dans une version plus récente de Kubernetes, consultez la politique d’obsolescence présentée sur le site Web de Kubernetes.

Pour savoir si vous utilisez des versions d’API obsolètes dans votre cluster, utilisez l’outil Kube No Trouble (kubent) disponible sur le site Web de GitHub. Si vous utilisez des versions d’API obsolètes, 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 module complémentaire kubectl convert. Pour en savoir plus, consultez la page Install kubectl convert plugin sur le site Web de Kubernetes.

À 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. Si l’une de ces vérifications échoue, Amazon EKS annule le déploiement de l’infrastructure et votre cluster reste sur la version précédente de Kubernetes. Toutefois, cette restauration n’affecte aucune des applications en cours d’exécution, et vous pouvez récupérer tous les clusters, le cas échéant. Au cours du processus de mise à niveau, il est possible que vous subissiez des interruptions de service mineures.

Mise à niveau des plans de contrôle et de données

Pour mettre à niveau un cluster Amazon EKS, vous devez mettre à jour deux composants principaux : le plan de contrôle et le plan de données. Lorsque vous mettez à niveau ces composants, tenez compte des points suivants.

Mises à niveau d’un cluster Amazon EKS sur place

Pour les mises à niveau sur place, il est uniquement possible d’effectuer une mise à niveau vers la prochaine version mineure de Kubernetes la plus élevée. S’il existe plusieurs versions entre la version actuelle de votre cluster et la version cible, vous devez effectuer une mise à niveau vers chaque version successivement. Pour chaque mise à niveau d’un cluster Kubernetes sur place, vous devez effectuer les tâches suivantes :

• Mettre à jour vos manifestes Kubernetes et mettre à jour les API obsolètes ou supprimées, le cas échéant.
• Mettre à niveau le plan de contrôle du cluster.
• Mettre à niveau les nœuds de votre cluster.
• Mettre à jour vos modules complémentaires Kubernetes et vos contrôleurs personnalisés, le cas échéant.

Pour en savoir plus, consultez la section Planning and executing Kubernetes version upgrades in Amazon EKS sur la page Planning Kubernetes upgrades with Amazon EKS. Consultez également les Best practices for cluster upgrades sur le site Web de GitHub.

Migration de clusters Amazon EKS bleu/vert ou canary

Une stratégie de mise à niveau bleu/vert ou canary est plus complexe, mais elle permet d’effectuer des mises à niveau avec une capacité de restauration facile, le tout sans temps d’arrêt. Pour effectuer une mise à niveau bleu/vert ou canary, consultez la page Blue/Green or Canary Amazon EKS clusters migration for stateless ArgoCD workloads.

Mise à niveau de groupes de nœuds gérés Amazon EKS

Important : le kubelet d’un nœud ne peut pas être plus récent que kube-apiserver. En outre, il ne peut pas remonter à plus de deux versions mineures antérieures à kube-apiserver. Supposons, par exemple, que kube-apiserver soit à la version 1.24. Dans ce cas, seul un kubelet correspondant aux versions 1.24, 1.23 et 1.22 sera pris en charge.

Pour effectuer une mise à niveau complète de vos groupes de nœuds gérés, procédez comme suit :

1. Mettez à niveau les composants du plan de contrôle de votre cluster Amazon EKS vers la dernière version.
2. Mettez à jour vos nœuds dans le groupe de nœuds gérés.

Migration 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 temps d’arrêt. Pour en savoir plus, consultez la page Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups.

Identification et mise à niveau des dépendances en aval (modules complémentaires)

Les clusters contiennent souvent de nombreux produits externes tels que des contrôleurs d’entrée, des systèmes de diffusion continue, des outils de surveillance et d’autres flux de travail. Lorsque vous mettez à jour votre cluster Amazon EKS, 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 correspondante :

• Module complémentaire CNI d’Amazon VPC : pour connaître la version suggérée de module complémentaire CNI d’Amazon VPC à utiliser pour chaque version de cluster, consultez la page Utilisation du module complémentaire CNI d’Amazon VPC pour Kubernetes Amazon EKS. Consultez également la page Update the aws-node daemonset to use IRSA sur le site Web de GitHub.
• Module complémentaire autogéré kube-proxy : effectuez une mise à jour vers la dernière version d’image de conteneur kube-proxy disponible pour chaque version de cluster Amazon EKS. Pour en savoir plus, consultez la page Utilisation du module complémentaire Kubernetes kube-proxy.
• CoreDNS : effectuez une mise à jour vers la dernière version d’image de conteneur CoreDNS disponible pour chaque version de cluster Amazon EKS. Pour en savoir plus, consultez la page Mise à jour du module complémentaire autogéré.
• Contrôleur de l’équilibreur de charge AWS : les versions 2.5.0 ou ultérieures du contrôleur de l’équilibreur de charge AWS nécessitent les versions 1.22 ou ultérieures de Kubernetes. Pour en savoir plus, consultez les versions du contrôleur de l’équilibreur de charge AWS sur le site Web de GitHub. Pour en savoir plus sur l’installation, consultez la page Installation du module complémentaire du contrôleur de l’équilibreur de charge AWS.
• Pilote d’interface de stockage de conteneur (CSI) Amazon Elastic Block Store (Amazon EBS) : les versions 1.25.0 ou ultérieures du pilote CSI Amazon EBS nécessitent les versions 1.23 ou ultérieures de Kubernetes. Pour en savoir plus, consultez les versions des pilotes CSI Amazon EBS sur le site Web de GitHub. Pour en savoir plus sur l’installation et la mise à niveau, consultez la page Gestion du pilote CSI Amazon EBS en tant que module complémentaire Amazon EKS.
• Pilote d’interface de stockage de conteneur (CSI) Amazon Elastic File System (Amazon EFS) : les versions 1.5.8 ou ultérieures du pilote CSI Amazon EFS nécessitent les versions 1.22 ou ultérieures de Kubernetes. Pour en savoir plus, consultez les versions des pilotes CSI d’Amazon EFS sur le site Web de GitHub. Pour en savoir plus sur l’installation et la mise à niveau, consultez ](https://docs.aws.amazon.com/eks/latest/userguide/efs-csi.html)Pilote CSI d’Amazon EFS[.

Mise à niveau de nœuds AWS Fargate

Pour mettre à jour un nœud Fargate, vous devez supprimer le pod représenté par le nœud. Vous pouvez ensuite redéployer le pod après avoir mis à jour votre plan de contrôle. Tous les nouveaux pods lancés sur Fargate ont une version de kubelet qui correspond à la version de votre cluster. Les pods Fargate existants ne sont pas modifiés.

Remarque : pour garantir la sécurité des pods Fargate, Amazon EKS doit appliquer des correctifs réguliers. Amazon EKS s’efforce de mettre à jour les pods de manière à éviter toute répercussion. Toutefois, si les pods ne peuvent pas être expulsés correctement, Amazon EKS doit les supprimer. Pour limiter les interruptions, consultez la page Application de correctifs au système d’exploitation Fargate.

Mise à niveau des nœuds sans groupe créés par Karpenter

Lorsque vous définissez une valeur pour ttlSecondsUntilExpired, cette valeur active l’expiration du nœud. Lorsque les nœuds atteignent l’âge défini en secondes, Amazon EKS les supprime. Cette suppression se produit même si les nœuds sont en cours d’utilisation. Ce processus vous permet de remplacer les nœuds par des instances nouvellement approvisionnées, et donc de les mettre à niveau. Lorsqu’un nœud est remplacé, Karpenter utilise les dernières AMI optimisées pour Amazon EKS. Pour en savoir plus, consultez la page Interruption 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 à cette valeur. Si vous créez plusieurs instances en peu de temps, elles expireront presque en même temps. Pour éviter toute interruption excessive de la charge de travail, définissez un budget d’interruption des pods. Pour en savoir plus, consultez la page Specifying a disruption budget for your application sur le site Web de Kubernetes.