Mise à jour d'une version Kubernetes de cluster Amazon EKS - Amazon EKS
Mise à jour de la version Kubernetes de votre cluster Amazon EKS

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 tout le monde.

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.

Mise à jour d'une version Kubernetes de cluster Amazon EKS

Dès qu'une nouvelle version Kubernetes est disponible dans Amazon EKS, vous pouvez mettre à jour votre cluster Amazon EKS vers la version la plus récente.

Important

Une fois que vous avez mis à niveau un cluster, vous ne pouvez pas le rétrograder vers une version antérieure. Nous vous recommandons, avant de mettre à jour vers une nouvelle version de Kubernetes, de consulter les informations dans Versions Kubernetes Amazon EKS et également de consulter les étapes de mise à jour de cette rubrique.

Les nouvelles versions de Kubernetes introduisent parfois des modifications importantes. Nous vous recommandons donc de tester le comportement de vos applications par rapport à la nouvelle version de Kubernetes avant de procéder à la mise à jour sur vos clusters de production. Pour ce faire, créez un flux d'intégration continue afin de tester le comportement de votre application avant de passer à une nouvelle version Kubernetes.

Dans le processus de mise à jour, Amazon EKS lance de nouveaux nœuds de serveur d'API avec la version de Kubernetes mise à jour pour remplacer les versions existantes. Amazon EKS effectue des surveillances de l'état de disponibilité et de l'infrastructure standard pour le trafic réseau sur ces nouveaux nœuds pour vérifier qu'ils fonctionnent comme prévu. Cependant, une fois que vous avez commencé la mise à niveau du cluster, vous ne pouvez ni la suspendre ni l'arrêter. Si l'une de ces vérifications échoue, Amazon EKS annule le déploiement de l'infrastructure, et votre cluster reste dans la version Kubernetes précédente. Les applications en cours d'exécution ne sont pas affectées, et votre cluster n'est jamais laissé dans un état non déterministe ou irrécupérable. Amazon EKS sauvegarde régulièrement tous les clusters gérés, et des mécanismes existent pour récupérer des clusters si nécessaire. Nous évaluons et améliorons en permanence nos processus de gestion de l'infrastructure Kubernetes.

Pour mettre à jour le cluster, Amazon EKS requiert jusqu'à cinq adresses IP disponibles correspondant aux sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Amazon EKS crée de nouvelles interfaces réseau élastiques de cluster (interfaces réseau) dans l'un des sous-réseaux que vous avez spécifiés. Les interfaces réseau peuvent être créées dans des sous-réseaux différents de ceux dans lesquels se trouvent vos interfaces réseau existantes. Assurez-vous donc que les règles de votre groupe de sécurité autorisent la communication de cluster requise pour tous les sous-réseaux que vous avez spécifiés lors de la création de votre cluster. Si l'un des sous-réseaux que vous avez spécifiés lors de la création du cluster n'existe pas, ne dispose pas de suffisamment d'adresses IP disponibles ou de règles de groupe de sécurité permettant la communication nécessaire avec le cluster, la mise à jour peut échouer.

Note

Afin d'assurer une disponibilité constante du point de terminaison du serveur d'API de votre cluster, Amazon EKS déploie un plan de contrôle Kubernetes hautement disponible et effectue des mises à jour continues des instances du serveur d'API pendant les opérations de mise à jour. Afin de tenir compte des modifications d'adresses IP des instances de serveurs d'API qui prennent en charge votre point de terminaison de serveur d'API Kubernetes, il est important de vous assurer que les clients de votre serveur d'API gèrent les reconnexions de manière efficace. Les versions récentes de kubectl et les bibliothèques clientes Kubernetes officiellement prises en charge effectuent ce processus de reconnexion de manière transparente.

Mise à jour de la version Kubernetes de votre cluster Amazon EKS

