Risolvere i problemi relativi agli upgrade

Questa pagina mostra come risolvere i problemi relativi agli upgrade dei cluster di Google Kubernetes Engine (GKE).

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

Problema: kube-apiserver non è in stato di integrità 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 tuo 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 il funzionamento corretto. Durante un upgrade del piano di controllo, Google Cloud viene ricreato il componente del server API Kubernetes (kube-apiserver). Se un webhook blocca il ruolo RBAC per il componente dell'API server, l'API server non si avvia e l'upgrade del cluster non viene completato.

Anche se un webhook funziona correttamente, può causare l'errore dell'upgrade del cluster perché potrebbe non essere raggiungibile dal piano di controllo appena creato.

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 i log di controllo di GKE per verificare la presenza di chiamate RBAC con le seguenti informazioni:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

RBAC_RULE è il nome completo di un ruolo RBAC, ad esempio rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

Il nome del webhook con errore viene visualizzato nel log con il seguente formato:

admission webhook WEBHOOK_NAME denied the request

Per risolvere il problema, prova quanto segue:

  • Modifica le limitazioni per consentire la creazione e l'aggiornamento di ClusterRoles con il prefisso system:.
  • Modifica il webhook in modo che non intercetti le richieste di creazione e aggiornamento degli ruoli RBAC di sistema.
  • Disattivare l'webhook.

Perché succede?

Kubernetes esegue il riconcilio automatico{track-name="k8sLink" track-type="troubleshooting"} dei ruoli RBAC di sistema predefiniti con i criteri predefiniti nell'ultima versione minore. I criteri predefiniti per i ruoli di sistema a volte cambiano nelle nuove versioni di Kubernetes.

Per eseguire questa riconciliazione, GKE crea o aggiorna i ClusterRole e i 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 minore.

Problema: carichi di lavoro espulsi dopo l'upgrade del cluster standard

I tuoi workload potrebbero essere a rischio di espulsione dopo un upgrade del cluster se si verificano tutte le seguenti condizioni:

  • I carichi di lavoro di sistema richiedono più spazio quando il piano di controllo del cluster esegue la nuova versione di GKE.
  • I nodi esistenti non dispongono di risorse sufficienti per eseguire i nuovi carichi di lavoro di sistema e quelli esistenti.
  • Il gestore della scalabilità automatica dei cluster è disabilitato per il cluster.

Per risolvere il problema, prova a procedere nel seguente modo:

Problema: la versione del nodo non è compatibile con la versione del control plane

Controlla quale versione di Kubernetes è in esecuzione nel piano di controllo del cluster e poi controlla quale versione di Kubernetes è in esecuzione nei pool di nodi del cluster. Se uno dei pool di nodi del cluster è precedente di più di due versioni secondarie rispetto al piano di controllo, potrebbero verificarsi problemi con il cluster.

Periodicamente, il team di GKE esegue per tuo conto gli upgrade del piano di controllo del cluster. Viene eseguito l'upgrade dei piani di controllo alle versioni stabili più recenti di Kubernetes. Per impostazione predefinita, i nodi di un cluster hanno attivato l'upgrade automatico e ti consigliamo di non disattivarlo.

Se l'upgrade automatico è disattivato per i nodi di un cluster e non esegui manualmente l'upgrade della versione del pool di nodi a una versione compatibile con il piano di controllo, il piano di controllo diventerà incompatibile con i nodi man mano che viene eseguito l'upgrade automatico nel tempo. L'incompatibilità tra il piano di controllo del cluster e i nodi può causare problemi imprevisti.

Le norme relative al supporto della versione e del disallineamento delle versioni di Kubernetes stabiliscono che i control plane sono compatibili con i nodi fino a due versioni secondarie meno recenti del control plane. Ad esempio, i piani di controllo Kubernetes 1.19 sono compatibili con i nodi Kubernetes 1.19, 1.18 e 1.17. Per risolvere questo problema, esegui manualmente l'upgrade della versione del pool di nodi a una versione compatibile con il piano di controllo.

Se temi che la procedura di upgrade possa causare interruzioni dei carichi di lavoro in esecuzione sui nodi interessati, completa i seguenti passaggi per eseguirne la migrazione a un nuovo pool di nodi:

  1. Crea un nuovo pool di nodi con una versione compatibile.
  2. Cordon i nodi del pool di nodi esistente come non pianificabili.
  3. (Facoltativo) Aggiorna i carichi di lavoro in esecuzione sul pool di nodi esistente per aggiungere un nodeSelector per l'etichetta cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME, dove NEW_NODE_POOL_NAME è il nome del nuovo pool di nodi. In questo modo, GKE posiziona questi carichi di lavoro sui nodi del nuovo pool di nodi.
  4. Svuota il pool di nodi esistente.
  5. Verifica che i workload vengano eseguiti correttamente nel nuovo pool di nodi. In questo caso, puoi eliminare il vecchio pool di nodi. Se noti interruzioni dei carichi di lavoro, riprogrammali sui nodi esistenti annullando il cordone dei nodi nel pool di nodi esistente e svuotando i nuovi nodi. Risolvi il problema e riprova.

Problema: i pod rimangono in stato di attesa dopo la configurazione di Node Allocatable

Dopo aver configurato Node Allocatable e aver eseguito un upgrade della versione del nodo, potresti notare che i pod in esecuzione sono stati impostati su pending.

Se i pod sono in attesa dopo un upgrade, ti consigliamo quanto segue:

Passaggi successivi

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