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

Les bonnes pratiques de mise à niveau structurée pour Google Distributed Cloud vous permettent de minimiser les interruptions de service et de réduire les risques opérationnels. La validation préalable à la mise à niveau permet de s'assurer que vos clusters et vos charges de travail restent stables tout au long de chaque transition de version.

Pour les environnements couvrant les niveaux de test, de développement et de production, effectuez vos mises à niveau de manière séquentielle en commençant par le niveau le moins critique. Vérifier l'état du cluster et le comportement de la charge de travail à chaque étape vous aide à identifier les problèmes potentiels avant de mettre à jour les systèmes de production.

Checklist pour la mise à niveau

Nous vous recommandons de suivre toutes les bonnes pratiques décrites dans ce document. Utilisez la checklist suivante pour suivre votre progression. Chaque élément de la liste renvoie à une section de ce document contenant plus d'informations :

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 perturbantes. Avant de commencer la mise à niveau, planifiez-la 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 à la mise à niveau d'un cluster varie en fonction du nombre de nœuds et de la densité de la charge de travail qui s'exécute sur ceux-ci. Pour réussir la mise à niveau d'un cluster, utilisez un intervalle de maintenance d'une durée suffisante.

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

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

Vérifier la compatibilité d'autres produits Google Cloud

Si votre cluster exécute Cloud Service Mesh, Config Sync ou Policy Controller, consultez la section Compatibilité des versions et des mises à niveau 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 administrateur ou utilisateur dans lequel Cloud Service Mesh, Config Sync ou Policy 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 vous aider à déterminer le moment où une mise à niveau entraînerait 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 moment choisi pour la mise à niveau du cluster d'administrateur peut être moins critique que pour les clusters d'utilisateur, car la mise à niveau d'un 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 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" correspond à un "millième de cœur". Par conséquent, 1 000 millicœurs équivalent à 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 les clusters d'utilisateur sur la même version.

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 totale actuelle de 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 2 000 mCPU et 6 Gio 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'existe désormais qu'un seul ensemble de contrôleurs de cycle de vie, qui consomment un total de 1 000 mCPU et 3 Gio 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 pendant 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 besoins 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 Gio de RAM. Les ressources sont renvoyées après utilisation.
Autonome Pic de 200 mCPU et 1 Gio de RAM. Les ressources sont renvoyées après utilisation.

Sauvegarder des clusters

Avant de commencer une mise à niveau, 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 comportent des pods 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 é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éliminaires qui sont là pour protéger les clusters de tout dommage possible.

Examiner les déploiements de charges de travail utilisateur

Deux aspects sont à prendre en compte pour les charges de travail utilisateur : 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 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 un blocage de la mise à niveau, le processus de drainage de la mise à niveau vers la version 1.36 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 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 la version mineure plus récente 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énierie GKE fournit des instructions pour identifier les charges de travail utilisant des API incompatibles, telles que les API Kubernetes supprimées.

Si vous utilisez Cloud Service Mesh, Config Sync ou Policy Controller, 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, consultez Compatibilité des versions et des mises à niveau.

Auditer l'utilisation des webhooks

Vérifiez si votre cluster comporte 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 disponibilité élevée (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 preview sur vos clusters de production. Nous ne garantissons pas que les clusters utilisant les fonctionnalités en preview puissent être mis à niveau. Dans certains cas, nous bloquons explicitement les mises à niveau des clusters utilisant les fonctionnalités en preview.

Pour en savoir plus sur les modifications destructives 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 la 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 cours de maintenance avant de lancer une mise à niveau. Si un nœud est en mode maintenance, la mise à niveau est suspendue 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