Esse erro pode ocorrer em um cluster regional ou no plano de controle replicado
quando o kube-controller-manager (KCM) reinicia inesperadamente. Essa reinicialização pode
envolver o encerramento ou a reinicialização do kubelet. Os registros do KCM podem
incluir mensagens leaderelection lost.
Esse cenário pode ocorrer quando o líder verifica se ainda está liderando como
parte da verificação de integridade do KCM.
Se o líder não estiver mais liderando ou a ocorrer um erro na verificação de alocação, a verificação
informará falta de integridade e o líder será reiniciado.
O status de eleição do líder pode ser recuperado com os recursos Lease do
grupo coordination.k8s.io:
Para conferir todas as alocações, execute o seguinte comando kubectl:
kubectl-nkube-systemgetlease
Para verificar o status de uma alocação, como lease/kube-controller-manager,
use o seguinte comando kubectl describe:
Na seção Events, verifique se há eventos LeaderElection. Analise quem
assume a liderança e quando isso acontece. O exemplo de saída a seguir mostra
que, quando o primeiro nó é encerrado manualmente, o segundo assume
a liderança instantaneamente:
Também é possível observar o processo de perda e ganho de liderança usando a
métrica kubernetes.io/anthos/leader_election_master_status agrupada por name.
O processo de eleição do líder só acontece em caso de falha do líder atual. É possível
confirmar a falha analisando as métricas kubernetes.io/anthos/container/uptime e
kubernetes.io/anthos/container/restart_count filtradas por um
container_name de kube-controller-manager.
Se você tiver problemas ou falhas recorrentes no processo de eleição do líder,
analise as seguintes considerações de correção:
Se o KCM reiniciar a cada intervalo de alguns minutos ou menos, verifique se há solicitações com falha
do servidor de API nos registros do KCM. As solicitações com falha indicam problemas de conectividade entre
os componentes ou que parte do serviço está sobrecarregada.
Se o Controller Manager não se comunicar com o servidor de API por
muito tempo, ocorrerá uma falha na renovação e a instância do KCM perderá a liderança, mesmo que a
conexão seja restaurada depois.
Se o plano de controle for replicado, o novo líder deverá assumir o controle
sem inatividade. Nenhuma ação é necessária. O plano de controle de um cluster multicloud ou
regional é sempre replicado. Não tente desativar a eleição
do líder de um plano de controle replicado. Não é possível reativar a eleição do líder
sem inatividade.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-05-07 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).\n\nYou can also see\n[Getting support](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support) for more information about support resources, including the following:\n\n- [Requirements](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#support_requirements) for opening a support case.\n- [Tools](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#support_tools) to help you troubleshoot, such as logs and metrics.\n- Supported [components](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#whats_supported), [versions](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#version_support_policy), and [features](/kubernetes-engine/distributed-cloud/vmware/docs/getting-support#supported_features) of Google Distributed Cloud for VMware (software only)."]]