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

Ce document décrit les bonnes pratiques et les considérations relatives à la mise à niveau de Google Distributed Cloud. Vous allez découvrir comment préparer les mises à niveau des clusters et quelles sont 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 tels que les environnements de test, de développement et de production, nous vous recommandons de commencer par l'environnement le moins critique, tel que test, et de vérifier la fonctionnalité de mise à niveau. Après avoir vérifié que la mise à niveau a réussi, passez à l'environnement suivant. Répétez ce processus jusqu'à ce que vous mettiez à niveau vos environnements de production. Cette approche vous permet de passer d'un point critique à un 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 soit aussi fluide que possible, examinez et effectuez les vérifications suivantes avant de commencer à mettre à niveau vos clusters:

Planifier la mise à niveau

Les mises à jour peuvent être gênantes. Avant de commencer la mise à niveau, planifiez soigneusement les opérations pour vous assurer que votre environnement et vos applications sont prêts et préparés.

Estimer l'engagement en temps et planifier un intervalle de maintenance

Par défaut, tous les pools de nœuds sont mis à niveau en parallèle, mais dans chaque pool de nœuds, les nœuds sont mis à niveau de manière séquentielle. La durée totale d'une mise à niveau dépend donc du nombre de nœuds dans le plus grand pool de nœuds. Pour obtenir une estimation approximative de la durée de la mise à niveau, utilisez 15 minutes x le nombre de nœuds du plus grand pool de nœuds. Par exemple, si vous avez 10 nœuds dans le plus grand pool, le temps total de mise à niveau est d'environ 150 minutes.

À partir de la version 1.28, vous pouvez accélérer une mise à niveau en définissant la valeur de maxSurge pour chaque pool de nœuds.

Sauvegarder le cluster d'utilisateur et d'administrateur

Avant de lancer une mise à niveau, 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 du cluster, une tâche de sauvegarde s'exécute avant la mise à niveau.

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

Vérifier l'utilisation de PodDisruptionBudgets

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

  1. Pour vérifier quels PDB sont 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 résultat suivant montre des 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 drainés.

Recherchez les PDB qui ne peuvent pas être remplis. Par exemple, vous pouvez définir une disponibilité minimale de 1 lorsque le déploiement ne comporte qu'une seule instance répliquée. Dans cet exemple, l'opération de drainage 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 tous les PDB d'un cluster donné avant de lancer la mise à niveau. Vous devrez peut-être vous coordonner avec les équipes de développement et les propriétaires d'applications pour modifier ou désactiver temporairement les PDB lors d'une mise à niveau d'un cluster.

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

Examiner les adresses IP disponibles

Les considérations suivantes concernant les adresses IP s'appliquent lors des mises à niveau du cluster:

  • Le processus de mise à niveau du cluster crée un nœud et draine les ressources avant de supprimer l'ancien nœud. Nous vous recommandons de toujours disposer de N+1 adresses IP pour le cluster d'administrateur ou d'utilisateur, N étant le nombre de nœuds du cluster.
  • Lorsque vous utilisez des adresses IP statiques, les adresses IP requises doivent être répertoriées dans les fichiers de blocs d'adresses IP.
  • Si vous utilisez DHCP, assurez-vous que les nouvelles VM peuvent obtenir des baux d'adresses IP supplémentaires dans le sous-réseau souhaité lors d'une mise à niveau.
    • Si vous devez ajouter des adresses IP, mettez à jour le fichier de blocs d'adresses IP, puis exécutez la commande gkectl update. Pour en savoir plus, consultez la section Planifier vos 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 puisse disposer d'une adresse IP supplémentaire. Cette approche permet au processus d'accélérer la procédure d'ajout et de suppression de la VM, car elle est exécutée au niveau du pool de nœuds.
    • Bien que cette approche soit une bonne option pour accélérer les mises à niveau des clusters d'utilisateur, 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 lorsque plusieurs pools de nœuds sont utilisés.

Vérifier l'utilisation du cluster

Assurez-vous que les pods peuvent être évacués lorsque le nœud se draine et que le cluster en cours de mise à niveau comporte suffisamment de ressources 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 affichent un instantané 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 d'utilisation des ressources peuvent permettre d'indiquer à quel moment une mise à niveau causerait le moins de perturbations, par exemple le week-end ou en soirée, en fonction de la charge de travail en cours d'exécution et des cas d'utilisation.

