L'aggiornamento del cluster GKE può talvolta riservare ostacoli imprevisti. Questo articolo analizza un caso reale in cui un upgrade apparentemente semplice alla versione 1.27 è stato bloccato da una "chiamata a un'API deprecata".
GKE sospende gli aggiornamenti automatici
Quando GKE rileva l'utilizzo di una funzionalità o di un'API deprecata, sospende gli aggiornamenti automatici per evitare che il cluster venga portato in uno stato non funzionante. Gli aggiornamenti alla minor version di Kubernetes successiva vengono sospesi, mentre GKE continua a distribuire i patch upgrade sulla minor version corrente.
Se per 30 giorni GKE non rileva più l'utilizzo della funzionalità deprecata né chiamate alle API deprecate, il cluster viene aggiornato automaticamente, a condizione che la minor version successiva sia la versione di default nel release channel del cluster.
Se invece GKE continua a rilevare l'uso della funzionalità deprecata, mantiene il cluster sulla minor version corrente fino alla data di end of life della versione. Una volta raggiunta tale data — consultabile nel Release Schedule — il cluster passa automaticamente alla minor version successiva e l'ambiente potrebbe risultare compromesso, dato che la funzionalità rimossa è ancora in uso.
Aggiornamento GKE bloccato
In questo caso, GKE ha individuato una chiamata a un'API deprecata come causa del blocco dell'upgrade dalla versione 1.26. Tuttavia, esaminando il cluster, non emergeva alcuna traccia del responsabile: un "horizontalPodAutoscaler" che utilizzava un'API deprecata.
Fasi dell'indagine
GKE Insights: sebbene GKE Insights abbia segnalato la chiamata all'API deprecata (
horizontalPodAutoscalerv2beta2) e uno user agent ("v2.3.0"), quest'ultimo non forniva informazioni utili.API deprecata: consultando l'elenco delle API deprecate della 1.27, si nota che HPA v2beta2 non sarà disponibile sui cluster con Kubernetes 1.26.
Admin Activity Audit Logs: il primo metodo consigliato è individuare i client API che effettuano chiamate di write all'API deprecata tramite la query di log riportata di seguito. Per eseguirla è necessario il ruolo roles/logging.viewer.
resource.type="k8s_cluster"
labels."k8s.io/removed-release"="1.26"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")
- Data Access Audit Logs: come passo successivo, individuiamo i client API che effettuano chiamate di lettura alle API deprecate. Occorre prima abilitare Kubernetes data read e Admin read. Per visualizzare i log potrebbe essere necessario anche il ruolo roles/logging.privateLogViewer.
Il colpevole svelato
Dopo aver atteso il popolamento dei log, il colpevole è emerso: una versione obsoleta (2.3.0) di kube-state-metrics! Kube-state-metrics, servizio di monitoraggio per gli oggetti Kubernetes, effettuava chiamate "list" all'API deprecata v2beta2, innescando il blocco dell'aggiornamento. Un caso che evidenzia quanto siano interconnessi gli ambienti cloud.
Esaminando il codice sorgente è possibile individuare con precisione l'origine della chiamata.
La soluzione
L'aggiornamento di kube-state-metrics a una versione che non utilizza l'API deprecata ha risolto il problema, aprendo la strada a un upgrade GKE senza intoppi.
Conclusione
- Filtro di esclusione del logging bucket: controlli il filtro di esclusione del logging bucket per assicurarsi che i data access audit log non siano esclusi, così da accelerare l'indagine.
- Resti aggiornato sulle modifiche delle API: monitori in modo proattivo le modifiche delle API Kubernetes per anticipare possibili blocchi agli aggiornamenti.
- Comprenda la differenza tra versioni statiche e release channel: valuti il compromesso tra versioni statiche (stabilità) e release channel (correzioni di sicurezza automatiche) nella sua strategia di aggiornamento.
- Gestisca gli aggiornamenti in modo strategico: sfrutti gli auto-upgrade e le maintenance exclusion per controllare i tempi di aggiornamento, valutando comunque di consentire i patch upgrade per le correzioni di sicurezza critiche.
- Attenzione ai costi dei log: abilitare i data access audit log può comportare costi aggiuntivi. Valuti le sue esigenze prima di attivarli per periodi prolungati.
Seguendo questi accorgimenti, potrà affrontare gli aggiornamenti GKE con maggiore sicurezza, riducendo al minimo le interruzioni alle sue operazioni cloud.
Se non conosce ancora DoiT International, le consigliamo di scoprirci. Il nostro team è pronto ad approfondire le sue esigenze di cloud engineering. Composto esclusivamente da senior engineer, è specializzato in consulenza cloud avanzata, progettazione architetturale e supporto al debugging. Ci contatti, parliamone insieme!
Mi auguro che questo articolo le sia stato utile! Per qualsiasi domanda, lasci pure un commento qui sotto.