Risolvere i problemi relativi agli upgrade

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

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

Problema: 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 tuo cluster. Alcuni webhook di ammissione implementati dall'utente impedire ai componenti del sistema di creare ruoli RBAC permissivi necessari funzionino correttamente. Durante l'upgrade di un piano di controllo, Google Cloud ricrea il componente server API Kubernetes (kube-apiserver). Se un webhook blocca il ruolo RBAC per il componente server API, il server API non si avvia e l'upgrade del cluster non sarà completato.

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

Il messaggio di errore nell'interfaccia a riga di comando gcloud è 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 in nuovi le versioni di Kubernetes.

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

Problema: carichi di lavoro eliminati dopo l'upgrade del cluster Standard

I carichi di lavoro 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 il nuovo sistema carichi di lavoro esistenti 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

Verifica quale versione di Kubernetes è in esecuzione nel piano di controllo del tuo cluster e e poi verifica quale versione di Kubernetes sono in esecuzione nei pool di nodi del tuo 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 GKE esegue upgrade del cluster piano di controllo per tuo conto. È stato eseguito l'upgrade dei piani di controllo alla versione stabile più recente tutte le versioni di Kubernetes. Per impostazione predefinita, i nodi di un cluster upgrade automatico attivata e ti consigliamo di non disattivala.

Se l'upgrade automatico è disabilitato per i nodi di un cluster e non lo devi manualmente esegui l'upgrade del tuo dalla versione del pool di nodi a una versione compatibile con il controllo di controllo, quest'ultimo diventerà incompatibile con i nodi poiché viene eseguito automaticamente l'upgrade del piano di controllo 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, Kubernetes 1.19 Control 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 il processo di upgrade causi interruzioni dei carichi di lavoro in esecuzione sui nodi interessati, completa i seguenti passaggi per eseguire la migrazione carichi di lavoro in 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.
  3. (Facoltativo) Aggiorna i carichi di lavoro in esecuzione nel 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. Svuotamento del pool di nodi esistente.
  5. Verifica che i carichi di lavoro 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, riprogramma i carichi di lavoro 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.