Le calendrier de mise à niveau du cluster d'administrateur peut être moins critique que pour les clusters d'utilisateur, car une mise à niveau du cluster d'administrateur n'entraîne généralement pas de temps d'arrêt de l'application. Toutefois, il est toujours important de rechercher des ressources gratuites dans vSphere avant de commencer une mise à niveau du cluster d'administrateur. En outre, la mise à niveau du cluster d'administrateur peut présenter un risque. Elle peut donc être recommandée pendant les périodes de faible utilisation, lorsque l'accès à la gestion du cluster est moins critique.

Pour en savoir plus, consultez la section Quels sont les services affectés lors d'une mise à niveau d'un cluster.

Vérifier l'utilisation de vSphere

Vérifiez qu'il y a suffisamment de ressources sur l'infrastructure vSphere sous-jacente. Pour vérifier l'utilisation de ces ressources, sélectionnez un cluster dans vCenter et consultez l'onglet Summary (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 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 de cluster d'administrateur
  • +1 VM par pool de nœuds et par mise à niveau de cluster d'utilisateur

Par exemple, supposons qu'un cluster d'utilisateur dispose de trois pools de nœuds, chacun contenant des nœuds utilisant 8 processeurs virtuels et au moins 32 Go de RAM. Étant donné que la mise à niveau s'effectue 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
  • 256 Go de RAM
  • Espace disque de la VM + 256 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 stresser le système de stockage sous-jacent sous la forme d'opérations d'E/S croissantes. La mise à niveau peut être considérablement ralentie si le sous-système de stockage sous-jacent est incapable de fournir des performances suffisantes lors d'une mise à niveau.

Bien que vSphere soit conçu pour utiliser des ressources simultanément et dispose de mécanismes permettant de les fournir, même en cas de sursollicitation, nous vous recommandons vivement de ne pas sursolliciter la mémoire de la VM. Un surengagement de mémoire peut avoir de graves conséquences sur les performances, qui affectent l'ensemble du cluster, car vSphere fournit la "RAM manquante" lors de l'échange de pages vers le datastore. Ce comportement peut entraîner des problèmes lors de la mise à niveau d'un cluster et affecter les performances sur les autres VM en cours d'exécution sur le cluster vSphere.

Si les ressources disponibles sont déjà limitées, arrêtez 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 vérifie 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 dont les pods sont bloqués. Si la commande gkectl diagnose affiche un avertissement Cluster unhealthy, corrigez les problèmes avant d'effectuer une mise à niveau. Pour en savoir plus, consultez la page 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 pouvant survenir lors d'une mise à niveau du cluster.

En outre, lorsque vous mettez à niveau des clusters d'utilisateur vers la version 1.29 ou une version ultérieure, nous vous recommandons d'exécuter la commande gkectl upgrade cluster avec l'option --dry-run. L'option --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'option --dry-run, vous pouvez identifier et résoudre les problèmes détectés par les vérifications préliminaires dans votre cluster d'utilisateur avant la mise à niveau.

Utiliser des déploiements pour minimiser les perturbations sur les applications

Étant donné que les nœuds doivent être drainés lors des mises à jour, les mises à niveau des clusters peuvent entraîner des interruptions de l'application. Le drainage des nœuds implique 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 doit être minimal sur les déploiements comportant plusieurs instances répliquées. Vous pouvez toujours mettre à niveau votre cluster si les applications n'utilisent pas les déploiements.

Des règles s'appliquent également aux déploiements pour s'assurer qu'un nombre défini d'instances répliquées continuent de s'exécuter en permanence. Ces règles sont appelées PodDisruptionBudgets (PDB). Les PDB vous permettent de limiter l'interruption d'une charge de travail lorsque ses pods doivent être reprogrammés pour une raison quelconque, telle que des mises à niveau ou des opérations de maintenance sur les nœuds de 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 en tant qu'équilibreur de charge sur un cluster, ceux-ci sont mis à niveau automatiquement lorsque vous mettez à niveau le cluster. Cette mise à niveau peut entraîner une interruption de service. Pour réduire l'impact d'une mise à niveau et d'une défaillance éventuelle 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'équilibrage de charge de sorte qu'un basculement vers l'autre pair puisse se produire.

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

Pour éviter une interruption de service lors d'une mise à niveau avec une paire haute disponibilité, 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'à ce que la mise à niveau de l'équilibreur de charge soit terminée.

Nous vous recommandons de disposer d'une paire d'équilibreurs de charge haute disponibilité si le cluster d'utilisateur lui-même est également configuré pour être disponibilité élevée. Cette série de bonnes pratiques suppose qu'un cluster d'utilisateur haute disponibilité utilise une paire d'équilibreurs de charge haute disponibilité.

Si vous utilisez MetalLB en tant qu'équilibreur de charge groupé, aucune configuration préalable à la mise à niveau n'est requise. L'équilibreur de charge est mis à niveau pendant le processus de mise à niveau du cluster.

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

À partir de la version 1.14, 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 vous pouvez mettre à niveau le plan de contrôle du cluster d'utilisateur et laisser les pools de nœuds dans la version actuelle. Pour en savoir plus sur les raisons pour lesquelles vous souhaiterez peut-être mettre à niveau le plan de contrôle séparément, consultez la section Mises à niveau des clusters d'utilisateur.

Dans un environnement multicluster, effectuez le suivi des clusters d'utilisateur qui ont été mis à niveau et enregistrez 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, enregistrez la version du plan de contrôle et chaque pool de nœuds de chaque cluster.

Vérifier les versions des clusters d'utilisateur et d'administrateur

gkectl

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

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Remplacez 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'administrateur:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gcloud CLI

Pour les clusters enregistrés dans l'API GKE On-Prem, vous pouvez utiliser la gcloud CLI pour obtenir les versions des clusters d'utilisateur, des pools de nœuds du cluster d'utilisateur et des clusters d'administrateur.

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

    gcloud components update

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

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

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

    Remplacez PROJECT_ID par l'ID du projet hôte du parc.

    Lorsque vous définissez --location=-, cela signifie que tous les clusters de toutes les régions sont listés. Si vous devez limiter le champ d'application de la liste, définissez --location sur la région que vous avez spécifiée lors de l'enregistrement du cluster.

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

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

    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 correspondante pour une version de Kubernetes, consultez la page Historique 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 alternés

Lors d'une mise à niveau, les certificats d'entité finale sont alternés, mais pas les certificats CA. Vous devez alterner manuellement vos certificats CA au moins une fois tous les cinq ans. Pour en savoir plus, consultez Effectuer la rotation des autorités de certification du cluster d'utilisateur et Effectuer la rotation des certificats CA du 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, à partir de la version 1.14, vous pouvez mettre à niveau 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 des clusters d'utilisateur et des clusters d'administrateur

La procédure de mise à niveau du cloud distribué de Google implique un processus de drainage de nœud qui supprime tous les pods d'un nœud. Le processus crée une VM pour chaque nœud de calcul drainé et l'ajoute au cluster. Les nœuds de calcul drainé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 les autres nœuds disponibles du cluster.

En fonction de l'architecture choisie pour la charge de travail, cette procédure peut avoir un impact sur la disponibilité d'une application. Pour éviter une surcharge des ressources du cluster, Google Distributed Cloud met à niveau un nœud à la fois.

Perturbation 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 standard Cluster d'utilisateur haute disponibilité
Accès à l'API Kubernetes Non affecté Non affecté Non affecté
Charges de travail utilisateur Non affecté Non affecté Non affecté
PodDisruptionBudgets* 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 des nœuds (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 lors de la mise à niveau est perceptible jusqu'à la fin de celle-ci.
  • Non affecté: une interruption de service peut se produire pendant un court laps de temps, mais est presque invisible.

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 d'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 disposant de plans de contrôle à haute disponibilité, la mise à niveau du plan de contrôle d'un cluster d'utilisateur n'interrompt pas les charges de travail des utilisateurs. Dans un environnement à haute disponibilité, la mise à niveau d'un cluster d'administrateur n'interrompt pas les charges de travail des utilisateurs. Pour les clusters d'utilisateur utilisant Controlplane V2, la mise à niveau uniquement du plan de contrôle n'interrompt pas les charges de travail des utilisateurs.

Lors d'une mise à niveau dans un environnement de plan de contrôle standard, le plan de contrôle ne peut pas contrôler les actions de scaling, de récupération ou de déploiement des pods. Lors de la brève interruption du plan de contrôle lors de la mise à niveau, les charges de travail de l'utilisateur peuvent être affectées si elles se trouvent à l'é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 standard.

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

Perturbation 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 standard Cluster d'utilisateur haute disponibilité
Accès à l'API Kubernetes Affecté Affecté Non affecté
Charges de travail utilisateur Non affecté Non affecté Non affecté
Nœud du plan de contrôle Affecté Affecté Non affecté
Autoscaler de pods Affecté Affecté Non affecté
Réparation automatique 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 lors de la mise à niveau est perceptible jusqu'à la fin de celle-ci.
  • Non affecté: une interruption de service peut se produire pendant un court laps de temps, mais est presque invisible.

Étapes suivantes