Résoudre les problèmes liés aux mises à niveau

Cette page explique comment résoudre les problèmes liés aux mises à niveau des clusters Google Kubernetes Engine (GKE).

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Problème : kube-apiserver non opérationnel après la mise à niveau du plan de contrôle

Le problème suivant se produit lorsque vous démarrez une mise à niveau manuelle du plan de contrôle de votre version de cluster GKE. Certains webhooks d'admission déployés par l'utilisateur peuvent empêcher les composants système de créer des rôles RBAC permissifs qui sont requis pour un fonctionnement correct. Lors d'une mise à niveau du plan de contrôle, Google Cloud recrée le composant de serveur d'API Kubernetes (kube-apiserver). Si un webhook bloque le rôle RBAC pour le composant de serveur d'API, le serveur d'API ne démarre pas et la mise à niveau du cluster ne se termine pas.

Le message d'erreur dans gcloud CLI ressemble à ceci :

FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.

Pour identifier le webhook défaillant, consultez vos journaux d'audit GKE pour les appels RBAC avec les informations suivantes :

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

RBAC_RULE est le nom complet d'un rôle RBAC, tel que rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

Le nom du webhook défaillant est affiché dans le journal au format suivant :

admission webhook WEBHOOK_NAME denied the request

Pour résoudre ce problème, procédez comme suit :

  • Ajustez vos contraintes pour autoriser la création et la mise à jour de ClusterRoles comportant le préfixe system:.
  • Ajustez le webhook pour ne pas intercepter les requêtes de création et de mise à jour des rôles RBAC système.
  • Désactivez le webhook.

Pourquoi cela se produit-il ?

Kubernetes rapproche automatiquement{track-name="k8sLink" track-type="troubleshooting"} les rôles RBAC système par défaut avec les stratégies par défaut de la dernière version mineure. Les stratégies par défaut des rôles système changent parfois dans les nouvelles versions de Kubernetes.

Pour effectuer ce rapprochement, GKE crée ou met à jour les ClusterRoles et les ClusterRoleBindings dans le cluster. Si vous disposez d'un webhook qui intercepte et refuse les requêtes de création ou de mise à jour en raison du champ d'application des autorisations utilisées par les stratégies RBAC par défaut, le serveur d'API ne peut pas fonctionner sur la nouvelle version mineure.

Problème : éviction des charges de travail après la mise à niveau d'un cluster Standard

Vos charges de travail peuvent être exposées à une éviction après la mise à niveau d'un cluster si toutes les conditions suivantes sont remplies :

  • Les charges de travail système nécessitent davantage d'espace lorsque le plan de contrôle du cluster exécute la nouvelle version de GKE.
  • Vos nœuds existants ne disposent pas de suffisamment de ressources pour exécuter les nouvelles charges de travail système et vos charges de travail existantes.
  • L'autoscaler de cluster est désactivé pour le cluster.

Essayez les solutions suivantes pour résoudre ce problème :

Problème : la version du nœud n'est pas compatible avec la version du plan de contrôle

Vérifiez la version de Kubernetes exécutée par le plan de contrôle de votre cluster, puis vérifiez la version de Kubernetes exécutée par les pools de nœuds de votre cluster. Si l'un des pools de nœuds du cluster a plus de deux versions mineures antérieures au plan de contrôle, cela peut engendrer des problèmes avec votre cluster.

L'équipe GKE effectue régulièrement des mises à niveau du plan de contrôle du cluster en votre nom. Les plans de contrôle sont mis à niveau vers les versions stables les plus récentes de Kubernetes. Par défaut, la mise à niveau automatique est activée sur les nœuds d'un cluster. Nous vous recommandons de ne pas la désactiver.

Si la mise à niveau automatique est désactivée pour les nœuds d'un cluster et que vous ne mettez pas à niveau manuellement la version du pool de nœuds vers une version compatible avec le plan de contrôle, votre plan de contrôle finira par être incompatible avec vos nœuds, car le plan de contrôle est automatiquement mis à niveau au fil du temps. Une incompatibilité entre le plan de contrôle de votre cluster et les nœuds peut provoquer des problèmes inattendus.

Les règles de compatibilité de la version de Kubernetes et du décalage de version stipulent que les plans de contrôle sont compatibles avec les nœuds jusqu'à deux versions mineures antérieures à celle du plan de contrôle. Par exemple, les plans de contrôle Kubernetes 1.19 sont compatibles avec les nœuds Kubernetes 1.19, 1.18 et 1.17. Pour résoudre ce problème, mettez à niveau manuellement la version du pool de nœuds vers une version compatible avec le plan de contrôle.

Si vous craignez que le processus de mise à niveau entraîne des perturbations pour les charges de travail s'exécutant sur les nœuds concernés, procédez comme suit pour migrer vos charges de travail vers un nouveau pool de nœuds :

  1. Créez un pool de nœuds avec une version compatible.
  2. Marquez les nœuds du pool existant comme non programmables.
  3. Facultatif : Mettez à jour vos charges de travail exécutées sur le pool de nœuds existant pour ajouter un sélecteur de nœuds pour le libellé cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME, où NEW_NODE_POOL_NAME est le nom du nouveau pool de nœuds. Cela garantit que GKE place ces charges de travail sur les nœuds du nouveau pool de nœuds.
  4. Drainez le pool de nœuds existant.
  5. Vérifiez que les charges de travail s'exécutent correctement dans le nouveau pool de nœuds. Si tel est le cas, vous pouvez supprimer l'ancien pool de nœuds. Si vous remarquez des interruptions de charge de travail, reprogrammez les charges de travail sur les nœuds existants en marquant les nœuds du pool de nœuds existant comme non programmables et en drainant les nouveaux nœuds. Résolvez le problème et réessayez.

Problème : pods bloqués à l'état "en attente" après la configuration des ressources pouvant être allouées aux nœuds

Après avoir configuré les ressources pouvant être allouées aux nœuds et effectué une mise à niveau de la version du nœud, vous remarquerez peut-être que des pods en cours d'exécution sont passés à l'état "en attente".

Si les pods sont en attente après une mise à niveau, nous vous suggérons de suivre les conseils suivants :

  • Assurez-vous que les demandes de ressources de mémoire et de processeur pour vos pods ne dépassent pas leur pic d'utilisation. Étant donné que GKE réserve le processeur et la mémoire pour les frais généraux, les pods ne peuvent pas demander ces ressources. Les pods qui demandent plus de ressources mémoire et de processeur qu'ils n'en utilisent empêchent les autres pods de demander ces ressources et peuvent laisser le cluster sous-exploité. Pour en savoir plus, consultez la section Programmation des pods avec des demandes de ressources.

  • Envisagez de redimensionner votre cluster. Pour obtenir des instructions, consultez la page Redimensionner un cluster.

  • Pour annuler cette modification, faites revenir votre cluster à une version antérieure. Pour obtenir des instructions, consultez la page Mettre à jour manuellement un cluster ou un pool de nœuds.

Étape suivante

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.