Risolvere i problemi relativi al controller manager di Kubernetes
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Questa pagina mostra come risolvere i problemi relativi al controller Kubernetes
manager (kube-controller-manager) per Google Distributed Cloud.
Elezione del dirigente persa
Questo errore potrebbe essere osservato in un cluster regionale o in un control plane replicato
quando kube-controller-manager (KCM) viene riavviato in modo imprevisto. Questo riavvio potrebbe
comportare la chiusura automatica o il riavvio da parte di kubelet. I log di KCM potrebbero
includere messaggi leaderelection lost.
Questo scenario può verificarsi quando il leader controlla se è ancora attivamente leader nell'ambito del controllo di integrità di KCM.
Se il leader non è più il leader o il controllo del lease non va a buon fine, il controllo di integrità
segnala che non è integro e il leader viene riavviato.
Lo stato dell'elezione del leader può essere recuperato ottenendo le risorse Lease del gruppo coordination.k8s.io:
Per visualizzare tutti i lease, esegui questo comando kubectl:
kubectl-nkube-systemgetlease
Per controllare lo stato di un determinato lease, ad esempio lease/kube-controller-manager,
utilizza il seguente comando kubectl describe:
Nella sezione Events, controlla la presenza di eventi LeaderElection. Controlla chi
assume la leadership e quando. L'output di esempio seguente mostra
che quando il primo nodo è stato arrestato manualmente, il secondo assume immediatamente
il ruolo di leader:
Puoi anche osservare il processo di perdita e acquisizione della leadership utilizzando la metrica kubernetes.io/anthos/leader_election_master_status raggruppata per name.
La procedura di elezione del leader viene eseguita solo se il leader attuale non riesce. Puoi
confermare l'errore esaminando le metriche kubernetes.io/anthos/container/uptime e
kubernetes.io/anthos/container/restart_count filtrate in base a un
container_name di kube-controller-manager.
Se riscontri problemi con il processo di elezione del leader che viene eseguito ripetutamente o
non va a buon fine, esamina le seguenti considerazioni per la risoluzione:
Se KCM viene riavviato ogni pochi minuti o meno, controlla i log di KCM per le richieste non riuscite al server API. Le richieste non riuscite indicano problemi di connettività tra
i componenti o che una parte del servizio è sovraccarica.
Se il gestore dei controller non riesce a comunicare con il server API per troppo
tempo, il rinnovo non riesce e l'istanza KCM perde la leadership, anche se la
connessione viene ripristinata in un secondo momento.
Se il control plane viene replicato, il nuovo leader deve subentrare senza problemi
senza tempi di inattività. Non è richiesta alcuna azione da parte tua. Il control plane di un cluster multicloud o
regionale viene sempre replicato. Non tentare di disattivare la selezione del leader per un piano di controllo replicato. Non puoi riattivare la selezione del leader
senza tempi di inattività.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
