Risolvere i problemi relativi agli upgrade

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

Problema: kube-apiserver non integro dopo l'upgrade del control plane

Il seguente problema si verifica quando avvii un upgrade manuale del control plane della versione GKE del cluster. Alcuni webhook di controllo degli accessi implementati dall'utente possono impedire ai componenti di sistema di creare ruoli RBAC permissivi necessari per funzionare correttamente. Durante un upgrade del control plane, Google Cloud viene ricreato il componente del server API Kubernetes (kube-apiserver). Se un webhook blocca il ruolo RBAC per il componente 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'esito negativo dell'upgrade del cluster perché potrebbe non essere raggiungibile dal control plane appena creato.

Il messaggio di errore in gcloud 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 non riuscito, controlla i log di controllo di GKE per 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 non riuscito viene visualizzato nel log nel seguente formato:

admission webhook WEBHOOK_NAME denied the request

Per risolvere il problema, prova quanto segue:

  • Modifica i vincoli 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 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, le norme predefinite per i ruoli di sistema 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 dalle norme RBAC predefinite, il server API non può funzionare nella nuova versione secondaria.

Problema: i workload vengono eliminati 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 control plane 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 la versione di Kubernetes in esecuzione sul control plane del cluster e poi controlla la versione di Kubernetes in esecuzione sui node pool del cluster. Se uno dei pool di nodi del cluster è precedente di più di due versioni secondarie rispetto al control plane, questo potrebbe causare problemi al cluster.

Periodicamente, il team GKE esegue gli upgrade del control plane del cluster per tuo conto. I control plane vengono sottoposti all'upgrade a versioni stabili più recenti di Kubernetes. Per impostazione predefinita, i nodi di un cluster hanno l'upgrade automatico abilitato e ti consigliamo di non disabilitarlo.

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

Le norme di supporto per la versione di Kubernetes e il disallineamento delle versioni indicano che i control plane sono compatibili con i nodi fino a due versioni secondarie precedenti a quella 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 versionepool di nodil a una versione compatibile con il control plane.

Se ti preoccupa che la procedura di upgrade possa causare interruzioni ai carichi di lavoro in esecuzione sui nodi interessati, completa i seguenti passaggi per eseguire la migrazione dei carichi di lavoro a un nuovpool di nodiol:

  1. Crea un nuovo pool di nodi con una versione compatibile.
  2. Contrassegna 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, riprogramma i carichi di lavoro sui nodi esistenti rimuovendo il blocco dei nodi nel pool di nodi esistente e svuotando i nuovi nodi. Risolvi il problema e riprova.

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

Dopo aver configurato Node Allocatable ed eseguito l'upgrade della versione del nodo, potresti notare che i pod in esecuzione sono passati allo stato in attesa.

Se i pod sono in attesa dopo un upgrade, ti consigliamo di procedere nel seguente modo:

Passaggi successivi