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 migrer vers Google Distributed Cloud. Vous apprendrez à vous préparer aux mises à niveau de clusters et à suivre les bonnes pratiques avant la mise à niveau. Ces bonnes pratiques permettent de réduire les risques associés aux mises à niveau de clusters.

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 migré 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 perturbatrices. Avant de commencer la mise à niveau, planifiez soigneusement la migration pour vous assurer que votre environnement et vos applications sont prêts.

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, mais dans chaque pool de nœuds, les nœuds sont mis à niveau de manière séquentielle. Le temps total d'une mise à niveau dépend donc du nombre de nœuds du plus grand pool de nœuds. Pour estimer approximativement 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 vous disposez de 10 nœuds dans le plus grand pool, le temps total de mise à niveau est d'environ 150 minutes.

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.

Sauvegarder le cluster d'utilisateur et le cluster d'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 à l'aide de gkectl.

Examiner l'utilisation de PodDisruptionBudgets

Dans Kubernetes, les PodDisruptionBudgets (PDB) peuvent aider à éviter les interruptions ou les temps d'arrêt inattendus des applications. 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 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 essentielle 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'un seul réplica. Dans cet exemple, l'opération de vidage est interrompue, car le PDB ne peut pas être satisfait par le contrôleur de ressources.

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 coordonner vos actions 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 effectue 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 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 :

• 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 d'administrateur ou d'utilisateur, où N est 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 bloc 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 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é 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.

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 entraînera le moins de perturbations, par exemple le week-end ou le soir, en fonction de la charge de travail en cours et des cas d'utilisation.

Le moment 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 d'indisponibilité 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 Services impactés lors de 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ésumé" indique 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
• 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 une surcharge du 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 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 pour fournir des ressources, même en cas de surengagement, nous vous recommandons vivement de ne pas surcharger la mémoire de la VM. L'utilisation excessive de la mémoire peut avoir de graves conséquences 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, éteignez les VM inutiles pour répondre à ces exigences supplémentaires et éviter une baisse potentielle 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 effectue des vérifications avancées, par exemple pour identifier les nœuds qui ne sont pas correctement configurés ou qui ont des pods bloqués. Si la commande gkectl diagnose affiche un avertissement Cluster unhealthy, corrigez les problèmes avant d'effectuer la 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, l'outil de pré-mise à niveau recherche les problèmes connus susceptibles de se produire lors d'une mise à niveau du cluster.

De plus, lorsque vous mettez à niveau les 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 les 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 les déploiements pour minimiser les interruptions d'application

Étant donné que les nœuds doivent être vidés lors des mises à jour, les mises à niveau du cluster peuvent entraîner des interruptions d'application. Vider 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 devrait être minime pour les déploiements comportant plusieurs réplicas. Vous pouvez toujours mettre à niveau votre cluster si les applications n'utilisent pas les déploiements.

Il existe également des règles pour les déploiements afin de s'assurer qu'un certain nombre de réplicas reste toujours en cours d'exécution. 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, 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'équilibrage 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 de permettre un basculement vers l'autre paire.

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 page É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 nouvelle VM d'é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 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, 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

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 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 d'autorité de certification doivent être remplacés

Lors d'une mise à niveau, les certificats de nœud 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 calcul vidé 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, puis 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 surcharger les capacités de ressources du cluster, Google Distributed Cloud effectue la mise à niveau d'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 vidé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 HA, la mise à niveau d'un cluster d'administrateur n'interrompt pas les charges de travail des utilisateurs. Pour les clusters d'utilisateurs utilisant Controlplane V2, la mise à niveau du seul plan de contrôle 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 scaling, de récupération ou de déploiement des pods. Pendant 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 sont en cours 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 sans 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.

Étape suivante

• Mettre à niveau Anthos clusters on VMware