Ce document décrit les bonnes pratiques et les points à prendre en compte pour mettre à niveau Google Distributed Cloud. Vous apprendrez à préparer les mises à niveau des clusters et 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 test, development 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 mettiez à niveau 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
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 effectuées, vous pouvez démarrer 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 disruptives. 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 sur ceux-ci. Pour effectuer 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 d'un seul nœud simultané.
Par exemple, si vous avez 50 nœuds dans un cluster, le temps total de mise à niveau sera
d'environ 500 minutes : 10 minutes * 50 nodes = 500 minutes.
Vérifier la compatibilité des autres Google Cloud produits
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 de la 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. 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 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 "millième de cœur". Ainsi, 1 000 millicores é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 dans 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 un total de 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 plus 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 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 termes de 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 | 200 mCPU et 1 Gio de RAM. Les ressources sont renvoyées après utilisation. |
Sauvegarder les 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 correctement configurés 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 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éliminaires qui sont là pour protéger les clusters contre tout dommage éventuel.
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é avec les 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 une mise à niveau bloquée, le processus de drainage de la mise à niveau jusqu'à la version 1.36 ne respecte pas les budgets d'interruption de pods. 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é avec les 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 à l'aide d'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 la section 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.
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 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 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
- Mettre à niveau Google Distributed Cloud
- En savoir plus sur le cycle de vie et les étapes des mises à niveau
- Résoudre les problèmes de mise à niveau des clusters