Ce document décrit les bonnes pratiques et les considérations à prendre en compte pour mettre à niveau GKE sur une solution Bare Metal. Vous apprendrez à vous préparer aux mises à niveau des clusters et découvrirez 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 (test, développement et production, par exemple), 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 à 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. La checklist suivante vous aidera à suivre vos progrès. 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 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 votre stratégie pour vous assurer que votre environnement et vos applications sont prêts et préparés.
Estimer le temps consacré 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é des charges de travail qui y sont exécutées. Pour mener à bien une mise à niveau du 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 la 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 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 qu'Anthos Service Mesh, Config Sync, Policy Controller ou Config Controller, consultez la matrice de compatibilité GKE Enterprise et vérifiez les versions compatibles avec GKE sur Bare Metal 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 lors du drainage du nœud et que le cluster en cours de mise à niveau dispose de 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 l'observabilité Google Cloud.
Vous pouvez utiliser des commandes telles que kubectl top nodes pour connaître l'utilisation actuelle des ressources de 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 à indiquer à quel moment une mise à niveau causerait 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 timing de la mise à niveau du cluster d'administrateur peut être moins important 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 entraîner un risque et peut donc être recommandée 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 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 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 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". 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 ont des versions différentes de celles 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 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'existe 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 ont 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 réduit la consommation des 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 un total de 2 000 mCPU 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 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 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 requises pour le cluster d'administrateur |
|---|---|
| Mise à niveau du cluster d'utilisateur | Effectuez la mise à niveau vers la même version des autres clusters: N/A Effectuez une mise à niveau vers une version différente des 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 d'un cluster hybride (sans cluster d'utilisateur) | surutilisation de 1 000 mCPU et de 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 commencer 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 en toute sécurité.
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. Si ces vérifications échouent, le processus de mise à niveau s'arrête. Il est préférable d'identifier et de résoudre ces problèmes de manière proactive avec la commande bmctl check cluster, plutôt que de vous appuyer sur les vérifications préliminaires qui sont là pour protéger les clusters de tout dommage potentiel.
Examiner les déploiements de charges de travail des utilisateurs
Deux aspects 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 répliquées se trouvent sur le même nœud, le drainage 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 vers la version 1.16 ne respecte pas les budgets d'interruption de pods (PDB). Les charges de travail peuvent s'exécuter en état dégradé. L'instance répliquée la moins active serait total
replica number - concurrent upgrade number.
Compatibilité avec les API
Pour les API compatibles, vérifiez la compatibilité de votre API de 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 à l'aide d'API incompatibles, telles que les API Kubernetes supprimées.
Si vous utilisez Anthos Service Mesh, Config Sync, Policy Controller et Config Controller, ou d'autres composants GKE Enterprise, vérifiez si la version installée est compatible avec la nouvelle version de GKE sur Bare Metal. Pour obtenir des informations 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 entraîner le blocage de 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 version preview 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 les fonctionnalités en version preview pourront être mis à niveau. Dans certains cas, nous bloquons explicitement les mises à niveau pour les clusters qui utilisent les fonctionnalités en version preview.
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 GKE sur Bare Metal, 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) et CentOS. 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.
GKE sur Bare Metal n'est compatible qu'avec SELinux sur les systèmes RHEL et CentOS.
Ne pas modifier la configuration de densité de pods
GKE sur Bare Metal 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é de 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 de 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 de maintenance, la mise à niveau est suspendue pour garantir que les pools de nœuds du plan de contrôle et de l'équilibreur de charge sont suffisamment disponibles.
Étapes suivantes
- Mettre à niveau des clusters
- En savoir plus sur le cycle de vie et les étapes des mises à niveau
- Résoudre les problèmes liés à la mise à niveau du cluster