Cette page a été traduite par l'API Cloud Translation.

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 leader perdu

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 une fermeture automatique ou un redémarrage par kubelet. Les journaux KCM peuvent inclure des messages leaderelection lost.

Ce scénario peut se produire lorsque la variante optimale vérifie si elle continue activement d'être dirigée activement dans le cadre de la vérification de l'état de l'état KCM.

Si la variante optimale n'est plus en tête ou si la vérification du bail échoue, la vérification de l'état'état signale qu'elle n'est plus opérationnelle et la variante optimale est redémarrée.

Le statut 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'une location donnée, telle 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 direction et quand cela se produit. L'exemple de résultat suivant montre que lorsque le premier nœud a été arrêté manuellement, le second prend instantanément la direction:
```
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 de prise de position de leader à l'aide de la métrique kubernetes.io/anthos/leader_election_master_status regroupée par name.

Le processus d'élection du responsable n'a lieu 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 lors de l'élection du responsable, qui se déroulent à plusieurs reprises ou échouent, consultez les considérations de résolution suivantes:

Si KCM redémarre toutes les deux ou trois minutes ou moins, vérifiez les journaux KCM pour identifier les requêtes ayant échoué auprès du serveur d'API. Les requêtes ayant échoué indiquent des problèmes de connectivité entre les composants ou une partie du service 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 sa position de leader, même si la connexion est ensuite restaurée.
Si le plan de contrôle est répliqué, le nouveau responsable doit prendre le relais en douceur, sans temps d'arrêt. 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 dirigeant sans un temps d'arrêt.

Étapes suivantes

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