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'une aide supplémentaire, contactez Cloud Customer Care.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 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.
É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 :
- Activer l'autoscaling pour un pool de nœuds existant
- Activer le provisionnement automatique des nœuds
- Créer un pool de nœuds
- Effectuer le scaling à la hausse d'un pool de nœuds existant