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

Nous vous recommandons de suivre toutes les bonnes pratiques présentées dans ce document. Utilisez la checklist suivante pour suivre vos progrès. Chaque élément de la liste est associé à une section de ce document contenant des informations supplémentaires:

Une fois ces vérifications terminées, vous pouvez lancer le processus de mise à niveau. Surveillez la progression jusqu'à ce que tous les clusters soient mis à niveau.

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

Le temps nécessaire à la mise à niveau d'un cluster dépend du nombre de nœuds et de la densité de charge de travail qui s'exécute sur ceux-ci. Pour terminer une mise à niveau d'un cluster, définissez un intervalle de maintenance suffisamment long.

Pour obtenir une estimation approximative de la mise à niveau, utilisez 10 minutes * the number of nodes pour la mise à niveau simultanée d'un seul nœud.

Par exemple, si votre cluster comporte 50 nœuds, le temps de mise à niveau total est d'environ 500 minutes: 10 minutes * 50 nodes = 500 minutes.

Vérifier la compatibilité d'autres composants GKE Enterprise

Si votre cluster exécute des composants GKE Enterprise tels qu'Anthos Service Mesh, Config Sync, Policy Controller ou Config Controller, vérifiez la compatibilité des versions et des mises à niveau de GKE Enterprise, et vérifiez les versions compatibles avec Google Distributed Cloud avant et après la mise à niveau.

La vérification de compatibilité est basée sur le cluster d'administrateur ou d'utilisateur dans lequel Anthos Service Mesh, Config Sync, Policy Controller ou Config Controller est déployé.

Vérifier l'utilisation des ressources du cluster

Pour vous assurer que les pods peuvent être évacués lorsque le nœud se draine et que le cluster en cours de mise à niveau contient suffisamment de ressources pour gérer la mise à niveau, vérifiez l'utilisation actuelle des ressources du cluster. Pour vérifier l'utilisation des ressources de votre cluster, utilisez les tableaux de bord personnalisés de Google Cloud Observability.

Vous pouvez utiliser des commandes telles que kubectl top nodes pour obtenir l'utilisation actuelle des ressources du cluster, mais 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 pendant les week-ends ou les soirées, 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 vérifier les ressources disponibles 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.

Ressources du plan de contrôle du cluster d'administrateur

Tous les contrôleurs et tâches de mise à niveau s'exécutent dans les nœuds du plan de contrôle du cluster d'administrateur. Vérifiez la consommation des ressources de ces nœuds du plan de contrôle pour connaître les ressources de calcul disponibles. Le processus de mise à niveau nécessite généralement 1 000 millicores de processeur (1 000 mCPU) et 2 à 3 Gio de RAM pour chaque ensemble de contrôleurs de cycle de vie. Notez que l'unité de processeur "mCPU" signifie "millicore de cœur". 1 000 millicores équivaut donc à un cœur sur chaque nœud pour chaque ensemble de contrôleurs de cycle de vie. Pour réduire les ressources de calcul supplémentaires requises lors d'une mise à niveau, essayez de conserver la même version des clusters d'utilisateur.

Dans l'exemple de déploiement suivant, les deux clusters d'utilisateur emploient des versions différentes du cluster d'administrateur:

Cluster d'administrateur Cluster d'utilisateur 1 Cluster d'utilisateur 2
1.13.3 1.13.0 1.13.2

Un ensemble de contrôleurs de cycle de vie est déployé dans le contrôleur d'administration pour chaque version utilisée. Dans cet exemple, il existe trois ensembles de contrôleurs de cycle de vie : 1.13.3, 1.13.0 et 1.13.2. Chaque ensemble de contrôleurs de cycle de vie consomme au total 1 000 mCPU et 3 Gio de RAM. La consommation totale actuelle des ressources de ces contrôleurs de cycle de vie est de 3 000 mCPU et 9 Gio de RAM.

Si le cluster d'utilisateur 2 est mis à niveau vers 1.13.3, il existe désormais deux ensembles de contrôleurs de cycle de vie: 1.13.3 et 1.13.0:

Cluster d'administrateur Cluster d'utilisateur 1 Cluster d'utilisateur 2
1.13.3 1.13.0 1.13.3

