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

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

Si vous disposez de plusieurs environnements, tels que test, développement et production, nous vous recommandons de commencer par l'environnement le moins critique, tel que test, 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 ce processus jusqu'à ce que vous ayez mis à 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 fonctionnent toutes 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 perturbatrices. 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 après les heures ouvrées 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 de manière séquentielle, car chaque nœud doit être drainé et recréé. Par conséquent, la durée totale d'une mise à niveau dépend du nombre de nœuds dans le plus grand pool de nœuds. Pour calculer une estimation approximative du temps de mise à niveau, multipliez 15 minutes par 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, 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 planification 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 notes 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 réduit de moitié le temps qu'il faudrait pour mettre à niveau deux versions de pool de nœuds de manière séquentielle. De plus, les mises à niveau avec saut de version 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 réduit les perturbations de la charge de travail et le temps de vérification. Pour en savoir plus, consultez la section 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 fenêtres de maintenance plus courtes au lieu d'une longue fenêtre de maintenance 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 la section Sauvegarder et restaurer un cluster d'administrateur à l'aide de gkectl.

Examiner l'utilisation de PodDisruptionBudgets

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

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 critique lors des mises à niveau lorsque les nœuds sont épuisés.

Recherchez les PDB qui ne peuvent pas être traités. Par exemple, vous pouvez définir une disponibilité minimale de 1, lorsque le déploiement ne comporte qu'une seule instance dupliquée. Dans cet exemple, l'opération de vidage est interrompue, car le contrôleur de ressources ne peut pas répondre à la 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 commencer 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 de cluster.

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

Examiner les adresses IP disponibles

Les considérations suivantes s'appliquent aux mises à niveau des clusters d'utilisateurs et des clusters d'administrateur non haute disponibilité (c'est-à-dire des clusters d'administrateur qui ne sont pas hautement disponibles):

• Le processus de mise à niveau du cluster crée un nouveau nœud et vide les ressources avant de supprimer l'ancien. 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'utilisateurs.

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

  • Lors de la mise à niveau de clusters d'administrateur non haute disponibilité, 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.
  • Lors de la mise à niveau des clusters d'utilisateurs, 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 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 blocs 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 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 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 d'adresses IP N+1 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 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 à déterminer quand une mise à niveau causera le moins de perturbations, par exemple les week-ends ou les soirs, en fonction de la charge de travail en cours d'exécution et des cas d'utilisation.

Le calendrier de la mise à niveau du cluster d'administrateur peut être moins critique que celui des clusters d'utilisateurs, 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 disponibles 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 la section Services concernés lors de la mise à niveau d'un cluster.

Vérifier l'utilisation de vSphere

Vérifiez qu'il existe 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 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 entraîner une surcharge du 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 sur-engagement, nous vous recommandons vivement de ne pas sur-engager la mémoire de la VM. Le surengagement de mémoire peut avoir un impact sérieux sur les performances de l'ensemble du cluster, car vSphere fournit la "RAM manquante" en échangeant des pages vers 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à limitées, arrêtez les VM inutiles pour répondre à ces exigences supplémentaires et éviter une baisse de performances potentielle.

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 la section Diagnostiquer les problèmes de cluster.

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

De plus, lorsque vous mettez à niveau des clusters d'utilisateurs 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 perturbations des applications

Comme les nœuds doivent être drainés lors des mises à jour, les mises à niveau de cluster peuvent entraîner des interruptions d'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. Tout impact devrait être minimal sur les déploiements qui comportent plusieurs réplications. Vous pouvez toujours mettre à niveau votre cluster si les applications n'utilisent pas de déploiements.

Des règles sont également définies pour les déploiements afin de s'assurer qu'un nombre défini d'instances répliquées s'exécute toujours. 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, comme des mises à niveau ou une maintenance sur les 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 de 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é (paire HA). Dans cette configuration, le système crée et configure deux VM d'équilibrage de charge afin qu'un basculement vers l'autre paire puisse se produire.

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 d'équilibrage 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 préalable à la mise à niveau n'est requise. L'équilibreur de charge est mis à niveau lors du processus de 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, 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'utilisateurs et d'administrateurs

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 à une version Kubernetes, consultez la section 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 remplacés

Lors d'une mise à niveau, les certificats de feuilles sont remplacé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. Le processus crée une VM pour chaque nœud de travail drainé et l'ajoute au cluster. Les nœuds de calcul vidé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 d'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 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 :

• * : 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'utilisateurs qui utilisent 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 haute disponibilité, le plan de contrôle ne peut pas contrôler les actions d'ajustement, de récupération ou de déploiement des pods. Lors de la courte interruption du plan de contrôle lors de la mise à niveau, les charges de travail des utilisateurs peuvent être affectées si elles se trouvent 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 haute disponibilité.

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 :

• 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

• Mettre à niveau un cluster ou un pool de nœuds