Les clusters Anthos sur Bare Metal sont désormais Google Distributed Cloud (logiciel uniquement) pour Bare Metal. Pour en savoir plus, consultez la présentation du produit.

Résoudre les problèmes liés au gestionnaire de contrôleurs Kubernetes

Cette page explique comment résoudre les problèmes liés au gestionnaire de contrôleurs Kubernetes (kube-controller-manager) pour Google Distributed Cloud.

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

Élection du responsable perdue

Cette erreur peut se produire dans un cluster régional ou un plan de contrôle répliqué lorsque kube-controller-manager (KCM) redémarre de manière inattendue. Ce redémarrage peut impliquer son arrêt de lui-même ou son redémarrage par kubelet. Les journaux KCM peuvent inclure des messages leaderelection lost.

Ce scénario peut se produire lorsque le responsable vérifie s'il est toujours le responsable actif lors de la vérification de l'état KCM.

Si ce responsable n'est plus le responsable en cours ou si la vérification du bail (lease) échoue, la vérification d'état indique qu'il n'est pas opérationnel, et le responsable est redémarré.

L'état d'élection du responsable peut être récupéré en obtenant les ressources Lease du groupe coordination.k8s.io :

Pour afficher tous les baux, exécutez la commande kubectl suivante :
```
kubectl -n kube-system get lease
```
Pour vérifier l'état d'un bail donné, tel que lease/kube-controller-manager, utilisez la commande kubectl describe suivante :
```
kubectl -n kube-system describe lease/kube-controller-manager
```
Dans la section Events, recherchez les événements LeaderElection. Vérifiez qui prend la place de responsable et quand. L'exemple de sortie suivant montre que lorsque le premier nœud a été arrêté manuellement, le second a immédiatement pris la relève en tant que responsable :
```
Events:
  Type    Reason          Age    From                     Message
  ----    ------          ----   ----                     -------
  Normal  LeaderElection  26m    kube-controller-manager  control-plane_056a86ec-84c5-48b8-b58d-86f3fde2ecdd became leader
  Normal  LeaderElection  5m20s  kube-controller-manager  control-plane2_b0475d49-7010-4f03-8a9d-34f82ed60cd4 became leader
```
Vous pouvez également observer le processus de perte et d'acquisition de la position de responsable à l'aide de la métrique kubernetes.io/anthos/leader_election_master_status, regroupée par name.

Le processus d'élection du responsable ne se produit que si le responsable actuel échoue. Vous pouvez confirmer l'échec en examinant les métriques kubernetes.io/anthos/container/uptime et kubernetes.io/anthos/container/restart_count, filtrées par un container_name de kube-controller-manager.

Si vous rencontrez des problèmes liés au processus d'élection du responsable, qui s'exécute ou échoue de manière répétée, consultez les points à prendre en compte pour résoudre les problèmes suivants:

Si KCM redémarre toutes les quelques minutes ou moins, vérifiez les journaux KCM pour voir si des requêtes envoyées au serveur d'API ont échoué. Les requêtes ayant échoué indiquent des problèmes de connectivité entre les composants ou qu'une partie du service est surchargée.
Si le gestionnaire de contrôleurs ne parvient pas à communiquer avec le serveur d'API pendant trop longtemps, le renouvellement échoue et l'instance KCM perd son rôle de responsable, même si la connexion est rétablie ultérieurement.
Si le plan de contrôle est répliqué, le nouveau responsable devrait prendre le relais sans interruption. Aucune action n'est requise. Le plan de contrôle d'un cluster multicloud ou régional est toujours répliqué. N'essayez pas de désactiver l'élection du responsable pour un plan de contrôle répliqué. Vous ne pouvez pas réactiver l'élection du responsable sans temps d'arrêt.

Étape suivante

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