Les contrôleurs de cycle de vie consomment désormais au total 2 000 mCPU et 6 Gio de RAM.

Si le cluster d'utilisateur 1 est mis à niveau vers 1.13.3, le parc s'exécute désormais tous dans la même version: 1.13.3:

Cluster d'administrateur Cluster d'utilisateur 1 Cluster d'utilisateur 2
1.13.3 1.13.3 1.13.3

Il n'y a désormais qu'un seul ensemble de contrôleurs de cycle de vie, qui consomment au total 1 000 mCPU et 3 Gio de RAM.

Dans l'exemple suivant, tous les clusters d'utilisateur utilisent la même version. Si le cluster d'administrateur est mis à niveau, seuls deux ensembles de contrôleurs de cycle de vie sont utilisés, ce qui permet de réduire la consommation de ressources de calcul:

Cluster d'administrateur Cluster d'utilisateur 1 Cluster d'utilisateur 2
1.14.0 1.13.3 1.13.3

Dans cet exemple, les contrôleurs de cycle de vie consomment à nouveau 2 000 mCPU au total et 6 Gio de RAM jusqu'à ce que tous les clusters d'utilisateur soient mis à niveau vers la même version que le cluster d'administrateur.

Si les nœuds du plan de contrôle ne disposent pas de ressources de calcul supplémentaires lors de la mise à niveau, des pods tels que anthos-cluster-operator, capi-controller-manager, cap-controller-manager ou cap-kubeadm-bootstraper peuvent s'afficher à l'état Pending. Pour résoudre ce problème, mettez à niveau certains des clusters d'utilisateur vers la même version afin de regrouper les versions et de réduire le nombre de contrôleurs de cycle de vie utilisés. Si la mise à niveau est déjà bloquée, vous pouvez également utiliser kubectl edit deployment pour modifier les déploiements en attente afin de réduire les demandes de processeur et de RAM afin qu'elles s'intègrent au plan de contrôle du cluster d'administrateur.

Le tableau suivant détaille les besoins en ressources de calcul pour différents scénarios de mise à niveau:

Cluster Ressources du cluster d'administrateur requises
Mise à niveau du cluster d'utilisateur Mise à niveau vers la même version des autres clusters: N/A

Mise à niveau vers une version différente d'autres clusters d'administrateur ou d'utilisateur : 1 000 mCPU et 3 Gio de RAM

