Résoudre les problèmes liés au gestionnaire de contrôleurs Kubernetes
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment résoudre les problèmes liés au gestionnaire de contrôleurs Kubernetes (kube-controller-manager) pour Google Distributed Cloud.
É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-nkube-systemgetlease
Pour vérifier l'état d'un bail donné, tel que lease/kube-controller-manager, utilisez la commande kubectl describe suivante :
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 :
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.
Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris les suivantes :
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["This pages shows you how to resolve issues with the Kubernetes controller\nmanager (`kube-controller-manager`) for Google Distributed Cloud.\n\nLeader election lost\n\nThis error might be observed in a regional cluster or replicated control plane\nwhen `kube-controller-manager` (KCM) restarts unexpectedly. This restart might\ninvolve quitting itself or being restarted by `kubelet`. The KCM logs might\ninclude `leaderelection lost` messages.\n\nThis scenario can occur when the leader checks if it's still actively leading as\npart of the KCM health check.\n\nIf the leader is no longer leading or the lease check fails, the health check\nreports to be unhealthy, and the leader is restarted.\n\nThe leader election status can be retrieved by getting the `Lease` resources of\nthe `coordination.k8s.io` group:\n\n1. To see all leases, run the following `kubectl` command:\n\n kubectl -n kube-system get lease\n\n2. To check status of a given lease, such as `lease/kube-controller-manager`,\n use the following `kubectl describe` command:\n\n kubectl -n kube-system describe lease/kube-controller-manager\n\n Under the `Events` section, check for `LeaderElection` events. Review who\n takes the leadership and when that happens. The following example output shows\n that when the first node was manually shut down, the second instantaneously\n takes over the leadership: \n\n Events:\n Type Reason Age From Message\n ---- ------ ---- ---- -------\n Normal LeaderElection 26m kube-controller-manager control-plane_056a86ec-84c5-48b8-b58d-86f3fde2ecdd became leader\n Normal LeaderElection 5m20s kube-controller-manager control-plane2_b0475d49-7010-4f03-8a9d-34f82ed60cd4 became leader\n\n You can also observe the process of losing and gaining leadership by using the\n `kubernetes.io/anthos/leader_election_master_status` metric grouped by `name`.\n\nThe leader election process only happens if the current leader fails. You can\nconfirm the failure by looking at `kubernetes.io/anthos/container/uptime` and\n`kubernetes.io/anthos/container/restart_count` metrics filtered by a\n`container_name` of `kube-controller-manager`.\n\nIf you experience issues of the leader election process repeatedly running or\nfailing, review the following remediation considerations:\n\n- If KCM restarts every few minutes or less, check the KCM logs for failed requests to API server. Failed requests indicate connectivity issues between the components or part of the service is overloaded.\n- If the controller manager fails to communicate with the API server for too long, the renewal fails and the KCM instance loses its leadership, even if the connection is later restored.\n- If the control plane is replicated, the new leader should smoothly take over without downtime. No action is required. The control plane of a multi-cloud or regional cluster is always replicated. Don't attempt to disable leader election for a replicated control plane. You can't re-enable leader election without downtime.\n\nWhat's next\n\nIf you need additional assistance, reach out to\n\n[Cloud Customer Care](/support-hub).\nYou can also see\n[Getting support](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support) for more information about support resources, including the following:\n\n- [Requirements](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#intro-support) for opening a support case.\n- [Tools](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#support-tools) to help you troubleshoot, such as your environment configuration, logs, and metrics.\n- Supported [components](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#what-we-support)."]]
