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

Nous vous recommandons de suivre toutes les bonnes pratiques décrites dans ce document. Suivez la checklist suivante pour suivre vos progrès. Chaque élément de la liste renvoie à une section de ce document pour en savoir plus:

Une fois ces vérifications effectuées, vous pouvez commencer 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 perturbatrices. Avant de commencer la mise à niveau, planifiez soigneusement pour vous assurer que votre environnement et vos applications sont prêts.

Estimer le temps nécessaire et planifier un intervalle de maintenance

Le temps nécessaire pour mettre à niveau un cluster varie en fonction du nombre de nœuds et de la densité de la charge de travail qui s'exécute dessus. Pour réussir une mise à niveau de cluster, utilisez un intervalle de maintenance suffisamment long.

Pour calculer une estimation approximative de la mise à niveau, utilisez 10 minutes * the number of nodes pour une mise à niveau de nœud unique simultanée.

Par exemple, si vous disposez de cinquante nœuds dans un cluster, la durée totale de la mise à niveau est d'environ cinq cents minutes: 10 minutes * 50 nodes = 500 minutes.

Vérifier la compatibilité des autres composants GKE Enterprise

Si votre cluster exécute des composants GKE Enterprise tels que Cloud Service Mesh, Config Sync, Policy Controller ou Config Controller, consultez la version de GKE Enterprise et la compatibilité des mises à niveau, puis 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 administrateur ou utilisateur dans lequel Cloud 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 est drainé et qu'il y a suffisamment de ressources dans le cluster en cours de mise à niveau 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 indiquer 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 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.

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

Tous les contrôleurs et jobs de mise à niveau s'exécutent dans les nœuds du plan de contrôle du cluster d'administrateur. Vérifiez la consommation de ressources de ces nœuds de 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 Go de RAM pour chaque ensemble de contrôleurs de cycle de vie. Notez que l'unité de processeur "mCPU" signifie "millième de cœur". Par conséquent, 1 000 millicœurs équivaut à 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 pour les clusters d'utilisateurs.

Dans l'exemple de déploiement suivant, les deux clusters d'utilisateur sont de versions différentes de celle 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'administrateur 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 un total de 1 000 mCPU et 3 Gio de RAM. La consommation de ressources totale actuelle de ces contrôleurs de cycle de vie est de 3 000 mCPU et de 9 GiB 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 un total de 2 000 mCPU et 6 GiB de RAM.

Si le cluster utilisateur 1 est mis à niveau vers 1.13.3, le parc s'exécute désormais avec 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 GiB de RAM.

Dans l'exemple suivant, tous les clusters d'utilisateur sont de 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. La consommation de ressources de calcul est donc réduite :

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 et 6 GiB 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, vous pouvez voir des pods tels que anthos-cluster-operator, capi-controller-manager, cap-controller-manager ou cap-kubeadm-bootstraper dans un état Pending. Pour résoudre ce problème, mettez à niveau certains des clusters d'utilisateur vers la même version afin de consolider les versions et de réduire le nombre de contrôleurs de cycle de vie utilisés. Si votre 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 requêtes de processeur et de RAM afin qu'elles s'adaptent au plan de contrôle du cluster d'administrateur.

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

Cluster Ressources du cluster d'administrateur requises
Migration des clusters d'utilisateur Passer à la même version que les autres clusters : non applicable

Passer à une autre version que les autres clusters d'administrateur ou d'utilisateur : 1 000 mCPU et 3 GiB de RAM

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

Sauvegarder des clusters

Avant de commencer une migration, sauvegardez les clusters à l'aide de la commande bmctl backup cluster.

Comme 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 qui ont des pods bloqués.

Lorsque vous exécutez la commande bmctl upgrade cluster pour mettre à niveau vos clusters, certaines vérifications préliminaires s'exécutent. Le processus de mise à niveau s'arrête si ces vérifications échouent. 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 s'appuyer sur les vérifications préalables qui sont là pour protéger les clusters de tout dommage possible.

Examiner les déploiements de charges de travail utilisateur

Il existe deux aspects à prendre en compte pour les charges de travail utilisateur: le vidage 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 répliquées se trouvent sur le même nœud, l'épuisement de la charge de travail peut perturber les 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 que la mise à niveau ne se bloque, le processus de vidage de la mise à niveau vers la version 1.31 ne respecte pas les budgets d'interruption de pod (PDB). Les charges de travail peuvent s'exécuter dans un état dégradé, et l'instance répliquée la moins performante est total replica number - concurrent upgrade number.

Compatibilité avec les API

Pour la compatibilité des API, vérifiez la compatibilité de l'API de votre charge de travail avec une version mineure plus récente de Kubernetes lors d'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 qui utilisent des API incompatibles, telles que les API Kubernetes supprimées.

Si vous utilisez Cloud 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 de GKE Enterprise, consultez la section Assistance pour les versions et les mises à niveau de GKE Enterprise.

Auditer l'utilisation des webhooks

Vérifiez si votre cluster contient des webhooks, en particulier des ressources de pod à des fins d'audit, comme Policy Controller. Le processus de drainage lors de la mise à niveau du cluster peut perturber le service de webhook du contrôleur de règles, ce qui peut entraîner un blocage de la mise à niveau ou une longue durée de la mise à niveau. Nous vous recommandons de désactiver temporairement ces webhooks ou d'utiliser un déploiement à haute disponibilité (HA).

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 mode preview sur vos clusters de production. Nous ne garantissons pas que les clusters utilisant les fonctionnalités en mode preview puissent ê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, vous pouvez activer ou désactiver SELinux avant ou après la création des clusters, ou leurs mises à niveau. 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 densité des pods

Google Distributed Cloud permet de configurer jusqu'à 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 maintenance avant de commencer une mise à niveau. Si un nœud est en mode maintenance, la mise à niveau est mise en pause pour s'assurer que les pools de nœuds du plan de contrôle et de l'équilibreur de charge sont suffisamment disponibles.

Étape suivante