Les clusters d'utilisateur d'un cluster hybride ont les mêmes besoins en ressources.
Mise à niveau du cluster d'administrateur (avec cluster d'utilisateur) 1 000 mCPU et 3 Gio de RAM
Mise à niveau des clusters hybrides (sans cluster d'utilisateur) Surutilisation de 1 000 mCPU et 3 Gio de RAM. Les ressources sont renvoyées après utilisation.
Autonome Surutilisation de 200 mCPU et 1 Gio de RAM. Les ressources sont renvoyées après utilisation.

Sauvegarder les clusters

Avant de lancer une mise à niveau, sauvegardez les clusters à l'aide de la commande bmctl backup cluster.

Étant donné que le fichier de sauvegarde contient des informations sensibles, stockez-le de manière sécurisée.

Vérifier que les clusters sont configurés et fonctionnent correctement

Pour vérifier l'état d'un cluster avant une mise à niveau, exécutez bmctl check cluster sur le cluster. 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.

Lorsque vous exécutez la commande bmctl upgrade cluster pour mettre à niveau vos clusters, certaines vérifications préliminaires sont exécutées. Le processus de mise à niveau s'arrête si ces vérifications ne aboutissent pas. Il est préférable d'identifier et de résoudre ces problèmes de manière proactive à l'aide de la commande bmctl check cluster, plutôt que de vous fier aux vérifications préliminaires qui protègent les clusters de tout dommage potentiel.

Examiner les déploiements de charges de travail utilisateur

Deux domaines sont à prendre en compte pour les charges de travail des utilisateurs: le drainage et la compatibilité des API.

Drainage de la charge de travail

La charge de travail de l'utilisateur sur un nœud est drainée lors d'une mise à niveau. Si la charge de travail comporte une seule instance répliquée ou si toutes les instances dupliquées se trouvent sur le même nœud, le drainage de la charge de travail peut entraîner une interruption des services exécutés dans le cluster. Exécutez vos charges de travail avec plusieurs instances répliquées. Le nombre d'instances répliquées doit être supérieur au nombre de nœuds simultanés.

Pour éviter une mise à niveau bloquée, le processus de drainage de mise à niveau vers la version 1.29 ne respecte pas les budgets d'interruption de pods (PDB). Les charges de travail peuvent s'exécuter dans un état dégradé, et l'instance répliquée la moins utile serait total replica number - concurrent upgrade number.

Compatibilité avec les API

Pour connaître la compatibilité de l'API, vérifiez la compatibilité de l'API de votre charge de travail avec la nouvelle version mineure de Kubernetes lorsque vous effectuez une mise à niveau de version mineure. Si nécessaire, mettez à niveau la charge de travail vers une version compatible. Dans la mesure du possible, l'équipe d'ingénieurs GKE Enterprise fournit des instructions pour identifier les charges de travail utilisant des API incompatibles, telles que les API Kubernetes supprimées.

Si vous utilisez Anthos Service Mesh, Config Sync, Policy Controller, Config Controller ou d'autres composants GKE Enterprise, vérifiez si la version installée est compatible avec la nouvelle version de Google Distributed Cloud. Pour en savoir plus sur la compatibilité des versions des composants GKE Enterprise, consultez la page Compatibilité des versions et des mises à niveau de GKE Enterprise.

Auditer l'utilisation des webhooks

Vérifiez si votre cluster comporte des webhooks, en particulier des ressources de pod à des fins d'audit telles que Policy Controller. Le processus de drainage lors de la mise à niveau du cluster peut perturber le service de webhook Policy Controller, ce qui peut bloquer la mise à niveau ou prendre beaucoup de temps. Nous vous recommandons de désactiver temporairement ces webhooks ou d'utiliser un déploiement à disponibilité élevée.

Examiner l'utilisation des fonctionnalités en preview

Les fonctionnalités en mode bêta sont susceptibles d'être modifiées et ne sont fournies qu'à des fins de test et d'évaluation. N'utilisez pas les fonctionnalités en preview sur vos clusters de production. Nous ne garantissons pas que les clusters qui utilisent des fonctionnalités en version preview peuvent être mis à niveau. Dans certains cas, nous bloquons explicitement les mises à niveau des clusters utilisant les fonctionnalités en mode bêta.

Pour en savoir plus sur les modifications majeures liées à la mise à niveau, consultez les notes de version.

Vérifier l'état de SELinux

Si vous souhaitez activer SELinux pour sécuriser vos conteneurs, vous devez vous assurer que SELinux est activé en mode Enforced sur toutes vos machines hôtes. À partir de la version 1.9.0 de Google Distributed Cloud ou version ultérieure, vous pouvez activer ou désactiver SELinux avant ou après la création ou la mise à niveau du cluster. SELinux est activé par défaut sur Red Hat Enterprise Linux (RHEL). Si SELinux est désactivé sur vos machines hôtes ou si vous n'êtes pas sûr, consultez la section Sécuriser vos conteneurs à l'aide de SELinux pour savoir comment l'activer.

Google Distributed Cloud n'est compatible avec SELinux que dans les systèmes RHEL.

Ne pas modifier la configuration de la densité des pods

Google Distributed Cloud accepte la configuration d'un maximum de 250 pods par nœud avec nodeConfig.PodDensity.MaxPodsPerNode. Vous ne pouvez configurer la densité des pods que lors de la création du cluster. Vous ne pouvez pas mettre à jour les paramètres de densité des pods pour les clusters existants. N'essayez pas de modifier la configuration de la densité des pods lors d'une mise à niveau.

Assurez-vous que les nœuds du plan de contrôle et de l'équilibreur de charge ne sont pas en mode maintenance

Assurez-vous que les nœuds du plan de contrôle et de l'équilibreur de charge ne sont pas en cours de maintenance avant de lancer une mise à niveau. Si un nœud est en mode maintenance, la mise à niveau s'interrompt pour garantir que les pools de nœuds du plan de contrôle et de l'équilibreur de charge sont suffisamment disponibles.

Étapes suivantes