Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Risolvi i problemi del gestore del controller Kubernetes

Queste pagine mostrano come risolvere i problemi relativi al controller manager (kube-controller-manager) di Kubernetes per Google Distributed Cloud.

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.

Elezione del leader persa

Questo errore potrebbe essere osservato in un cluster a livello di regione o in un piano di controllo replicato quando kube-controller-manager (KCM) si riavvia in modo imprevisto. Questo riavvio potrebbe potrebbe comportare l'uscita da sé o il riavvio da parte di kubelet. I log KCM potrebbero includi messaggi leaderelection lost.

Questo scenario può verificarsi quando il leader controlla se è ancora in testa con del controllo di integrità KCM.

Se il leader non è più in primo piano o se il controllo del lease non va a buon fine, il controllo di integrità segnala che il sistema non è integro e il leader viene riavviato.

Lo stato di elezione dei leader può essere recuperato recuperando le Lease risorse di il gruppo coordination.k8s.io:

Per visualizzare tutti i lease, esegui questo comando kubectl:
```
kubectl -n kube-system get lease
```

Per controllare lo stato di un determinato lease, ad esempio lease/kube-controller-manager, utilizza il seguente comando kubectl describe:

kubectl -n kube-system describe lease/kube-controller-manager

Nella sezione Events, controlla la presenza di eventi LeaderElection. Rivedi chi e quando ciò accade. L'output di esempio seguente mostra che quando il primo nodo è stato arrestato manualmente, il secondo istantaneamente prende il comando:

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

Puoi anche osservare il processo di perdita e acquisizione della leadership utilizzando la metrica kubernetes.io/anthos/leader_election_master_status raggruppata per name.

Il processo di elezione del leader si verifica solo se il leader attuale non riesce. Puoi conferma l'errore esaminando kubernetes.io/anthos/container/uptime e kubernetes.io/anthos/container/restart_count metriche filtrate in base a container_name di kube-controller-manager.

Se riscontri problemi relativi al processo elettorale dei leader ripetutamente in corso o se non funziona, esamina le seguenti considerazioni sulla correzione:

Se KCM si riavvia a intervalli di pochi minuti o meno, controlla i log KCM per eventuali errori richieste al server API. Le richieste non riuscite indicano problemi di connettività tra che i componenti o parte del servizio siano sovraccarichi.
Se anche il gestore del controller non riesce a comunicare con il server API lungo, il rinnovo non va a buon fine e l'istanza KCM perde la propria leadership, anche se e la connessione a internet viene ripristinata in un secondo momento.
Se il piano di controllo viene replicato, il nuovo leader dovrebbe prendere il controllo senza problemi senza tempi di inattività. Non è richiesta alcuna azione da parte tua. Il piano di controllo di un cluster multi-cloud o regionale viene sempre replicato. Non tentare di disattivare la variante leader per un piano di controllo replicato. Non puoi riattivare l'elezione del leader senza tempi di riposo.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.