Bonnes pratiques pour les mises à niveau de clusters Google Distributed Cloud

Ce document décrit les bonnes pratiques et les points à prendre en compte pour mettre à niveau Google Distributed Cloud. Vous apprendrez à vous préparer aux mises à niveau de cluster et découvrirez les bonnes pratiques à suivre avant la mise à niveau. Ces bonnes pratiques permettent de réduire les risques associés aux mises à niveau des clusters.

Si vous disposez de plusieurs environnements (test, développement et production, par exemple), nous vous recommandons de commencer par l'environnement le moins critique (test, par exemple) et de vérifier la fonctionnalité de mise à niveau. Une fois que vous avez vérifié que la mise à niveau a réussi, passez à l'environnement suivant. Répétez cette procédure jusqu'à ce que vous ayez mis à niveau vos environnements de production. Cette approche vous permet de passer d'un point critique à l'autre et de vérifier que la mise à niveau et vos charges de travail s'exécutent correctement.

Checklist pour la mise à niveau

Pour que le processus de mise à niveau se déroule le plus facilement possible, examinez et effectuez les vérifications suivantes avant de commencer à mettre à niveau vos clusters :

Planifier la mise à niveau

Les mises à jour peuvent être perturbantes. Avant de commencer la mise à niveau, planifiez soigneusement pour vous assurer que votre environnement et vos applications sont prêts. Vous devrez peut-être également planifier la mise à niveau en dehors des heures d'ouverture habituelles, lorsque le trafic est le plus faible.

Estimer le temps nécessaire et planifier un intervalle de maintenance

Par défaut, tous les pools de nœuds sont mis à niveau en parallèle. Toutefois, dans chaque pool de nœuds, les nœuds sont mis à niveau séquentiellement, car chacun d'eux doit être drainé et recréé. La durée totale d'une mise à niveau dépend donc du nombre de nœuds du plus grand pool de nœuds. Pour obtenir une estimation approximative de la durée de la mise à niveau, multipliez 15 minutes par le nombre de nœuds du plus grand pool de nœuds. Par exemple, si le pool le plus grand comporte 10 nœuds, la durée totale de la mise à niveau sera d'environ 15 * 10 = 150 minutes, soit 2,5 heures.

Voici plusieurs façons de réduire le temps de mise à niveau et de faciliter la planification et la programmation des mises à niveau :

  • Dans la version 1.28 et les versions ultérieures, vous pouvez accélérer une mise à niveau en définissant la valeur de maxSurge pour des pools de nœuds individuels. Lorsque vous mettez à niveau des nœuds avec maxSurge, plusieurs nœuds sont mis à niveau en même temps qu'un seul nœud.

  • Si vos clusters sont en version 1.16 ou ultérieure, vous pouvez ignorer une version mineure lors de la mise à niveau des pools de nœuds. Effectuer une mise à niveau en ignorant une version permet de diviser par deux le temps nécessaire pour mettre à niveau séquentiellement les pools de nœuds de deux versions. De plus, les mises à niveau de version intermédiaire vous permettent d'augmenter le délai entre les mises à niveau nécessaires pour rester sur une version compatible. Réduire le nombre de mises à niveau permet de limiter les perturbations de la charge de travail et le temps de vérification. Pour en savoir plus, consultez Ignorer une version lors de la mise à niveau des pools de nœuds.

  • Vous pouvez mettre à niveau le plan de contrôle d'un cluster d'utilisateur séparément des pools de nœuds. Cette flexibilité peut vous aider à planifier plusieurs intervalles de maintenance plus courts au lieu d'un seul intervalle de maintenance long pour mettre à niveau l'ensemble du cluster. Pour en savoir plus, consultez Mettre à niveau les pools de nœuds.

Sauvegarder le cluster d'utilisateur et le cluster administrateur

Avant de commencer la migration, sauvegardez vos clusters d'utilisateur et d'administrateur.

Une sauvegarde de cluster d'utilisateur est un instantané du magasin etcd du cluster d'utilisateur. Le magasin etcd contient tous les objets Kubernetes et les objets personnalisés requis pour gérer l'état du cluster. L'instantané contient les données requises pour recréer les composants et les charges de travail du cluster. Pour en savoir plus, découvrez comment sauvegarder un cluster d'utilisateur.

Avec Google Distributed Cloud version 1.8 ou ultérieure, vous pouvez configurer la sauvegarde automatique avec clusterBackup.datastore dans le fichier de configuration du cluster d'administrateur. Pour activer cette fonctionnalité dans un cluster existant, modifiez le fichier de configuration du cluster d'administrateur et ajoutez le champ clusterBackup.datastore, puis exécutez gkectl update admin.

