Versione 1.15. Questa versione non è più supportata. Per informazioni su come eseguire l'upgrade alla versione 1.16, vedi Eseguire l'upgrade dei cluster nella documentazione più recente. Per ulteriori informazioni sulle versioni supportate e non supportate, consulta la pagina Cronologia delle versioni nella documentazione più recente.

Risolvere i problemi relativi al gestore dei controller Kubernetes

Questa pagina mostra come risolvere i problemi relativi a Kubernetes Controller Manager (kube-controller-manager) per Google Distributed Cloud Virtual for Bare Metal.

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

Elezioni del leader perse

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 inaspettatamente. 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 in testa attivamente nell'ambito del controllo di integrità KCM.

Se la variante principale non è più in testa o il controllo del lease non riesce, il controllo di integrità risulta non integro e la variante principale viene riavviata.

Lo stato delle elezioni leader può essere recuperato ottenendo le risorse Lease del gruppo coordination.k8s.io:

Per visualizzare tutti i lease, esegui il comando kubectl seguente:
```
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, verifica se sono presenti eventi LeaderElection. Esaminate chi assume la dirigenza e quando succede. Il seguente output di esempio mostra che, quando il primo nodo è stato arrestato manualmente, il secondo assume immediatamente la leadership:

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 per perdere e acquisire leadership utilizzando la metrica kubernetes.io/anthos/leader_election_master_status raggruppata per name.

Il processo di elezione del leader avviene solo se il leader attuale fallisce. Puoi confermare l'errore esaminando le metriche kubernetes.io/anthos/container/uptime e kubernetes.io/anthos/container/restart_count filtrate per container_name di kube-controller-manager.

Se si verificano problemi relativi al processo elettorale dei leader che sono ripetutamente in corso o non vengono superati, esamina le seguenti considerazioni di rimedio:

Se KCM si riavvia a intervalli di pochi minuti o meno, controlla se nei log di KCM sono presenti richieste non riuscite al server API. Le richieste non riuscite indicano che i problemi di connettività tra i componenti o parte del servizio sono sovraccaricati.
Se il gestore del 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 piano di controllo viene replicato, la nuova leader dovrebbe intervenire senza tempi di inattività. Non è richiesto alcun intervento da parte tua. Il piano di controllo di un cluster multi-cloud o a livello di regione è sempre replicato. Non tentare di disabilitare le elezioni di leader per un piano di controllo replicato. Non puoi riattivare le elezioni del leader senza tempi di inattività.

Passaggi successivi

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