Bonnes pratiques de mise à niveau des clusters Google Distributed Cloud

Ce document décrit les bonnes pratiques et les points à prendre en compte pour la mise à niveau de Google Distributed Cloud. Vous apprendrez à vous préparer aux mises à niveau des clusters 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, 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 à 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 soit aussi fluide que possible, vérifiez et effectuez les vérifications suivantes avant de commencer la mise à niveau de vos clusters:

Planifier la mise à niveau

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

Estimer le temps consacré 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, 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 calculer une estimation approximative de la durée de la mise à niveau, utilisez 15 minutes * le nombre de nœuds dans le pool de nœuds le plus volumineux. Par exemple, si vous avez 10 nœuds dans le pool le plus grand, 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 commencer 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.

À partir de la version 1.8 de Google Distributed Cloud, 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 du cluster.

Si vous rencontrez des problèmes, consultez la page Sauvegarder et restaurer un cluster d'administrateur avec gkectl pour restaurer un cluster d'administrateur à partir de sa sauvegarde.

Vérifier l'utilisation de PodDisruptionBudgets

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

  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 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 drainés.

Recherchez les PDB qui ne peuvent pas être traitées. 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 du cluster.

Google Distributed Cloud exécute une vérification préliminaire pendant le processus de mise à niveau pour avertir les PDB. Toutefois, vous devez également vérifier manuellement les PDB pour garantir 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 s'appliquent aux adresses IP 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 d'adresses IP N+1 pour le cluster d'administrateur ou d'utilisateur, où N correspond au 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 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 bloc d'adresses IP, puis exécutez la commande gkectl update. Pour en savoir plus, consultez Planifier vos adresses IP.
  • Si vous utilisez des adresses IP statiques et souhaitez accélérer le processus de mise à niveau du cluster d'utilisateur, répertoriez suffisamment d'adresses IP dans votre fichier de blocage 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 VM, car elle est effectuée par 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 vers une seule VM à la fois, même lorsque plusieurs pools de nœuds sont utilisés.

Vérifier l'utilisation des clusters

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

Le timing de la mise à niveau du cluster d'administrateur peut être moins important 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 vérifier les ressources gratuites dans vSphere avant de commencer une mise à niveau du cluster d'administrateur. En outre, la mise à niveau du cluster d'administrateur peut entraîner un risque et peut donc être recommandée pendant les périodes d'utilisation moins actives lorsque l'accès à la gestion du cluster est moins critique.

Pour en savoir plus, consultez la section Services concernés par la 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 cette utilisation des ressources, sélectionnez un cluster dans vCenter et consultez l'onglet Summary (Résumé).

L'onglet de résumé 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 être compatible avec les ressources supplémentaires suivantes:

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

Par exemple, supposons qu'un cluster d'utilisateur comporte trois pools de nœuds, chacun comportant des nœuds utilisant huit processeurs virtuels et au moins 32 Go de RAM. Étant donné que la mise à niveau s'effectue par défaut en parallèle pour les trois pools de nœuds, 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 entraîner des contraintes sur le système de stockage sous-jacent en raison de l'augmentation des opérations d'E/S. La mise à niveau peut être fortement ralentie si le sous-système de stockage sous-jacent n'est pas en mesure de fournir des performances suffisantes lors d'une mise à niveau.

Bien que vSphere soit conçu pour une utilisation simultanée de ressources et dispose de mécanismes permettant de fournir des ressources, même en cas de sursollicitation, nous vous recommandons vivement de ne pas sursolliciter la mémoire de la VM. Le surengagement de la mémoire peut avoir de graves conséquences sur les performances et affecter l'ensemble du cluster, car vSphere fournit la "RAM manquante" pour le remplacement 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 des autres VM en cours d'exécution sur le cluster vSphere.

Si les ressources disponibles sont déjà limitées, éteignez les VM inutiles pour répondre à ces exigences supplémentaires et éviter tout risque de 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 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 potentiels pouvant survenir lors de la mise à niveau du cluster.

De plus, 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 effectuent des vérifications préliminaires, elles ne peuvent pas être exécutées séparément de la mise à niveau. L'ajout de l'indicateur --dry-run vous permet de rechercher et de résoudre les problèmes détectés par les vérifications préliminaires sur votre cluster d'utilisateur avant la mise à niveau.

Utiliser des déploiements pour limiter les perturbations au niveau de l'application

Étant donné que les nœuds doivent être drainés lors des mises à jour, les mises à niveau des clusters peuvent entraîner des perturbations au niveau de l'application. Le drainage des 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 devrait être minime sur les déploiements comportant plusieurs instances répliquées. 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 qui garantissent 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 les perturbations d'une charge de travail lorsque ses pods doivent être reprogrammés pour une raison quelconque, telle que les mises à niveau ou la maintenance sur les nœuds de cluster. Ils sont également importants à 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 lors de la mise à niveau du 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'équilibreur de charge afin qu'un basculement vers l'autre pair puisse avoir lieu.

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 toute 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'à la fin de la mise à niveau de l'équilibreur de charge.

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 une disponibilité élevée. Cette série de bonnes pratiques part du principe 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 lors du processus de mise à niveau du cluster.

Décider 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). Vous pouvez également mettre à niveau le plan de contrôle du cluster d'utilisateur et conserver la version actuelle des pools de nœuds. Pour en savoir plus sur les raisons pour lesquelles vous pouvez mettre à niveau le plan de contrôle séparément, consultez la section Mises à niveau des clusters d'utilisateur.

Dans un environnement multicluster, suivez les 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 de chaque pool de nœuds dans 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 de votre parc.

    Lorsque vous définissez --location=-, cela signifie que tous les clusters de toutes les régions sont répertoriés. Si vous devez réduire 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 du 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 Alterner les autorités de certification du cluster d'utilisateur et Alterner les certificats CA du cluster d'administrateur.

Différences entre les types de clusters

Il existe deux types de clusters différents:

  • Cluster d'utilisateur
  • Cluster d'administrateur

Selon la manière dont vous créez un cluster d'utilisateur, celui-ci 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 du cluster d'utilisateur et du cluster d'administrateur

La procédure de mise à niveau de Google Distributed Cloud implique un processus de drainage des nœuds 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 de 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.

Selon 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 excessive 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 du 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 des utilisateurs 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 pendant la mise à niveau est perceptible jusqu'à la fin de celle-ci.
  • Non affecté: une interruption de service peut se produire dans un très court laps de temps, mais elle est presque invisible.

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

Dans les environnements dotés 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 le plan de contrôle 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. 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 échouent lors d'une mise à niveau dans un environnement standard.

Pour améliorer la disponibilité et réduire les perturbations des clusters d'utilisateur de production pendant les mises à niveau, nous vous recommandons d'utiliser trois nœuds de 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 du 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 des utilisateurs 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 pendant la mise à niveau est perceptible jusqu'à la fin de celle-ci.
  • Non affecté: une interruption de service peut se produire dans un très court laps de temps, mais elle est presque invisible.

Étapes suivantes