Une fois clusterBackup.datastore activé, votre cluster d'administrateur est automatiquement sauvegardé dans etcd sur le datastore vSphere configuré. Ce processus de sauvegarde se répète chaque fois que le cluster d'administrateur est modifié. Lorsque vous lancez une mise à niveau de cluster, une tâche de sauvegarde s'exécute avant la mise à niveau du cluster.

Pour restaurer un cluster d'administrateur à partir de sa sauvegarde en cas de problème, consultez Sauvegarder et restaurer un cluster d'administrateur avec gkectl.

Examiner l'utilisation de PodDisruptionBudgets

Dans Kubernetes, les PodDisruptionBudgets (PDB) peuvent aider à éviter les temps d'arrêt ou les pannes d'application indésirables. Les PDB indiquent au planificateur de toujours maintenir un certain nombre de pods en cours d'exécution, tandis que d'autres pods peuvent échouer. Ce comportement est un moyen utile d'assurer la disponibilité des applications.

  1. Pour vérifier les PDB configurés dans votre cluster, utilisez la commande kubectl get pdb :

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Remplacez KUBECONFIG par le nom de votre fichier kubeconfig.

    L'exemple de sortie suivant montre les PDB nommés istio-ingress, istiod et kube-dns :

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Dans le tableau précédent, chaque PDB spécifie qu'au moins un pod doit toujours être disponible. Cette disponibilité devient essentielle lors des mises à niveau lorsque les nœuds sont vidés.

Recherchez les PDB qui ne peuvent pas être exécutés. Par exemple, vous pouvez définir une disponibilité minimale de 1 lorsque le déploiement ne comporte qu'un seul réplica. Dans cet exemple, l'opération de vidange est interrompue, car le contrôleur de ressources ne peut pas satisfaire le PDB.

Pour vous assurer que les PDB n'interfèrent pas avec la procédure de mise à niveau, vérifiez toutes les PDB d'un cluster donné avant de commencer la mise à niveau. Vous devrez peut-être coordonner avec les équipes de développement et les propriétaires d'applications pour modifier ou désactiver temporairement les PDB lors de la mise à niveau d'un cluster.

Google Distributed Cloud exécute une vérification préliminaire lors du processus de mise à niveau pour vous avertir des PDB. Toutefois, vous devez également vérifier manuellement les PDB pour garantir une expérience de mise à niveau fluide. Pour en savoir plus sur les PDB, consultez Spécifier un budget d'interruption pour votre application.

Examiner les adresses IP disponibles