Pour mettre à jour la version Kubernetes de votre cluster

  1. Comparez la version Kubernetes de votre plan de contrôle de cluster à la version Kubernetes de vos nœuds.

    • Obtenez la version Kubernetes du plan de contrôle de votre cluster.

      kubectl version

    • Obtenez la version Kubernetes de vos nœuds. Cette commande renvoie tous les nœuds Amazon EC2 et Fargate autogérés et gérés. Chaque Pod Fargate est répertorié comme son propre nœud.

      kubectl get nodes

    Avant de mettre à jour votre plan de contrôle vers une nouvelle version de Kubernetes, assurez-vous que la version mineure de Kubernetes des nœuds gérés et des nœuds Fargate de votre cluster est identique à la version de votre plan de contrôle. Par exemple, si votre plan de contrôle exécute la version 1.29 et que l'un de vos nœuds exécute la version1.28, vous devez mettre à jour vos nœuds vers la version 1.30 1.29 avant de mettre à jour votre plan de contrôle vers la version 1.30. Nous vous recommandons également de mettre à jour vos nœuds autogérés vers la même version que votre plan de contrôle avant de mettre à jour le plan de contrôle. Pour plus d’informations, consultez Mise à jour d'un groupe de nœuds gérés et Mises à jour des nœuds autogérés. Si vous avez des nœuds Fargate dont la version mineure est inférieure à la version du plan de contrôle, supprimez d'abord le Pod représenté par le nœud. Mettez ensuite à jour votre plan de contrôle. Tous les Pods restants seront mis à jour vers la nouvelle version une fois que vous les aurez redéployés.

  2. Si la version de Kubernetes avec laquelle vous avez initialement déployé votre cluster était Kubernetes version 1.25 ou ultérieure, ignorez cette étape.

    Par défaut, le contrôleur d'admission de politique de sécurité du Pod est activé sur les clusters Amazon EKS. Avant de mettre à jour votre cluster, assurez-vous que des politiques de sécurité de Pod appropriées sont en place. Il s'agit ainsi d'éviter les problèmes de sécurité potentiels. Vous pouvez vérifier la politique par défaut à l'aide de la commande kubectl get psp eks.privileged.

    kubectl get psp eks.privileged

    Si vous recevez l'erreur suivante, veuillez consulter Stratégie de sécurité de Pod Amazon EKS par défaut avant de continuer.

    Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found

  3. Si la version de Kubernetes avec laquelle vous avez initialement déployé votre cluster était Kubernetes version 1.18 ou ultérieure, ignorez cette étape.

    Vous devrez peut-être supprimer un terme abandonné de votre manifeste CoreDNS.

    1. Vérifiez si votre manifeste CoreDNS a une ligne qui n'a que le mot upstream.

      kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream

      Si aucune sortie n'est renvoyée, cela signifie que votre manifeste n'a pas la ligne. Dans ce cas, passez à l'étape suivante. Si le mot upstream est retourné, supprimez la ligne.

    2. Supprimez la ligne près du haut du fichier qui ne contient que le mot upstream dans le fichier configmap. Ne changez rien d'autre dans le fichier. Une fois la ligne supprimée, enregistrez les modifications.

      kubectl edit configmap coredns -n kube-system -o yaml

  4. Mettez à jour votre cluster à l'aide du eksctl AWS Management Console, ou du AWS CLI.

    Important

    • Si vous effectuez une mise à jour vers la version 1.23 et utilisez des volumes Amazon EBS dans votre cluster, alors vous devez installer le pilote Amazon EBS CSI dans votre cluster avant de mettre celui-ci à jour vers la version 1.23 afin d'éviter les perturbations liées à la charge de travail. Pour plus d’informations, consultez Kubernetes1,23 et Pilote CSI Amazon EBS.

    • Kubernetes 1.24 et versions ultérieures utilisent containerd comme environnement d'exécution du conteneur par défaut. Si vous passez à l'exécution containerd et que vous avez déjà configuré Fluentd pour Container Insights, vous devez effectuer la migration de Fluentd vers Fluent Bit avant de mettre à jour votre cluster. Les analyseurs Fluentd sont configurés pour analyser uniquement les messages du journal au format JSON. Contrairement à dockerd, l'exécution du conteneur containerd a des messages de journal qui ne sont pas au format JSON. Si vous ne migrez pas vers Fluent Bit, certains des analyseurs Fluentd's configurés généreront un grand nombre d'erreurs à l'intérieur du conteneur Fluentd. Pour plus d'informations sur la migration, voir Configurer en Fluent Bit tant que DaemonSet pour envoyer des CloudWatch journaux vers Logs.

    • Dans la mesure où Amazon EKS exécute un plan de contrôle hautement disponible, vous devez mettre à jour une seule version mineure à la fois. Pour plus d'informations sur cette exigence, consultez Politique de prise en charge des versions et versions asymétriques de Kubernetes. Supposez que la version actuelle de votre cluster soit la version 1.28 et que vous souhaitiez la mettre à jour vers la version 1.30. Vous devez d'abord mettre à jour la version 1.28 de votre cluster vers la version 1.29, puis mettre à jour la version 1.29 de votre cluster vers la version 1.30.

    • Vérifiez l'asymétrie de version entre Kubernetes kube-apiserver et kubelet sur vos nœuds.

      • À partir de la version 1.28 de Kubernetes, kubelet peut avoir jusqu'à trois versions mineures antérieures à kube-apiserver. Voir la politique d'asymétrie des versions en amont de Kubernetes.

      • Si la version de Kubernetes du kubelet de vos nœuds gérés et nœuds Fargate est 1.25 ou une version plus récente, vous pouvez mettre à jour votre cluster jusqu'à trois versions à l'avance sans mettre à jour la version kubelet. Par exemple, si la version du kubelet est 1.25, vous pouvez mettre à jour la version de votre cluster Amazon EKS de 1.25 vers 1.26 ou vers 1.27 et vers 1.28 alors que le kubelet reste sur la version 1.25.

      • Si la version de Kubernetes du kubelet de vos nœuds gérés et nœuds Fargate est 1.24 ou une version plus ancienne, il ne peut être que sur maximum deux versions mineures plus anciennes que le kube-apiserver. En d'autres termes, si la version du kubelet est 1.24 ou une version antérieure, vous ne pouvez mettre à jour votre cluster que sur deux versions plus récentes. Par exemple, si la version du kubelet est 1.21, vous pouvez mettre à jour la version de votre cluster Amazon EKS de 1.21 vers 1.22 et vers 1.23, mais vous ne pouvez pas mettre à jour le cluster vers 1.24 alors que la version du kubelet reste sur 1.21.

    • Avant de commencer une mise à jour, il est recommandé de vérifier que le kubelet sur vos nœuds est identique à celle de la version Kubernetes de votre plan de contrôle.

    • Si votre cluster est configuré avec une version d' Amazon VPC CNI plugin for Kubernetes antérieure à la version 1.8.0, nous vous recommandons de mettre à jour le plugin à la dernière version avant de mettre à jour votre cluster. Pour mettre à jour le plugin, consultez Utilisation du module complémentaire Amazon VPC CNI plugin for Kubernetes Amazon EKS.

    • Si vous mettez à jour votre cluster vers la version 1.25 ou vers une version ultérieure et que vous avez déployé le AWS Load Balancer Controller dans votre cluster, mettez à jour le contrôleur vers la version 2.4.7 ou vers une version ultérieure avant de mettre à jour votre cluster vers la version 1.25. Pour plus d'informations, consultez les notes de mise à jour de Kubernetes1,25.

    eksctl

    Cette procédure nécessite eksctl version 0.183.0 ou ultérieure. Vous pouvez vérifier votre version avec la commande suivante :

    eksctl version

    Pour les instructions d'installation et de mise à jour de eksctl, consultez la rubrique Installation dans la documentation eksctl.

    Mettez à jour la version Kubernetes de votre plan de contrôle Amazon EKS. Remplacez my-cluster par le nom de votre cluster. Remplacez 1.30 par le numéro de version pris en charge par Amazon EKS vers lequel vous souhaitez mettre à jour votre cluster. Pour obtenir une liste des numéros de version pris en charge, consultez Versions Kubernetes Amazon EKS.

    eksctl upgrade cluster --name my-cluster --version 1.30 --approve

    Cette mise à jour peut prendre plusieurs minutes.

    AWS Management Console

    1. Ouvrez la console Amazon EKS à l'adresse https://console.aws.amazon.com/eks/home#/clusters.

    2. Sélectionnez le nom du cluster Amazon EKS à mettre à jour, puis choisissez Update cluster version (Mettre à jour la version du cluster).

    3. Dans Version Kubernetes, sélectionnez la version vers laquelle mettre à jour votre cluster, puis sélectionnez Mettre à jour.

    4. Dans Cluster name (Nom du cluster), saisissez le nom de votre cluster, puis sélectionnez Confirm (Confirmer).

      Cette mise à jour peut prendre plusieurs minutes.

    AWS CLI

    1. Mettez à jour votre cluster Amazon EKS à l'aide de la commande AWS CLI suivante. Remplacez les example values par vos propres valeurs. Remplacez 1.30 par le numéro de version pris en charge par Amazon EKS vers lequel vous souhaitez mettre à jour votre cluster. Pour obtenir une liste des numéros de version pris en charge, consultez Versions Kubernetes Amazon EKS.

      aws eks update-cluster-version --region region-code --name my-cluster --kubernetes-version 1.30

      L'exemple qui suit illustre un résultat.

      {
    "update": {
        "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
        "status": "InProgress",
        "type": "VersionUpdate",
        "params": [
            {
                "type": "Version",
                "value": "1.30"
            },
            {
                "type": "PlatformVersion",
                "value": "eks.1"
            }
        ],
[...]
        "errors": []
    }
}

    2. Contrôlez l'état de mise à jour de votre cluster avec la commande suivante. Utilisez le nom de cluster et l'ID de mise à jour renvoyé par la commande précédente. Lorsqu'un état Successful s'affiche, la mise à jour est terminée. Cette mise à jour peut prendre plusieurs minutes.

      aws eks describe-update --region region-code --name my-cluster --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f

      L'exemple qui suit illustre un résultat.

      {
    "update": {
        "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
        "status": "Successful",
        "type": "VersionUpdate",
        "params": [
            {
                "type": "Version",
                "value": "1.30"
            },
            {
                "type": "PlatformVersion",
                "value": "eks.1"
            }
        ],
[...]
        "errors": []
    }
}

  5. Une fois la mise à jour de votre cluster terminée, mettez à jour vos nœuds vers la même version mineure Kubernetes que celle de votre cluster mis à jour. Pour plus d’informations, consultez Mises à jour des nœuds autogérés et Mise à jour d'un groupe de nœuds gérés. Tous les nouveaux Pods lancés sur Fargate ont une version kubelet correspondant à la version de votre cluster. Les Pods Fargate existants ne sont pas modifiés.

  6. (Facultatif) Si vous avez déployé Kubernetes Cluster Autoscaler sur votre cluster avant de mettre à jour le cluster, mettez ce composant à jour vers la version la plus récente correspondant à la version majeure et mineure de Kubernetes vers laquelle vous avez effectué la mise à jour.

    1. Ouvrez la page des versions de Cluster Autoscaler dans un navigateur web et recherchez la dernière version de Cluster Autoscaler qui correspond aux versions majeure et mineure Kubernetes de votre cluster. Par exemple, si la version Kubernetes de votre cluster est 1.30, recherchez la version la plus récente du Cluster Autoscaler qui commence par 1.30. Enregistrez le numéro de version sémantique (1.30.n, par exemple) de cette version à utiliser à l'étape suivante.

    2. Identifiez l'image Cluster Autoscaler sur la version que vous avez enregistrée à l'étape précédente avec la commande suivante. Si nécessaire, remplacez 1.30.n par votre propre valeur.

      kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:v1.30.n

  7. (Clusters avec des nœuds GPU uniquement) Si votre cluster comporte des groupes de nœuds avec prise en charge de GPU (par exemple p3.2xlarge), vous devez mettre à jour le contrôleur DaemonSet du plugin de périphérique NVIDIA pour Kubernetes sur votre cluster. Remplacez vX.X.X par la version NVIDIA/k8s-device-plugin souhaitée avant d'exécuter la commande suivante.

    kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/vX.X.X/nvidia-device-plugin.yml

  8. Mettez à jour les modules complémentaires Amazon VPC CNI plugin for Kubernetes, CoreDNS et kube-proxy. Nous vous recommandons de mettre à jour les modules complémentaires avec les versions minimales répertoriées dans les jetons de compte de service.

    • Si vous utilisez des modules complémentaires Amazon EKS, dans la console Amazon EKS, sélectionnez Clusters, puis le nom du cluster que vous avez mis à jour dans le volet gauche. Les notifications s'affichent dans la console. Elles vous informent qu'une nouvelle version est disponible pour chaque module complémentaire disposant d'une mise à jour disponible. Pour mettre à jour un module complémentaire, sélectionnez l'onglet Add-ons (Modules complémentaires). Dans l'une des zones d'un module complémentaire dont une mise à jour est disponible, sélectionnez Update now (Mettre à jour maintenant), sélectionnez une version disponible, puis cliquez sur Update (Mise à jour).

    • Vous pouvez également utiliser le AWS CLI ou eksctl pour mettre à jour les modules complémentaires. Pour plus d’informations, consultez Mise à jour d'un module complémentaire.

  9. Si nécessaire, mettez à jour votre version de kubectl. Vous devez utiliser une version kubectl qui se situe à une différence de version mineure près du plan de contrôle de votre cluster Amazon EKS. Par exemple, un client kubectl 1.29 doit utiliser des clusters Kubernetes, 1.28, 1.29 et 1.30. Vous pouvez vérifier votre version installée à l'aide de la commande suivante.

    kubectl version --client