Questa pagina mostra come risolvere i problemi relativi agli upgrade dei cluster Google Kubernetes Engine (GKE).
Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.kube-apiserver non integro dopo l'upgrade del piano di controllo
Il seguente problema si verifica quando avvii un upgrade manuale del piano di controllo della versione GKE del cluster. Alcuni webhook di ammissione di cui è stato eseguito il deployment dall'utente possono impedire ai componenti di sistema di creare ruoli RBAC permissivi necessari per funzionare correttamente. Durante l'upgrade del piano di controllo, Google Cloud ricrea il componente del server API Kubernetes (kube-apiserver). Se un webhook blocca il ruolo RBAC per il componente server API, il server API non viene avviato e l'upgrade del cluster non viene completato.
Il messaggio di errore nellgcloud CLI è simile al seguente:
FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.
Per identificare il webhook con errori, controlla gli audit log di GKE per le chiamate RBAC con le seguenti informazioni:
protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"
RBAC_RULE è il nome completo di un ruolo RBAC, come
rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.
Il nome del webhook con errori viene visualizzato nel log nel seguente formato:
admission webhook WEBHOOK_NAME denied the request
Per risolvere il problema, prova a procedere nel seguente modo:
- Modifica i vincoli per consentire la creazione e l'aggiornamento di ClusterRole con il prefisso
system:. - Modifica il webhook in modo che non intercetti le richieste per la creazione e l'aggiornamento dei ruoli RBAC di sistema.
- Disattiva il webhook.
Perché succede?
Kubernetes riconcilia automaticamente i ruoli RBAC di sistema predefiniti con i criteri predefiniti nell'ultima versione secondaria. A volte i criteri predefiniti per i ruoli di sistema cambiano nelle nuove versioni di Kubernetes.
Per eseguire questa riconciliazione, GKE crea o aggiorna gli oggetti ClusterRole e ClusterRoleBinding nel cluster. Se hai un webhook che intercetta e rifiuta le richieste di creazione o aggiornamento a causa dell'ambito delle autorizzazioni utilizzate dai criteri RBAC predefiniti, il server API non può funzionare nella nuova versione secondaria.
Carichi di lavoro rimossi dopo l'upgrade del cluster Standard
I carichi di lavoro potrebbero essere a rischio di rimozione dopo un upgrade del cluster se si verificano tutte le seguenti condizioni:
- I carichi di lavoro del sistema richiedono più spazio quando il piano di controllo del cluster esegue la nuova versione GKE.
- I nodi esistenti non dispongono di risorse sufficienti per eseguire i nuovi carichi di lavoro di sistema e i carichi di lavoro esistenti.
- Il gestore della scalabilità automatica dei cluster è disabilitato per il cluster.
Per risolvere il problema, prova a procedere nel seguente modo:
- Abilita la scalabilità automatica per i pool di nodi esistenti
- Abilita il provisioning automatico dei nodi
- Crea un nuovo pool di nodi
- Fai lo scale up di un pool di nodi esistente