Les considérations suivantes s'appliquent aux adresses IP lors des mises à niveau de clusters d'utilisateur et de clusters d'administrateur sans haute disponibilité (c'est-à-dire les clusters d'administrateur qui ne sont pas à haute disponibilité) :

  • Le processus de mise à niveau du cluster crée un nœud et vide les ressources avant de supprimer l'ancien nœud. Nous vous recommandons de toujours disposer de N+1 adresses IP pour le cluster, où N est le nombre de nœuds du cluster. Cette recommandation ne s'applique qu'aux clusters d'administrateur non HA (qui ne comportent qu'un seul nœud de plan de contrôle) et aux clusters d'utilisateur.

  • Lorsque vous utilisez des adresses IP statiques, les adresses IP requises doivent être listées dans les fichiers de bloc d'adresses IP.

    • Lorsque vous mettez à niveau des clusters d'administrateur non HD, ajoutez l'adresse IP supplémentaire dans le fichier de bloc d'adresses IP utilisé par le cluster d'administrateur. Le chemin d'accès à ce fichier doit être spécifié dans le champ network.ipMode.ipBlockFilePath du fichier de configuration du cluster d'administrateur.
    • Lorsque vous mettez à niveau des clusters d'utilisateur, ajoutez l'adresse IP supplémentaire dans le fichier de bloc d'adresses IP utilisé par le cluster d'utilisateur. Le chemin d'accès à ce fichier doit être spécifié dans le champ network.ipMode.ipBlockFilePath du fichier de configuration du cluster d'utilisateur.

  • Si vous utilisez DHCP, assurez-vous que les nouvelles VM peuvent obtenir des baux d'adresse IP supplémentaires dans le sous-réseau applicable lors d'une mise à niveau.

    Si vous devez ajouter des adresses IP, mettez à jour le fichier de bloc d'adresses IP, puis exécutez la commande gkectl update. Pour en savoir plus, consultez la section Planifier les adresses IP.

  • Si vous utilisez des adresses IP statiques et que vous souhaitez accélérer le processus de mise à niveau du cluster d'utilisateur, indiquez suffisamment d'adresses IP dans votre fichier de blocs d'adresses IP pour que chaque pool de nœuds dispose d'une adresse IP supplémentaire. Cette approche permet d'accélérer le processus d'ajout et de suppression de VM, car il est effectué au niveau de chaque pool de nœuds.

    Bien que cette approche soit une bonne option pour accélérer la mise à niveau des clusters d'utilisateurs, tenez compte de la disponibilité des ressources et des performances de votre environnement vSphere avant de continuer.

  • S'il n'y a qu'une seule adresse IP de secours pour l'ensemble du cluster d'utilisateur, cette limitation ralentit le processus de mise à niveau à une seule VM à la fois, même si plusieurs pools de nœuds sont utilisés.

Les clusters d'administrateur HA ne nécessitent pas N+1 adresses IP pour les mises à niveau. Les trois nœuds du plan de contrôle d'un cluster d'administrateur à haute disponibilité sont recréés un par un, ce qui garantit qu'aucune adresse IP supplémentaire n'est nécessaire.

Vérifier l'utilisation du cluster

Assurez-vous que les pods peuvent être évacués lorsque le nœud est drainé et qu'il y a suffisamment de ressources dans le cluster en cours de mise à niveau pour gérer la mise à niveau. Pour vérifier l'utilisation actuelle des ressources du cluster, vous pouvez utiliser des tableaux de bord personnalisés dans Google Cloud Observability ou directement sur le cluster à l'aide de commandes telles que kubectl top nodes.

Les commandes que vous exécutez sur le cluster vous donnent un aperçu de l'utilisation actuelle des ressources du cluster. Les tableaux de bord peuvent fournir une vue plus détaillée des ressources consommées au fil du temps. Ces données sur l'utilisation des ressources peuvent vous aider à déterminer le moment où une mise à niveau entraînerait le moins de perturbations, par exemple le week-end ou le soir, en fonction de la charge de travail et des cas d'utilisation en cours.

Le calendrier de mise à niveau du cluster d'administrateur peut être moins critique que celui des clusters d'utilisateur, car une mise à niveau du cluster d'administrateur n'entraîne généralement pas de temps d'arrêt des applications. Toutefois, il est toujours important de vérifier la disponibilité des ressources dans vSphere avant de commencer la mise à niveau d'un cluster d'administrateur. De plus, la mise à niveau du cluster d'administrateur peut impliquer certains risques. Il est donc recommandé de la réaliser pendant les périodes d'utilisation moins actives, lorsque l'accès à la gestion du cluster est moins critique.

Pour en savoir plus, consultez Quels services sont concernés par la mise à niveau d'un cluster ?.

Vérifier l'utilisation de vSphere

Vérifiez que l'infrastructure vSphere sous-jacente dispose de suffisamment de ressources. Pour vérifier cette utilisation des ressources, sélectionnez un cluster dans vCenter et consultez l'onglet Résumé.

L'onglet "Récapitulatif" affiche la consommation globale de mémoire, de processeur et de stockage de l'ensemble du cluster. Étant donné que les mises à niveau de Google Distributed Cloud nécessitent des ressources supplémentaires, vous devez également vérifier si le cluster peut gérer ces demandes de ressources supplémentaires.

En règle générale, votre cluster vSphere doit pouvoir prendre en charge les ressources supplémentaires suivantes :

  • +1 VM par mise à niveau du cluster d'administrateur
  • +1 VM par pool de nœuds par mise à niveau du cluster d'utilisateur

Par exemple, supposons qu'un cluster d'utilisateur comporte trois pools de nœuds, où chaque pool de nœuds comporte des nœuds utilisant huit vCPU et 32 Go de RAM ou plus. Étant donné que la mise à niveau se produit en parallèle pour les trois pools de nœuds par défaut, la procédure de mise à niveau consomme les ressources supplémentaires suivantes pour les trois nœuds de surutilisation supplémentaires :

  • 24 processeurs virtuels
  • 96 Go de RAM
  • Espace disque de la VM + 96 Go de vSwap

Le processus de mise à niveau crée des VM à l'aide de l'opération de clonage vSphere. Le clonage de plusieurs VM à partir d'un modèle peut exercer une pression sur le système de stockage sous-jacent sous la forme d'une augmentation des opérations d'E/S. La mise à niveau peut être considérablement ralentie si le sous-système de stockage sous-jacent ne peut pas fournir de performances suffisantes pendant la mise à niveau.

Bien que vSphere soit conçu pour une utilisation simultanée des ressources et dispose de mécanismes permettant de fournir des ressources, même en cas de surallocation, nous vous recommandons vivement de ne pas surallouer la mémoire de la VM. La surallocation de mémoire peut avoir un impact important sur les performances de l'ensemble du cluster, car vSphere fournit la "RAM manquante" en échangeant des pages avec le datastore. Ce comportement peut entraîner des problèmes lors de la mise à niveau d'un cluster et avoir un impact sur les performances des autres VM en cours d'exécution sur le cluster vSphere.

Si les ressources disponibles sont déjà rares, mettez hors tension les VM inutiles pour répondre à ces exigences supplémentaires et éviter une éventuelle baisse des performances.

Vérifier l'état et la configuration du cluster

Exécutez les outils suivants sur tous les clusters avant la mise à niveau :

  • La commande gkectl diagnose : gkectl diagnose garantit que tous les clusters sont opérationnels. La commande exécute des vérifications avancées, par exemple pour identifier les nœuds qui ne sont pas configurés correctement ou qui ont des pods bloqués. Si la commande gkectl diagnose affiche un avertissement Cluster unhealthy, corrigez les problèmes avant de tenter une mise à niveau. Pour en savoir plus, consultez Diagnostiquer les problèmes de cluster.

  • L'outil de pré-mise à niveau : en plus de vérifier l'état et la configuration du cluster, il recherche les problèmes connus potentiels qui pourraient survenir lors de la mise à niveau du cluster.

De plus, lorsque vous mettez à niveau des clusters d'utilisateur vers la version 1.29 ou ultérieure, nous vous recommandons d'exécuter la commande gkectl upgrade cluster avec l'indicateur --dry-run. L'indicateur --dry-run exécute des vérifications préliminaires, mais ne lance pas le processus de mise à niveau. Bien que les versions antérieures de Google Distributed Cloud exécutent des vérifications préliminaires, elles ne peuvent pas être exécutées séparément de la mise à niveau. En ajoutant l'indicateur --dry-run, vous pouvez identifier et résoudre les problèmes détectés par les vérifications préliminaires avec votre cluster d'utilisateur avant la mise à niveau.

Utiliser des déploiements pour minimiser les interruptions d'application

Étant donné que les nœuds doivent être drainés lors des mises à jour, les mises à niveau de cluster peuvent entraîner des interruptions d'application. Drainer les nœuds signifie que tous les pods en cours d'exécution doivent être arrêtés et redémarrés sur les nœuds restants du cluster.

Si possible, vos applications doivent utiliser des déploiements. Avec cette approche, les applications sont conçues pour gérer les interruptions. L'impact sur les déploiements comportant plusieurs répliques doit être minime. Vous pouvez toujours mettre à niveau votre cluster si les applications n'utilisent pas de déploiements.

Il existe également des règles pour les déploiements afin de s'assurer qu'un nombre défini de réplicas est toujours en cours d'exécution. Ces règles sont appelées PodDisruptionBudgets (PDB). Les PDB vous permettent de limiter les interruptions d'une charge de travail lorsque ses pods doivent être reprogrammés pour une raison quelconque, par exemple en cas de mise à niveau ou de maintenance des nœuds du cluster. Il est important de les vérifier avant une mise à niveau.

Utiliser une paire d'équilibreurs de charge à haute disponibilité

Si vous utilisez Seesaw comme équilibreur de charge sur un cluster, les équilibreurs de charge sont mis à niveau automatiquement lorsque vous mettez à niveau le cluster. Cette mise à niveau peut entraîner une interruption du service. Pour réduire l'impact d'une mise à niveau et d'une éventuelle défaillance de l'équilibreur de charge, vous pouvez utiliser une paire haute disponibilité. Dans cette configuration, le système crée et configure deux VM d'équilibreur de charge afin qu'un basculement vers l'autre pair puisse avoir lieu.

Pour améliorer la disponibilité du service (c'est-à-dire du serveur d'API Kubernetes), nous vous recommandons d'utiliser toujours une paire HA devant le cluster d'administrateur. Pour en savoir plus sur Seesaw et sa configuration HA, consultez la documentation de la version 1.16 Équilibrage de charge groupé avec Seesaw.

Pour éviter toute interruption de service lors d'une mise à niveau avec une paire HA, le cluster lance un basculement avant de créer la VM de l'équilibreur de charge. Si un cluster d'utilisateur n'utilise qu'une seule instance d'équilibreur de charge, le service est interrompu jusqu'à la fin de la mise à niveau de l'équilibreur de charge.

Nous vous recommandons d'utiliser une paire d'équilibreurs de charge haute disponibilité si le cluster d'utilisateur lui-même est également configuré pour être hautement disponible. Cette série de bonnes pratiques part du principe qu'un cluster d'utilisateur HA utilise une paire d'équilibreurs de charge HA.

Si vous utilisez MetalLB comme équilibreur de charge groupé, aucune configuration avant la mise à niveau n'est requise. L'équilibreur de charge est mis à niveau lors de la mise à niveau du cluster.

Déterminer comment mettre à niveau chaque cluster d'utilisateur

Dans la version 1.14 et les versions ultérieures, vous pouvez choisir de mettre à niveau un cluster d'utilisateur dans son ensemble (ce qui signifie que vous pouvez mettre à niveau le plan de contrôle et tous les pools de nœuds du cluster), ou mettre à niveau le plan de contrôle du cluster d'utilisateur et laisser les pools de nœuds à la version actuelle. Pour savoir pourquoi vous pourriez vouloir mettre à niveau le plan de contrôle séparément, consultez la section Mises à niveau du cluster d'utilisateur.

Dans un environnement multicluster, suivez les clusters d'utilisateurs qui ont été mis à niveau et notez leur numéro de version. Si vous décidez de mettre à niveau le plan de contrôle et les pools de nœuds séparément, notez la version du plan de contrôle et de chaque pool de nœuds dans chaque cluster.

Vérifier les versions des clusters d'utilisateurs et d'administrateurs

gkectl

  • Pour vérifier la version des clusters d'utilisateurs :

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

  • Pour vérifier la version des clusters d'administrateurs :

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

CLI gcloud

Pour les clusters enregistrés dans l'API GKE On-Prem, vous pouvez utiliser gcloud CLI afin d'obtenir les versions des clusters d'utilisateurs, des pools de nœuds sur le cluster d'utilisateur et des clusters d'administrateurs.

  1. Assurez-vous de disposer de la dernière version de gcloud CLI. Mettez à jour les composants de gcloud CLI, si nécessaire :

    gcloud components update

  2. Exécutez les commandes suivantes pour vérifier les versions :

  • Pour vérifier la version des clusters d'utilisateurs :

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    PROJECT_ID est l'ID de votre projet hôte de parc.

    Lorsque vous définissez --location=-, cela signifie que vous souhaitez lister tous les clusters de toutes les régions. Si vous devez limiter la liste, définissez --location sur la région que vous avez spécifiée lorsque vous avez enregistré le cluster.

    Le résultat de la commande inclut la version du cluster.

  • Pour vérifier la version des clusters d'administrateurs :

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Vérifiez la version des nœuds du cluster :

Vous pouvez utiliser kubectl pour obtenir la version des nœuds de cluster, mais kubectl renvoie la version de Kubernetes. Pour obtenir la version Google Distributed Cloud correspondant à une version Kubernetes, consultez Gestion des versions.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.

Vérifier si les certificats CA doivent être renouvelés

Lors d'une mise à niveau, les certificats feuilles sont alternés, mais pas les certificats d'autorité de certification. Vous devez effectuer une rotation manuelle de vos certificats d'autorité de certification au moins une fois tous les cinq ans. Pour en savoir plus, consultez Effectuer une rotation des autorités de certification de cluster d'utilisateur et Effectuer une rotation des certificats CA de cluster d'administrateur.

Différences entre les types de clusters

Il existe deux types de clusters :

  • Cluster d'utilisateur
  • Cluster d'administrateur

Selon la façon dont vous créez un cluster d'utilisateur, il peut contenir à la fois des nœuds de calcul et des nœuds de plan de contrôle (Controlplane V2) ou uniquement des nœuds de calcul (kubeception). Avec kubeception, le plan de contrôle d'un cluster d'utilisateur s'exécute sur un ou plusieurs nœuds d'un cluster d'administrateur. Dans les deux cas, dans la version 1.14 et les versions ultérieures, vous pouvez mettre à jour le plan de contrôle d'un cluster d'utilisateur séparément des pools de nœuds qui exécutent vos charges de travail.

Différents effets des mises à niveau de clusters d'utilisateurs et d'administrateurs

La procédure de mise à niveau de Google Distributed Cloud implique un processus de vidage de nœud qui supprime tous les pods d'un nœud. Ce processus crée une VM pour chaque nœud de calcul drainé et l'ajoute au cluster. Les nœuds de calcul vidés sont ensuite supprimés de l'inventaire VMware. Au cours de ce processus, toute charge de travail exécutée sur ces nœuds est arrêtée et redémarrée sur d'autres nœuds disponibles du cluster.

Selon l'architecture de charge de travail choisie, cette procédure peut avoir un impact sur la disponibilité d'une application. Pour éviter de trop solliciter les capacités de ressources du cluster, Google Distributed Cloud met à niveau un nœud à la fois.

Interruption du cluster d'utilisateur

Le tableau suivant décrit l'impact d'une mise à niveau sur place d'un cluster d'utilisateur :

Fonction Cluster d'administrateur Cluster d'utilisateur sans HA Cluster d'utilisateur HA
Accès aux API Kubernetes Non affecté Non affecté Non affecté
Charges de travail de l'utilisateur Non affecté Non affecté Non affecté
Budgets d'interruptions de pods* Non affecté Non affecté Non affecté
Nœud du plan de contrôle Non affecté Affecté Non affecté
Autoscaler de pod (VMware) Non affecté Non affecté Non affecté
Réparation automatique Non affecté Non affecté Non affecté
Autoscaling de nœud (VMware) Non affecté Non affecté Non affecté
Autoscaling horizontal des pods Affecté Affecté Non affecté
  • * : Les PDB peuvent entraîner l'échec ou l'arrêt de la mise à niveau.
  • Affecté : une interruption de service pendant la mise à niveau est perceptible jusqu'à la fin de la mise à niveau.
  • Non affecté : une interruption de service peut se produire pendant une très courte période, mais elle est presque imperceptible.

Les nœuds du plan de contrôle du cluster d'utilisateur, qu'ils s'exécutent sur le cluster d'administrateur (kubeception) ou sur le cluster d'utilisateur lui-même (Controlplane V2), n'exécutent aucune charge de travail utilisateur. Lors d'une mise à niveau, ces nœuds du plan de contrôle sont drainés, puis mis à jour en conséquence.

Dans les environnements avec des plans de contrôle à haute disponibilité, la mise à niveau du plan de contrôle d'un cluster d'utilisateur ne perturbe pas les charges de travail des utilisateurs. Dans un environnement à haute disponibilité, la mise à niveau d'un cluster d'administrateur ne perturbe pas les charges de travail des utilisateurs. Pour les clusters d'utilisateur utilisant Controlplane V2, la mise à niveau du plan de contrôle uniquement ne perturbe pas les charges de travail des utilisateurs.

Lors d'une mise à niveau dans un environnement de plan de contrôle non HA, le plan de contrôle ne peut pas contrôler les actions de mise à l'échelle, de récupération ou de déploiement des pods. Pendant la brève interruption du plan de contrôle lors de la mise à niveau, les charges de travail des utilisateurs peuvent être affectées si elles sont dans un état de scaling, de déploiement ou de récupération. Cela signifie que les déploiements échoueront lors d'une mise à niveau dans un environnement non HA.

Pour améliorer la disponibilité et réduire les interruptions des clusters d'utilisateurs de production lors des mises à niveau, nous vous recommandons d'utiliser trois nœuds de plan de contrôle (mode haute disponibilité).

Interruption du cluster d'administrateur

Le tableau suivant décrit l'impact d'une mise à niveau sur place d'un cluster d'administrateur :

Fonction Cluster d'administrateur Cluster d'utilisateur sans HA Cluster d'utilisateur HA
Accès aux API Kubernetes Affecté Affecté Non affecté
Charges de travail de l'utilisateur Non affecté Non affecté Non affecté
Nœud du plan de contrôle Affecté Affecté Non affecté
Autoscaler de pod Affecté Affecté Non affecté
Réparation automobile Affecté Affecté Non affecté
Autoscaling des nœuds Affecté Affecté Non affecté
Autoscaling horizontal des pods Affecté Affecté Non affecté
  • Affecté : une interruption de service pendant la mise à niveau est perceptible jusqu'à la fin de la mise à niveau.
  • Non affecté : une interruption de service peut se produire pendant une très courte période, mais elle est presque imperceptible.

Étapes suivantes