Problemi noti di GKE

Autopilot Standard

In questa pagina sono elencati i problemi noti di GKE. Questa pagina è rivolta ad amministratori e architetti che gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante e rispondono ad avvisi e pagine quando gli obiettivi del livello di servizio (SLO) non vengono soddisfatti o le applicazioni non funzionano.

In questa pagina sono elencati i problemi noti per tutte le versioni supportate e per le due versioni secondarie che precedono immediatamente la prima versione con assistenza estesa. Al termine del periodo di assistenza estesa di una versione, tutti i problemi N-2 vengono rimossi. Ad esempio, quando la versione 1.30 raggiunge la fine del supporto esteso, vengono rimossi i problemi noti specifici delle versioni 1.28 e precedenti.

Se fai parte di Google Developer Program, salva questa pagina per ricevere notifiche quando viene pubblicata una nota di rilascio correlata a questa pagina. Per saperne di più, consulta Pagine salvate.

Per filtrare i problemi noti in base alla versione o alla categoria del prodotto, seleziona i filtri dai seguenti menu a discesa.

Seleziona la tua versione di GKE:

1,35 1,34 1,33 1.32 1,31 1,30 1,29 1,28 1,27

Seleziona la categoria del problema:

Configurazione Installazione Upgrade e aggiornamenti Operazione Logging e monitoraggio Sicurezza Reimpostazione/eliminazione Prestazioni

In alternativa, cerca il problema:

Categoria	Versioni identificate	Versione/i corretta/e	Problema e soluzione alternativa
Upgrade e aggiornamenti	1.36.3-gke.1767000 e versioni successive		I workload di Agent Sandbox non funzionano dopo l'upgrade del cluster Il componente aggiuntivo Agent Sandbox (agentsandbox) ha promosso le sue definizioni di risorse personalizzate e l'API da v1alpha1 a v1beta1 a partire dalla versione GKE 1.36.3-gke.1767000. Se esegui l'upgrade di un cluster che esegue Agent Sandbox da una versione precedente alla 1.36.3-gke.1767000 senza eseguire la migrazione delle risorse personalizzate, i workload v1alpha1 esistenti non funzionano correttamente. Soluzione temporanea: Prima di eseguire l'upgrade del control plane del cluster alla versione 1.36.3-gke.1767000 o successiva, esegui la migrazione dei manifest e dei workload di Agent Sandbox da v1alpha1 a v1beta1 seguendo la guida alla migrazione di Agent Sandbox da v1alpha1 a v1beta1.
Operazione	1,35 1,36 1,37	1.35.6-gke.1250001 e versioni successive 1.36.4-gke.1391002 e versioni successive 1.37.1-gke.1187000 e versioni successive	Le richieste POST HTTP per i token dal server dei metadati non vanno a buon fine e restituiscono l'errore 400 Bad Request I workload che utilizzano Workload Identity Federation for GKE per autenticarsi alle API Google Cloud richiedendo token di accesso o token di identità dei account di servizio dal server dei metadati GKE (come /computeMetadata/v1/instance/service-accounts/default/token o /computeMetadata/v1/instance/service-accounts/default/identity) potrebbero non riuscire con un errore HTTP 400 Bad Request (INVALID_ARGUMENT). Questo problema si verifica quando un'applicazione, una libreria client o un gateway API invia una richiesta HTTP POST senza una catena di certificati valida nel corpo della richiesta. Nelle versioni di GKE interessate, le richieste POST a questi endpoint dei token sono rigorosamente riservate ai token di accesso e ai token ID associati. Di conseguenza, le richieste con payload vuoti, con codifica del modulo o JSON non validi vengono rifiutate. Per risolvere il problema, esegui l'upgrade all'ultima versione patch all'interno della versione secondaria di qualsiasi canale di rilascio. Soluzione temporanea: Per risolvere il problema, configura l'applicazione, la libreria client o l'API Gateway in modo che utilizzi il metodo GET anziché POST quando richiedi token di accesso o token ID dal server dei metadati, come nell'esempio seguente: curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" Se il tuo workload utilizza un SDK o un gateway di terze parti (come MuleSoft Flex Gateway, IBM App Connect o script HTTP personalizzati) che invia per impostazione predefinita richieste POST agli endpoint del server dei metadati, aggiorna la configurazione o la libreria client per inviare richieste GET.
Upgrade e aggiornamenti	1.33 e versioni successive	Da definire	Pod non pianificati e quota esaurita durante gli upgrade secondari in due passaggi per il control plane. Durante gli upgrade delle versioni secondarie in due passaggi per i control plane nei cluster Autopilot che utilizzano pod con durata estesa, è possibile eseguire il provisioning di nuovi node pool utilizzando la versione del nodo precedente. Il gestore della scalabilità automatica dei cluster valuta i nodi di cui è stato appena eseguito il provisioning rispetto alla versione del control plane di cui è stato eseguito l'upgrade, rileva una mancata corrispondenza della versione e applica il taint cloud.google.com/not-target-gke-version:true. Il gestore della scalabilità automatica dei cluster blocca anche lo scale up dei node pool di pod con durata estesa esistenti o appena creati che utilizzano la versione precedente del nodo. Questo comportamento impedisce la pianificazione dei pod e attiva un loop di scalabilità infinito. Anziché fare lo scale up di un pool di nodi esistente, il provisioning automatico dei nodi crea un nuovo pool di nodi singoli in ogni iterazione di scale up per soddisfare i workload in attesa. Questo loop genera centinaia di pool di nodi vuoti separati che possono esaurire le quote dei gruppi di istanze gestite a livello di regione. Soluzione temporanea: Per risolvere il loop di scalabilità, completa manualmente l'upgrade del control plane eseguendo il seguente comando: gcloud container clusters complete-control-plane-upgrade [CLUSTER_NAME] --location=[LOCATION] In alternativa, applica la seguente tolleranza ai workload interessati in modo che possano essere pianificati sui nodi della versione precedente: tolerations: - key: "cloud.google.com/not-target-gke-version" operator: "Equal" value: "true" effect: "NoSchedule"
Operazione	1.37.0-gke.2941000 e versioni successive	1.37.1-gke.1131000	I nodi che montano volumi NFS accumulano voci di montaggio e interrompono la creazione di container Sui nodi che eseguono versioni interessate, il montaggio di un volume NFS lascia voci aggiuntive nella tabella di montaggio del nodo. Inoltre, quando un pod che utilizza un volume NFS termina, i tentativi di smontaggio non vanno a buon fine, per cui kubelet riprova ripetutamente a smontare il volume. Ogni nuovo tentativo aggiunge altre voci alla tabella di montaggio, che cresce continuamente anche se non sono pianificati nuovi workload. Quando la tabella di montaggio raggiunge il limite del kernel, il runtime del container non può più creare container su quel nodo. Il nodo smette di eseguire nuovi pod, potrebbe segnalare uno stato NotReady e potrebbe riavviarsi ripetutamente. I pod che utilizzano volumi NFS potrebbero rimanere nello stato Terminating perché non è possibile smontare i relativi volumi. Negli eventi dei pod e nei log kubelet, i nodi in questo stato segnalano errori simili ai seguenti: MountVolume.SetUp failed for volume "VOLUME_NAME" : mount failed: exit status 1 mount: /etc: mount(2) system call failed: No space left on device Questo problema interessa i node pool che montano volumi NFS con il driver NFS in-tree di Kubernetes. I nodi che non utilizzano il driver NFS in-tree per montare i volumi NFS non sono interessati. Soluzione temporanea: Per ripristinare un nodo interessato, riavvialo o ricrealo. Le voci di montaggio aggiuntive esistono solo nello stato di esecuzione del nodo, quindi vengono cancellate al riavvio del nodo. I pod bloccati nello stato Terminating dopo il riavvio possono essere rimossi con il seguente comando: kubectl delete pod POD_NAME --namespace NAMESPACE --force --grace-period=0 Per evitare che il problema si ripresenti nei cluster Standard, esegui il downgrade dei node pool che montano volumi NFS a una versione 1.36. Imposta un'esclusione dalla manutenzione in modo che GKE non esegua automaticamente l'upgrade dei node pool a una versione interessata. Se un cluster Autopilot esegue una versione interessata, utilizza una delle seguenti opzioni: Se i volumi NFS sono supportati da Filestore, montali con il driver CSI di Filestore anziché con il driver NFS in-tree. Il driver CSI monta i volumi dal proprio container e non utilizza il componente del nodo interessato. Se devi continuare a utilizzare il driver NFS in-tree, lascia che la riparazione automatica dei nodi recuperi i nodi interessati. I cluster Autopilot riparano i nodi automaticamente e un nodo che segnala uno stato NotReady per circa 10 minuti viene svuotato e ricreato, il che cancella la relativa tabella di montaggio.
Upgrade	1.34.9-gke.1065000 e versioni successive, 1.35.6-gke.1049000 e versioni successive e tutte le versioni patch 1.36	1.34.10-gke.1328000 e versioni successive, 1.35.8-gke.1026000 e versioni successive, 1.36.4-gke.1058000 e versioni successive (non è ancora disponibile una correzione per 1.37)	Errori dei workload GPU A4X Max (GB300) La creazione o l'upgrade dei node pool GKE A4X Max (a4x-maxgpu-4g-metal) a versioni patch specifiche (consulta la colonna Versioni identificate) causa errori dei workload GPU con i superchip NVIDIA GB300 Grace Blackwell Ultra collegati. A causa dei tempi di avvio prolungati della memoria a larghezza di banda elevata (HBM) sull'hardware GB300 con questo tipo di macchina bare metal, il servizio di avvio nvidia-persistenced va in timeout. Questo timeout lascia le GPU non inizializzate e genera il messaggio di errore cudaErrorDeviceUnavailable(46) quando i pod tentano di richiedere risorse CUDA. Soluzione: Esegui l'upgrade di ogni cluster e pool di nodi interessato a una versione corretta. GKE impedisce la creazione di node pool A4X Max con le versioni interessate e non eseguirà automaticamente l'upgrade dei node pool alle versioni interessate. GKE non impedisce gli upgrade manuali alle versioni interessate. Tuttavia, per evitare errori, ti consigliamo di non eseguire l'upgrade alle versioni interessate. Soluzione temporanea: Se non puoi eseguire l'upgrade, elimina tutti i node pool A4X Max che eseguono le versioni interessate e ricreali utilizzando una versione precedente non interessata. Tieni presente che, poiché la capacità massima di A4X deve essere ottenuta tramite una prenotazione, non perderai alcuna capacità eliminando i node pool.
Operazione	Versioni 1.33 precedenti alla 1.33.5-gke.2469000, versioni 1.34 precedenti alla 1.34.1-gke.2037001	1.33.5-gke.2469000 e versioni successive, 1.34.1-gke.2037001 e versioni successive, 1.35 e versioni successive	Nodi GPU o TPU bloccati con taint impending-node-termination dopo la manutenzione dell'host Sui cluster GKE con nodi acceleratore (GPU o TPU) che eseguono versioni interessate, i nodi potrebbero bloccarsi con i taint cloud.google.com/impending-node-termination o cloud.google.com/maintenance-window-started dopo il completamento della manutenzione o delle riparazioni dell'host Compute Engine. Quando l'istanza VM viene riavviata, il controller di manutenzione di GKE potrebbe applicare nuovamente questi taint in modo prematuro se è pianificato un altro evento di manutenzione futuro per il nodo, impedendo la pianificazione di nuovi workload su nodi integri. Soluzione temporanea: Per risolvere lo stato di blocco, devi rimuovere manualmente dai nodi interessati sia le etichette di manutenzione attiva gestite da GKE sia i taint. Se rimuovi solo i taint, il controller di manutenzione di GKE li riapplicherà automaticamente. Per cancellare le etichette e le incompatibilità, esegui questi comandi: kubectl label nodes NODE_NAME cloud.google.com/active-node-maintenance- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time- kubectl label nodes NODE_NAME cloud.google.com/scheduled-maintenance-time-latest- kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination- kubectl taint nodes NODE_NAME cloud.google.com/maintenance-window-started- Sostituisci NODE_NAME con il nome del nodo interessato.
Operazione	1,33 1,34	1.34.1-gke.1829001 e versioni successive	Errori di ammissione dei pod per i workload TPU v7 dovuti alla segnalazione di un numero di chip errato. GKE annuncia erroneamente otto chip TPU allocabili per gli acceleratori TPU v7 (tpu7x) con una topologia 2x2x1, che contiene fisicamente solo quattro chip. Questa mancata corrispondenza dei report impedisce la pianificazione dei pod per i workload TPU v7. L'architettura dual-chiplet di TPU v7 non viene gestita correttamente nelle versioni precedenti, il che comporta errori di ammissione dei pod. A seconda delle risorse TPU richieste, si verificano i seguenti errori: Quando richiedi quattro TPU (google.com/tpu: 4), il `kubelet` restituisce un UnexpectedAdmissionError: "invalid TPU chip count request, you must request all 4 chips on this node together". Quando richiedi otto TPU (google.com/tpu: 8), il webhook di ammissione tpu-accelerator-topology-constraints nega la richiesta con il seguente errore: "Invalid resource requests for google.com/tpu. Deve essere uguale a uno dei valori [4] per l'acceleratore tpu7x e la topologia 2x2x1". Soluzione temporanea: Per risolvere il problema, esegui l'upgrade del cluster GKE alla versione 1.34.1-gke.1829001 o successiva.
Operazione	1.35.3-gke.1234000 e versioni successive	Da definire	Il client Lustre non utilizza le NIC secondarie sui nodi multi-NIC Sui nodi GKE con più schede di interfaccia di rete (NIC), il driver CSI di Managed Lustre è abilitato per impostazione predefinita per utilizzare tutte le NIC disponibili per aggregare la larghezza di banda distribuendo il traffico di archiviazione TCP tra le interfacce di rete. Tuttavia, a causa di un problema noto, i client Lustre a partire dalla versione 2.14.0_p249 potrebbero non utilizzare le NIC secondarie. Invece, tutto il traffico di archiviazione TCP verso l'istanza Managed Lustre viene instradato esclusivamente tramite la NIC principale, impedendo l'aggregazione della larghezza di banda e limitando il throughput di archiviazione. Soluzione temporanea: Se i tuoi workload richiedono l'aggregazione della larghezza di banda multi-NIC per Managed Lustre, esegui il downgrade dei node pool a una versione di GKE precedente alla 1.35.3-gke.1234000, ad esempio 1.35.2-gke.1842000.
Operazione	1.35 e versioni successive	Da definire	Timeout della connessione o connessione rifiutata per i flussi reindirizzati al server di metadati GKE In GKE versione 1.35 e successive, i workload che utilizzano Workload Identity per l'autenticazione alle API Google Cloud potrebbero riscontrare timeout di connettività temporanei o connessioni rifiutate al server di metadati GKE immediatamente dopo l'avvio del nodo. Soluzione temporanea: Per consigli e soluzioni alternative, consulta Risolvi gli errori di timeout all'avvio del pod.
Operazione	1.33.8-gke.1026000 e versioni successive	1.35.1 e versioni successive	Il pod shim gVisor non riesce a eseguire la pulizia e registra l'errore "runsc: executable file not found in $PATH" A ogni uscita dal pod gVisor o interruzione per memoria esaurita, containerd tenta di eliminare la sandbox. Tuttavia, a volte il processo di pulizia non va a buon fine e viene registrato l'errore exec: "runsc": executable file not found in $PATH. Questo errore può causare problemi come l'esaurimento delle risorse, il degrado della rete, il panico di NodeLocalDNS, i timeout DNS o una latenza elevata durante la creazione dei pod. Soluzione: Esegui l'upgrade dei nodi GKE alla versione 1.35.1 o successiva. Per i cluster Standard, esegui l'upgrade del pool di nodi con i nodi interessati. Per i cluster Autopilot, esegui manualmente l'upgrade del cluster Autopilot alla versione 1.35.1 o successiva e GKE eseguirà automaticamente l'upgrade dei nodi in modo che corrispondano alla versione del control plane il prima possibile. Soluzione temporanea: Se non riesci a eseguire l'upgrade del cluster, esegui una delle seguenti operazioni: Esamina e aumenta le richieste e i limiti di memoria per i pod gVisor. Esegui il deployment del seguente DaemonSet con privilegi per copiare il file binario runsc da /home/containerd/usr/local/sbin a /home/kubernetes/bin: apiVersion: apps/v1 kind: DaemonSet metadata: name: runsc-path namespace: kube-system spec: selector: matchLabels: app: runsc-path updateStrategy: type: RollingUpdate template: metadata: labels: app: runsc-path spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: sandbox.gke.io/runtime operator: In values: - gvisor tolerations: - effect: NoSchedule key: sandbox.gke.io/runtime operator: Equal value: gvisor volumes: - name: host hostPath: path: / initContainers: - name: copy-runsc image: bash command: - /usr/local/bin/bash - -c - | set -euo pipefail cp /host/home/containerd/usr/local/sbin/runsc /host/home/kubernetes/bin chmod a+rx /host/home/kubernetes/bin/runsc volumeMounts: - name: host mountPath: /host resources: requests: memory: 5Mi cpu: 5m securityContext: privileged: true containers: - image: gcr.io/google-containers/pause:3.2 name: pause
Operazione	1.35.0-gke.2232000 e versioni successive	1.35.3-gke.1.35.3-gke.1290000 e versioni successive	I volumi dinamici utilizzano il tipo di disco predefinito I workload che utilizzano volumi dinamici in GKE 1.35.0-gke.2232000 o versioni successive potrebbero non riuscire a pianificare o collegare. Questo problema può anche causare il provisioning dei volumi utilizzando il hd-type di riserva (ad esempio hyperdisk-balanced) anziché il pd-type, anche sui nodi che non supportano Hyperdisk. Questo accade perché il server del nodo PDCSI non riesce a compilare l'oggetto CSINode con le topologie dei tipi di disco supportate. Di conseguenza, il controller non dispone delle informazioni sulla topologia necessarie per abbinare i volumi ai nodi compatibili. Soluzione temporanea: Esegui l'upgrade alla versione 1.35.3-gke.1290000 o successive.
Upgrade e aggiornamenti	Tutte le versioni patch precedenti alla 1.34.3-gke.1208000 per GKE 1.34 Tutte le versioni patch precedenti alla 1.35.0-gke.2232000 per GKE 1.35	1.34.3-gke.1208000 per GKE 1.34 1.35.0-gke.2232000 per GKE 1.35	Problemi di avvio dei pod durante gli upgrade a GKE 1.35 per i cluster GKE Dataplane V2 Cluster che eseguono l'upgrade del control plane alla versione GKE 1.35.0-gke.2232000 e successive dalle versioni precedente alla versione 1.34.3-gke.1208000 per GKE 1.34 precedente alla versione 1.35.0-gke.2232000 per GKE 1.35 potrebbero verificarsi problemi di avvio dei pod per i nuovi workload creati durante l'implementazione del DaemonSet anetd. L'avvio dei nuovi workload non andrà a buon fine durante l'implementazione di anetd se sono pianificati su un nodo con anetd non aggiornato. Durante l'implementazione, potresti visualizzare il seguente messaggio di errore: Failed to create pod sandbox: rpc error [...] plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded Ciò si verifica perché GKE utilizza l'operatore identity-management-mode, che richiede che tutti gli agenti e l'operatore abbiano una visualizzazione sincronizzata delle etichette relative all'identità. A partire da GKE 1.35.0-gke.2232000, le etichette topology.kubernetes.io sono escluse dal set pertinente all'identità per evitare la duplicazione delle identità. Questa modifica causa una mancata corrispondenza temporanea della configurazione tra il control plane di cui è stato eseguito l'upgrade e gli agenti anetd obsoleti durante l'implementazione. Per saperne di più, consulta la richiesta di pull di Cilium. Soluzione temporanea: Per GKE 1.34 precedente alla versione 1.34.3-gke.1208000: esegui prima l'upgrade alla versione 1.34.3-gke.1208000 o successiva, quindi esegui l'upgrade alla versione 1.35.0-gke.2232000 o successiva Per GKE 1.35 precedente alla versione 1.35.0-gke.2232000: dopo l'upgrade, attendi il completamento dell'implementazione di anetd. Per velocizzare manualmente l'implementazione, elimina i pod anetd obsoleti. In questo modo, l'operatore e gli agenti dei nodi anetd avranno una visualizzazione sincronizzata delle etichette relative all'identità.
Upgrade e aggiornamenti	1.32 1,33 1,34 1,35	1.32.11-gke.1153001 e versioni successive 1.33.5-gke.2326000 e versioni successive 1.34.3-gke.1214000 e versioni successive 1.35.0-gke.2180000 e versioni successive	Ritardi nella pianificazione dei pod sui nuovi nodi con policy di rete Calico abilitata Sui cluster GKE con policy di rete Calico abilitata, una regressione nelle versioni interessate può causare ritardi significativi nella pianificazione dei pod su nodi nuovi o ricreati. Questi ritardi possono far sì che i nodi rimangano in uno stato NotReady per periodi prolungati. Il problema è causato dallo script di avvio CNI di Calico che formatta in modo errato l'URL del server API Kubernetes per gli indirizzi IPv4 racchiudendoli tra parentesi quadre ([]). Questo approccio genera un errore di analisi dell'URL durante la creazione di nuovi sandbox dei pod, visibile nei log di "kubelet": Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox ""sandbox-id"": plugin type="calico" failed (add): error creating calico client: host must be a URL or a host:port pair: "https://[IPv4-address]:443" Soluzione temporanea: La versione del componente Calico è determinata dalla versione del control plane del cluster. Per mitigare questo problema, esegui l'upgrade del control plane del cluster a una delle versioni corrette. Dopo aver eseguito l'upgrade del control plane, devi ricreare i nodi nei tuoi pool di nodi per assicurarti che utilizzino il formato URL del server API Kubernetes corretto. Puoi farlo eseguendo un upgrade in loco del node pool alla stessa versione o a una versione più recente oppure ricreando manualmente i node pool.
Prestazioni	1.32.8-gke.1134000 e versioni successive per GKE 1.32 1.33.3-gke.1392000 e versioni successive per GKE 1.33 Tutte le versioni patch per GKE 1.34 e 1.35	1.32.11-gke.1075000 e versioni successive per GKE 1.32 1.33.5-gke.2392000 e versioni successive per GKE 1.33 1.34.3-gke.1318000 e versioni successive per GKE 1.34 1.35.0-gke.2398000 e versioni successive per GKE 1.35	Le prestazioni del networking per uso generico diminuiscono sui tipi di macchina GPU della serie A e G4 I cluster GKE con nodi GPU serie A e G4 mostrano prestazioni ridotte per il networking per uso generico su GKE 1.32.8-gke.1134000 e versioni successive per GKE 1.32 e su GKE 1.33.3-gke.1392000 e versioni successive. Il peggioramento delle prestazioni sul networking per uso generico influisce sui tipi di macchine GPU, tra cui le serie di macchine A3, A4, A4X e G4. Tieni presente che GPUDirect-TCPXO su A3 Mega e GPUDirect-RDMA su A3 Ultra, A4 e A4X non sono interessati. Questo accade perché lo script a livello di nodo (/usr/bin/google_set_multiqueue) che imposta l'affinità di interruzione non è configurato correttamente. Soluzione temporanea: Esegui l'upgrade di ogni pool di nodi interessato a una versione corretta.
Prestazioni	1.32.8-gke.1134000 e versioni successive per GKE 1.32 1.33.3-gke.1392000 e versioni successive per GKE 1.33 e versioni successive	1.32.11-gke.1075000 e versioni successive per GKE 1.32 1.33.5-gke.2392000 e versioni successive per GKE 1.33	Le prestazioni di GPUDirect-TCPX diminuiscono su A3 High I cluster GKE con nodi A3 High (a3-highgpu-8g) mostrano prestazioni ridotte quando utilizzano GPUDirect-TCPX su GKE 1.32.8-gke.1134000 e versioni successive per GKE 1.32 e su GKE 1.33.3-gke.1392000 e versioni successive. Questo accade perché lo script a livello di nodo (/usr/bin/google_set_multiqueue) che imposta l'affinità di interruzione non è configurato correttamente. Soluzione temporanea: Per i node pool GKE 1.32, esegui l'upgrade delle versioni dei node pool GKE alla versione 1.32.11-gke.1075000 o successiva. Per i node pool GKE 1.33 e versioni successive, esegui l'upgrade delle versioni dei node pool GKE alla versione 1.33.5-gke.2392000 o successive. Per i node pool GKE 1.34, consulta GPUDirect-TCPX non è disponibile con A3 High per GKE 1.34 e versioni successive.
Upgrade	1,35	1.35.0-gke.2232000 e versioni successive.	Duplicazione dell'identità Cilium nei cluster GKE Dataplane V2 I cluster GKE che eseguono la versione 1.35 con GKE Dataplane V2 abilitato potrebbero registrare un aumento del numero di risorse personalizzate ciliumidentities.cilium.io. Questo problema è causato dall'aggiunta di etichette topology.kubernetes.io ai pod in Kubernetes 1.35, che genera identità Cilium aggiuntive per ogni zona in cui è pianificato un pod di un workload. Sia nei cluster a livello di regione che in quelli a livello di zona, la pianificazione di un nuovo workload può causare una duplicazione temporanea dell'identità Cilium. Questa duplicazione si verifica perché i pod ricevono un'identità al momento della creazione in base alle etichette iniziali e un'altra identità dopo l'aggiunta delle etichette di topologia quando il pod viene pianificato su un nodo. Nei cluster a livello di regione, il numero di identità potrebbe aumentare ulteriormente di un fattore proporzionale al numero di zone interessate dal cluster. Impatto: Se il numero totale di identità supera 65.535, la pianificazione di nuovi workload potrebbe non riuscire. Soluzione temporanea: Per limitare il numero totale di identità, evita di aggiungere ai pod etichette con un numero elevato di valori univoci. Per saperne di più, consulta la seguente documentazione di Cilium: Sicurezza basata sull'identità Identità di sicurezza Gli upgrade manuali devono essere eseguiti dalle versioni 1.34.3-gke.1208000 e successive. Se avvii l'upgrade da una versione precedente alla 1.34.3-gke.1208000, potresti riscontrare problemi temporanei con la pianificazione dei pod durante il processo di upgrade.
Upgrade	Versioni patch 1.34 precedenti alla 1.34.5-gke.1153000 Versioni patch 1.35 precedenti alla 1.35.2-gke.1485000	1.34.5-gke.1153000 e versioni successive 1.35.2-gke.1485000 e versioni successive 1.36 e versioni successive Devi anche utilizzare il programma di installazione di GPUDirect-TCPX versione 3.1.9 o successive e il sidecar versione 2.0.12 o successive. Le versioni del programma di installazione e del sidecar hanno una mappatura uno a uno e devono corrispondere. Ad esempio, la versione 3.1.12 del programma di installazione di GPUDirect-TCPX corrisponde alla versione 2.0.15 del sidecar. Per ulteriori informazioni sulle versioni del programma di installazione e del sidecar, consulta le note di rilascio di GPUDirect-TCPX.	GPUDirect-TCPX non è disponibile con A3 High per versioni GKE specifiche I cluster GKE con nodi A3 High (a3-highgpu-8g) utilizzano GPUDirect-TCPX per massimizzare la larghezza di banda della rete GPU. Per i nodi che utilizzano TCPX e A3 High, l'upgrade alle versioni GKE interessate può causare problemi di funzionalità o problemi di prestazioni con TCPX. Questo perché TCPX non è compatibile con il kernel Linux 6.12 aggiornato utilizzato da Container-Optimized OS milestone 125 o versioni successive. La milestone 125 viene utilizzata dalla versione 1.34 di GKE. Altri tipi di macchine GPU A3 High (a3-highgpu-1g, a3-highgpu-2g, a3-highgpu-4g) e altre serie di macchine GPU non sono interessati perché non supportano GPUDirect-TCPX. Soluzione: Esegui l'upgrade alle patch della versione GKE corretta per risolvere il problema. Per informazioni dettagliate sulla configurazione e sull'upgrade dei node pool con GPUDirect-TCPX, consulta Massimizza la larghezza di banda di rete delle GPU nei cluster Standard o Massimizza la larghezza di banda di rete delle GPU nei cluster Autopilot. Quando esegui i test NCCL su versioni fisse, potresti visualizzare i seguenti avvisi che non influiscono sulle prestazioni o sulla funzionalità: Log NCCL WARN per Rx Ctrl Timeouts: questo messaggio può essere visualizzato se il workload pubblica un'operazione di comunicazione Recv sulla destinazione molto prima di pubblicare un'operazione di comunicazione Send sull'iniziatore. Non è previsto alcun impatto sul rendimento. Log NCCL WARN per No free space for recv task: questo messaggio avvisa di un numero totale ridotto di attività di rete per l'elaborazione delle operazioni, il che comporta l'occupazione temporanea di tutte le attività. Non è previsto alcun impatto sul rendimento.
Operazione	Tutte le versioni precedenti alla 1.34.0-gke.2285000	1.34.0-gke.2285000 e versioni successive	Capacità minima dell'istanza aggiornata La capacità minima per le istanze Managed Lustre è stata aggiornata a 9000 GiB. I cluster che eseguono versioni precedenti alla 1.34.0-gke.2285000 non possono creare istanze con questa capacità minima tramite il driver CSI Managed Lustre. Soluzione temporanea: Esegui l'upgrade della versione del cluster alla versione 1.34.0-gke.2285000 o successiva per abilitare la creazione di istanze Managed Lustre con una capacità minima di 9000 GiB.
Operazione	Tutte le versioni	Da definire	La UI della consoleGoogle Cloud non è modificabile durante la riparazione automatica dei nodi Quando un nodo GKE è in fase di riparazione automatica, il pool di nodi non è modificabile tramite la console Google Cloud a causa di un'operazione in corso. Soluzione temporanea: Puoi comunque modificare la configurazione del pool di nodi utilizzando i comandi gcloud CLI.
Operazione	Versioni 1.33 precedenti alla 1.33.4-gke.1036000	1.33.4-gke.1036000 e versioni successive	Livello di prestazioni errato per le istanze Lustre di cui è stato eseguito il provisioning dinamico Quando esegui il provisioning dinamico di un'istanza Lustre, la creazione dell'istanza non va a buon fine con un errore InvalidArgument per PerUnitStorageThroughput, indipendentemente dal valore perUnitStorageThroughput specificato nella richiesta API. Soluzione temporanea: Esegui l'upgrade del cluster GKE alla versione 1.33.4-gke.1036000 o successiva. Se utilizzi il canale stabile, potrebbe non essere ancora disponibile una versione più recente. In questo caso, puoi selezionare manualmente una versione dai canali Rapido o Regolare che includa la correzione.
Operazione	1.32.3-gke.1099000 e versioni successive 1,33	1.33.3-gke.1266000 e versioni successive	Errore di input/output durante la ridenominazione o lo spostamento di file utilizzando il driver CSI di Cloud Storage FUSE Quando utilizzi una versione interessata del driver CSI di Cloud Storage FUSE, la ridenominazione o lo spostamento dei file nei bucket Cloud Storage potrebbe non riuscire con un errore di I/O. Soluzione temporanea: Aggiungi temporaneamente una definizione specifica dell'immagine sidecar al manifest del pod. Nella sezione spec.containers del manifest del pod, aggiungi la seguente definizione del container con l'immagine: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2. # Add the following block to use the fixed sidecar image - name: gke-gcsfuse-sidecar image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2 Per saperne di più, consulta il manifest del pod in Configura un'immagine privata per il container sidecar. Dopo aver eseguito l'upgrade del cluster a una versione GKE corretta o successiva, devi rimuovere l'intero blocco gke-gcsfuse-sidecar dal manifest. Dopo aver rimosso questo blocco, GKE riprenderà a inserire e gestire automaticamente l'immagine sidecar corretta per la versione del cluster di cui è stato eseguito l'upgrade.
Logging e monitoraggio	Tutte le versioni	Da definire	Race condition nei DaemonSet gke-metrics-agent Quando aggiungi l'etichetta cloud.google.com/gke-metrics-agent-scaling-level a un pool di nodi per aumentare manualmente l'allocazione della memoria del DaemonSet gke-metrics-agent, si verifica una race condition nel DaemonSet durante la creazione di un nuovo nodo. Questa race condition comporta riavvii intermittenti e potrebbe comportare la perdita di metriche. Questo problema si verifica perché esiste un ritardo prima che l'etichetta venga aggiunta a un nuovo nodo nel pool di nodi. Durante questo ritardo, il DaemonSet crea un pod con l'allocazione della memoria originale su quel nodo. Dopo l'applicazione dell'etichetta, il DaemonSet crea un pod con la nuova allocazione della memoria. Il pod esistente non viene eliminato completamente all'avvio del pod aggiornato. Entrambi i pod tentano di associarsi allo stesso numero di porta. Soluzione temporanea: Dopo aver aggiunto l'etichetta cloud.google.com/gke-metrics-agent-scaling-level a un pool di nodi, riavvia il DaemonSet gke-metrics-agent: kubectl -n kube-system rollout restart daemonset gke-metrics-agent
Upgrade	1,33	1.33.2-gke.1043000	Limite di file aperti ridotto con containerd 2.0 Per i node pool che eseguono GKE versione 1.33, che utilizza containerd 2.0, il limite flessibile predefinito per i file aperti (ulimit -n) per i container viene ridotto a 1024. Si tratta di una modifica in containerd stesso (vedi containerd PR #8924) in cui LimitNOFILE è stato rimosso da containerd.service come best practice, in modo che venga applicato il limite flessibile predefinito del sistema. I workload che prevedono un limite flessibile predefinito più elevato (ad esempio quelli che si basano implicitamente sul valore predefinito più elevato precedente) potrebbero riscontrare errori, come gli errori Too many open files. Soluzione: Esegui l'upgrade da una versione patch 1.33 precedente alla versione 1.33.2-gke.1043000 o successiva. Soluzione temporanea: Aumenta il limite di file aperti per i tuoi workload utilizzando uno dei seguenti metodi: Modifica a livello di applicazione:modifica il codice dell'applicazione o la configurazione per impostare esplicitamente ulimit -n o prlimit --nofile=524288. Plug-in Containerd NRI Ulimit Adjuster Utilizza il plug-in containerd/nri ulimit-adjuster per regolare l'ulimit. Esegui il downgrade pool di nodi (solo Standard): per i cluster GKE Standard, puoi eseguire temporaneamente il downgrade del node pool alla versione 1.32 per evitare questo problema finché non sarà disponibile una soluzione permanente. Per ulteriori informazioni sulla migrazione a containerd 2, consulta Esegui la migrazione dei nodi a containerd 2.
Upgrade	1.31.5-gke.1169000, 1.32.1-gke.1376000	1.31.7-gke.1164000, 1.32.3-gke.1512000	CRD status.storedVersions non valido per i CRD gestiti Alcune CRD gestite da GKE potrebbero avere un campo status.storedVersions non valido, il che crea il rischio di interrompere l'accesso agli oggetti CRD dopo un upgrade. Questo problema interessa i cluster che soddisfano entrambe le seguenti condizioni: Cluster che hanno utilizzato una versione GKE interessata in un determinato momento. Cluster con versioni non supportate (served=false) di oggetti CRD archiviati in etcd. Soluzione temporanea: La soluzione alternativa consigliata è ritardare gli upgrade del cluster fino alla risoluzione del problema. In alternativa, se sai che il tuo cluster contiene versioni non supportate di oggetti CRD, puoi aggiungere queste versioni al campo status.storedVersions utilizzando il comando kubectl patch.
Operazioni, logging e monitoraggio	00:06:32, 120 --> 00:06:33, 605	1.32.2-gke.1652003 o versioni successive 1.31.6-gke.1221001 o versioni successive 1.30.10-gke.1227001 o versioni successive	Metriche mancanti o gestore della scalabilità automatica dei workload non funzionante Potresti notare lacune nei dati delle metriche sulle versioni interessate dopo che le dimensioni del cluster aumentano di oltre cinque nodi. Questo problema potrebbe influire anche sulle operazioni di scalabilità automatica. Questo problema riguarda solo i cluster di cui è stato eseguito l'upgrade alle versioni interessate. I cluster appena creati dovrebbero funzionare come previsto. Soluzione temporanea: Se il problema ti riguarda, puoi eseguire il downgrade di una versione della patch o l'upgrade alle versioni corrette più recenti.
Operazione			Limiti di dimensioni e collegamento di Google Cloud Hyperdisk In genere, un pod che non può essere pianificato correttamente a causa dei limiti di collegamento del volume di un nodo attiva il provisioning automatico di un nuovo nodo. Quando i workload che utilizzano un prodotto Hyperdisk vengono pianificati su un nodo che esegue una VM C3, il provisioning automatico dei nodi non viene eseguito e il pod viene pianificato sul nodo già pieno. Il workload viene pianificato sul nodo nonostante la mancanza di un collegamento del disco disponibile. Anche l'avvio del workload non riesce, a causa di un errore simile al seguente: AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17] Il problema è presente per tutti i prodotti Hyperdisk sulle macchine C3. I limiti di collegamento di Hyperdisk variano in base al numero di vCPU della VM e al prodotto Hyperdisk. Per ulteriori informazioni, consulta Limiti delle prestazioni di Hyperdisk. Soluzione temporanea: I prodotti Google Cloud Hyperdisk attivano il provisioning automatico su altre forme di VM. Ti consigliamo una forma che supporti solo Google Cloud Hyperdisk.
Operazione	01.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000		gke-metadata-server è OOMKilled sui nodi TPU/GPU Sui nodi TPU GKE (ad esempio ct4p-hightpu-4t) e sui nodi GPU (ad esempio a3-highgpu-8g), il kernel potrebbe terminare gke-metadata-server con un OOMKilled quando la memoria utilizzata del server supera i 100 MB. Soluzione temporanea: Se osservi eventi OOMKilled per gke-metadata-server sui nodi TPU o GPU, contatta il team di assistenza GKE Identity (ID componente: 395450) per le opzioni di mitigazione.
Operazione	1.32.0-gke.1358000 a 1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001, 1.32.4-gke.1533000 Da 1.33.0-gke.0 a 1.33.0-gke.1552000	1.32.4-gke.1353003 e versioni successive 1.33.0-gke.1552000 e versioni successive	Le modifiche alle dimensioni dei volumi potrebbero essere bloccate a causa dello stato NodePendingResize in sospeso sulle PVC. I cluster con versione 1.32 che hanno nodi con versione 1.31 o precedente non riusciranno ad aggiornare lo stato di PersistentVolumeClaim durante il ridimensionamento. Questo stato errato impedisce l'avvio delle operazioni di ridimensionamento successive, impedendo di fatto ulteriori ridimensionamenti. Un PVC in questo stato ha un campo status.allocatedResourceStatuses che contiene NodePendingResize o entrambi i campi status.allocatedResources e status.conditions.type: FileSystemResizePending. Se è stata creata una PVC mentre il cluster era in una versione interessata, potresti riscontrare questo problema anche dopo l'upgrade del cluster a una versione corretta nota. In questo scenario, devi applicare una patch alla PVC per rimuovere il campo status.allocatedResources con una soluzione alternativa una tantum. Soluzione temporanea: I PVC bloccati a causa dello stato di sospensione possono essere corretti per rimuovere questo stato. Puoi utilizzare un comando patch come il seguente per rimuovere lo stato di dangling: kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}' kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'
Operazione	1.32.4-gke.1236007, 1.32.4-gke.1353001	1.32.4-gke.1353003 e versioni successive	Il driver PDCSI potrebbe registrare un numero eccessivo di log I cluster GKE su versioni specifiche della 1.32 potrebbero generare un numero eccessivo di messaggi di log dal driver PDCSI. Questo logging eccessivo consumerebbe la quota dell'API Cloud Logging Write. Soluzione temporanea: Puoi ridurre questo logging eccessivo aggiungendo un filtro di esclusione. Per escludere l'importazione dei messaggi di log in Cloud Logging, utilizza la seguente query: resource.type="k8s_container" resource.labels.container_name="gce-pd-driver" (sourceLocation.file="cache.go" OR "Cannot process volume group")
Operazioni	1.27.16-gke.2440000 e versioni successive 1.28.15-gke.1673000 e versioni successive 1.29.13-gke.1038000 e versioni successive 1.30.9 e versioni successive 1.31.7 e versioni successive 1.32.1-gke.1357001 e versioni successive	1.27.16-gke.2691000 e versioni successive 1.28.15-gke.2152000 e versioni successive 1.29.15-gke.1218000 e versioni successive 1.30.11-gke.1190000 e versioni successive 1.31.7-gke.1363000 e versioni successive 1.32.4-gke.1106000 e versioni successive 1.33.0-gke.1552000 e versioni successive	I pod che tentano di montare volumi permanenti NFS su nodi COS che in precedenza avevano un montaggio di sola lettura (RO) verranno montati solo in modalità RO Per GKE versione 1.27 e successive, i volumi NFS che utilizzano il driver CSI in-tree di Kubernetes possono montare volumi permanenti in modalità RO solo dopo un montaggio RO precedente sullo stesso nodo. Soluzione temporanea: Esegui il downgrade dei node pool a una versione precedente a quelle interessate
Operazioni	Versioni 1.32 dalla 1.32.1-gke.1357001 alla 1.32.4-gke.1106000 (esclusa) Tutte le versioni 1.33 precedenti alla 1.33.0-gke.1552000 Release 1.32: 1.32.4-gke.1106000 e versioni successive Release 1.33: 1.33.0-gke.1552000 e versioni successive	I pod che tentano di montare volumi permanenti NFS sui nodi Ubuntu non potranno essere eseguiti. Per GKE versione 1.32 e successive, i volumi NFS che utilizzano il driver CSI in-tree di Kubernetes non potranno montare volumi permanenti sui nodi Ubuntu. In questo caso, potresti visualizzare i seguenti messaggi di errore: "MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1" Output: Mount failed: mount failed: exit status 127 "Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes" Oltre a visualizzare questi messaggi di errore, i pod che utilizzano questi volumi non potranno essere avviati. Soluzione temporanea: Esegui il downgrade dei node pool alla versione 1.31.
Operazione	>= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1369000	1.28.15-gke.1668000 o versioni successive 1.29.13-gke.1028000 o versioni successive 1.30.8-gke.1287000 o versioni successive 1.31.6-gke.1020000 o versioni successive 1.32.1-gke.1369000 o versioni successive	I pod che utilizzano syscall correlate a io_uring potrebbero essere bloccati in stato Terminating I pod che utilizzano syscall correlate a io_uring potrebbero entrare nello stato D (sospensione del disco), chiamato anche TASK_UNINTERRUPTIBLE, a causa di un bug nel kernel Linux. I processi in stato D non possono essere attivati da indicatori, tra cui SIGKILL. Quando un pod è interessato da questo problema noto, i suoi container potrebbero non terminare normalmente. Nei log di containerd, potresti osservare messaggi ripetuti simili ai seguenti: Kill container [container-id] che indicano che il sistema sta tentando ripetutamente di arrestare un container. Contemporaneamente, i log di kubelet mostrano messaggi di errore, come i seguenti: "Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded" o "Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid" Questi sintomi indicano che i processi all'interno del container sono bloccati in uno stato di sospensione non interrompibile (stato D), che impedisce la corretta terminazione del pod. I workload che utilizzano io_uring direttamente o indirettamente tramite un runtime di linguaggio come NodeJS potrebbero essere interessati da questo problema noto. I workload interessati hanno un processo nello stato D (sospensione del disco) nel file /proc/<pid>/state e mostrano la stringa io_uring come parte dei contenuti di /proc/<pid>/stack. I workload Node.js potrebbero essere in grado di disattivare l'utilizzo di io_uring tramite UV_USE_IO_URING=0. Soluzione temporanea: Esegui l'upgrade dei nodi del cluster a una versione corretta o successiva.
Operazione	1.28, 1.29, 1.30, 1.31	1.30.8-gke.1261000 e versioni successive 1.31.4-gke.1183000 e versioni successive 1.32.0-gke.1448000 e versioni successive	I workload che utilizzano lo streaming di immagini non riescono con errori di autenticazione Un bug nella funzionalità di streaming delle immagini potrebbe causare l'errore dei workload quando viene soddisfatto un insieme di condizioni specifiche durante la lettura dei file da parte del container. I messaggi di errore relativi agli errori di autenticazione potrebbero essere visibili nel log gcfsd. Per verificare se il problema ti riguarda, cerca nei log con questa query di ricerca: resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential." La presenza di questi errori indica che i nodi sono interessati. Se questo problema ti riguarda, puoi eseguire l'upgrade dei node pool a una versione GKE con patch.
Operazione	Da 1.30.0 a 1.30.5-gke.1443001 Da 1.31.0 a 1.31.1-gke.1678000	1.30.5-gke.1628000 e versioni successive 1.31.1-gke.1846000 e versioni successive	Aumento dei tassi di espulsione dei pod nelle versioni GKE 1.30 e 1.31 Alcune versioni di GKE 1.30 e GKE 1.31 che utilizzano rispettivamente COS 113 e COS 117 hanno kernel creati con l'opzione CONFIG_LRU_GEN_ENABLED=y. Questa opzione attiva la funzionalità del kernel LRU multi-generazione, che fa sì che il kubelet calcoli in modo errato la memoria utilizzata e potrebbe causare l'espulsione dei pod da parte del kubelet. L'opzione di configurazione CONFIG_LRU_GEN_ENABLED è disattivata in cos-113-18244-151-96 e cos-117-18613-0-76. Potresti non vedere sempre una frequenza di espulsione dei pod insolita perché questo problema dipende dal pattern di utilizzo della memoria utilizzata del workload. Esiste un rischio maggiore che il kubelet rimuova i pod per i workload per i quali non è stato impostato un limite di memoria nel campo delle risorse. Questo perché i workload potrebbero richiedere più memoria di quella che il kubelet segnala come disponibile. Se noti un utilizzo della memoria più elevato di un'applicazione dopo l'upgrade alle versioni GKE menzionate senza altre modifiche, potresti essere interessato dall'opzione del kernel. Per verificare se esistono frequenze di espulsione dei pod insolite, analizza le seguenti metriche con Esplora metriche: kubernetes.io/container_memory_used_bytes e kubernetes.io/container_memory_request_bytes Puoi utilizzare le seguenti query PromQL. Sostituisci i valori di cluster_name, namespace_name, metadata_system_top_level_controller_type e metadata_system_top_level_controller_name con il nome e il tipo di workload che vuoi analizzare: max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}])) Se noti picchi insoliti nella memoria utilizzata che superano la memoria richiesta, è possibile che il workload venga espulso più spesso. Soluzione alternativa Se non puoi eseguire l'upgrade alle versioni corrette e se utilizzi un ambiente GKE in cui puoi eseguire il deployment di pod con privilegi, puoi disattivare l'opzione LRU multi-generazione utilizzando un DaemonSet. Aggiorna i node pool GKE da cui vuoi eseguire il DaemonSet con un'annotazione per disattivare l'opzione LRU multi-generazione. Ad esempio, disable-mglru: "true". Aggiorna il parametro nodeSelector nel manifest del DaemonSet con la stessa annotazione utilizzata nel passaggio precedente. Ad esempio, consulta il file disable-mglru.yaml nel repository GoogleCloudPlatform/k8s-node-tools. Esegui il deployment del DaemonSet nel tuo cluster. Dopo che il DaemonSet è in esecuzione in tutti i node pool selezionati, la modifica diventa effettiva immediatamente e il calcolo della memoria utilizzata da kubelet torna alla normalità.
Operazione	1.28, 1.29, 1.30, 1.31	1.28.14-gke.1175000 e versioni successive 1.29.9-gke.1341000 e versioni successive 1.30.5-gke.1355000 e versioni successive 1.31.1-gke.1621000 e versioni successive	Pod bloccati nello stato Terminating Un bug nel runtime del container (containerd) potrebbe causare il blocco dei pod e dei container nello stato Terminating con errori simili ai seguenti: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown Se il problema ti riguarda, puoi eseguire l'upgrade dei nodi a una versione di GKE con una versione fissa di containerd.
Operazione	1.34 e versioni precedenti Versioni 1.35 precedenti alla 1.35.6-gke.1005000 Versioni 1.36 precedenti alla 1.36.0-gke.2459000	1.35.6-gke.1005000 e versioni successive 1.36.0-gke.2459000 e versioni successive	Lo streaming di immagini non va a buon fine a causa dei link simbolici Un bug nella funzionalità di flussi di immagini potrebbe impedire l'avvio dei container. La creazione dei container in esecuzione su un nodo con lo streaming delle immagini abilitato su versioni GKE specifiche potrebbe non riuscire con il seguente errore: "CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links" Soluzione temporanea: Per risolvere il problema, esegui l'upgrade dei node pool a una versione corretta (1.35.6-gke.1005000 o successiva oppure 1.36.0-gke.2459000 o successiva). Se non puoi eseguire l'upgrade, puoi verificare la presenza di livelli vuoti o duplicati. Se non riesci a rimuovere i livelli vuoti o duplicati, disattiva lo streaming di immagini.
Operazione	1.27,1.28,1.29	1.28.9-gke.1103000 e versioni successive 1.29.4-gke.1202000 e versioni successive 1.30: tutte le versioni	Lo streaming delle immagini non riesce a causa di file mancanti Un bug nella funzionalità di flussi di immagini potrebbe causare l'errore dei container a causa di uno o più file mancanti. I container in esecuzione su un nodo con lo streaming di immagini abilitato nelle seguenti versioni potrebbero non avviarsi o essere eseguiti con errori che indicano che determinati file non esistono. Ecco alcuni esempi di questi errori: No such file or directory Executable file not found in $PATH Se questo problema ti riguarda, puoi disattivare lo streaming di immagini.
Networking,Upgrades and updates	1,28		Errore di configurazione TLS del gateway Abbiamo identificato un problema relativo alla configurazione di TLS per i gateway nei cluster che eseguono GKE versione 1.28.4-gke.1083000. Ciò influisce sulle configurazioni TLS che utilizzano un SSLCertificate o una CertificateMap. Se esegui l'upgrade di un cluster con gateway esistenti, gli aggiornamenti apportati al gateway non riusciranno. Per i nuovi gateway, non verrà eseguito il provisioning dei bilanciatori del carico. Questo problema verrà risolto in una versione patch di GKE 1.28 imminente.
Upgrade e aggiornamenti	1,27	1.27.8 o versioni successive	Problema del plug-in del dispositivo GPU I cluster che eseguono GPU e di cui viene eseguito l'upgrade dalla versione 1.26 a una versione patch 1.27 precedente alla 1.27.8 potrebbero riscontrare problemi con i plug-in dei dispositivi GPU dei nodi (nvidia-gpu-device-plugin). Segui questi passaggi a seconda dello stato del tuo cluster: Se il tuo cluster esegue la versione 1.26 e ha GPU, non eseguire l'upgrade manuale del cluster finché la versione 1.27.8 non è disponibile nel canale di rilascio del cluster. Se il tuo cluster esegue una versione patch 1.27 precedente e i nodi sono interessati, riavvia i nodi o elimina manualmente il pod nvidia-gpu-device-plugin sui nodi (il gestore dei componenti aggiuntivi creerà un nuovo plug-in funzionante). Se il tuo cluster utilizza gli upgrade automatici, questo non ti riguarda, poiché gli upgrade automatici sposteranno i cluster solo alle versioni patch con la correzione.
Operazione	1.27,1.28	1.27.5-gke.1300 e versioni successive 1.28.1-gke.1400 e versioni successive	La scalabilità automatica per tutti i workload viene interrotta HorizontalPodAutoscaler (HPA) e VerticalPodAutoscaler (VPA) potrebbero interrompere la scalabilità automatica di tutti i workload in un cluster se contiene oggetti HPA autoscaling/v2 configurati in modo errato. Il problema interessa i cluster che eseguono versioni patch precedenti di GKE 1.27 e 1.28 (ad esempio, 1.27.3-gke.100). Soluzione temporanea: Correggi gli oggetti HPA autoscaling/v2 configurati in modo errato assicurandoti che i campi in spec.metrics.resource.target corrispondano, ad esempio: Quando spec.metrics.resource.target.type è Utilization, il target deve essere averageUtilization Quando spec.metrics.resource.target.type è AverageValue, il target deve essere averageValue Per maggiori dettagli su come configurare gli oggetti HPA autoscaling/v2, consulta la documentazione di Kubernetes su HorizontalPodAutoscaler.
Operazione	1.28,1.29	1.28.7-gke.1026000 1.29.2-gke.1060000	Deployment di Container Threat Detection non riuscito Il deployment di Container Threat Detection potrebbe non riuscire sui cluster Autopilot che eseguono le seguenti versioni di GKE: Da 1.28.6-gke.1095000 a 1.28.7-gke.1025000 Da 1.29.1-gke.1016000 a 1.29.1-gke.1781000
Networking, upgrade	1.27, 1.28, 1.29, 1.30	1.30.4-gke.1282000 o versioni successive 1.29.8-gke.1157000 o versioni successive 1.28.13-gke.1078000 o versioni successive 1.27.16-gke.1342000 o versioni successive	Problemi di connettività per i pod hostPort dopo l'upgrade del control plane I cluster con policy di rete abilitata potrebbero riscontrare problemi di connettività con i pod hostPort. Inoltre, i pod appena creati potrebbero richiedere altri 30-60 secondi per essere pronti. Il problema si verifica quando viene eseguito l'upgrade del control plane GKE di un cluster a una delle seguenti versioni di GKE Da 1.30 a 1.30.4-gke.1281999 Da 1.29.1-gke.1545000 a 1.29.8-gke.1156999 Da 1.28.7-gke.1042000 a 1.28.13-gke.1077999 Da 1.27.12-gke.1107000 a 1.27.16-gke.1341999 Soluzione temporanea: Esegui l'upgrade o ricrea i nodi immediatamente dopo l'upgrade del control plane GKE.
Networking	1.31, 1.32	1.32.1-gke.1729000 o versioni successive 1.31.6-gke.1020000 o versioni successive	Traffico UDP interrotto tra i pod in esecuzione sullo stesso nodo I cluster con visibilità tra nodi abilitata potrebbero riscontrare interruzioni del traffico UDP tra i pod eseguiti sullo stesso nodo. Il problema si verifica quando viene eseguito l'upgrade del nodo del cluster GKE o quando viene creato con una delle seguenti versioni di GKE: 1.32.1-gke.1729000 o versioni successive 1.31.6-gke.1020000 o versioni successive Il percorso interessato è il traffico UDP da pod a pod sullo stesso nodo tramite Hostport o Service. Risoluzione Esegui l'upgrade del cluster a una delle seguenti versioni corrette: 1.32.3-gke.1927000 o versioni successive 1.31.7-gke.1390000 o versioni successive
Operazione	1.29,1.30,1.31	1.29.10-gke.1071000 o versioni successive 1.30.5-gke.1723000 o versioni successive 1.31.2-gke.1115000 o versioni successive	Crittografia del database Cloud KMS e operatore Ray incompatibili Alcune versioni di Ray Operator non sono compatibili con la crittografia del database Cloud KMS. Soluzioni temporanee: Esegui l'upgrade del control plane del cluster a una versione corretta o successiva.
Upgrade e aggiornamenti	1.30, 1.31	1.30.8-gke.1051000 o versioni successive 1.31.1-gke.2008000 e versioni successive	Pod del gestore della manutenzione della GPU bloccato nello stato CrashLoopBackOff Con questo problema, i pod gpu-maintenance-handler sono bloccati in uno stato "CrashLoopBackOff" sui rispettivi nodi. Questo stato impedisce l'applicazione dell'etichetta "manutenzione imminente" ai nodi GKE, il che può influire sui processi di svuotamento dei nodi e di espulsione dei pod per i workload. "Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')" Se questo problema ti riguarda, puoi risolverlo eseguendo l'upgrade del control plane a una versione di GKE che include la correzione.
Operazione	1.33.1-gke.1522000 e versioni successive	1.33.4-gke.1142000 e versioni successive	Impossibile avviare i pod sui nodi con lo streaming di immagini abilitato Sui nodi con lo streaming di immagini abilitato, l'avvio dei workload potrebbe non riuscire con la seguente firma di errore: Failed to create pod sandbox ... context deadline exceeded I log della porta seriale di un nodo interessato contengono anche la seguente firma di errore: task gcfsd ... blocked for more than X seconds La presenza di queste due firme di errore indica un deadlock in uno dei componenti di Image Streaming. Questo deadlock impedisce ai pod di avviarsi correttamente. Mitigazione: Riavvia il nodo per una mitigazione rapida. Tieni presente che il nodo riavviato potrebbe comunque riscontrare nuovamente il deadlock. Per una mitigazione più efficace, disattiva lo streaming di immagini nel pool di nodi eseguendo questo comando: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming Nota: la disattivazione dello streaming di immagini ricrea tutti i nodi all'interno di un pool di nodi.
Operazione	1.32.4-gke.1198000 e versioni successive Versioni 1.33 precedenti alla 1.33.5-gke.1862000 Versioni 1.34 precedenti alla 1.34.1-gke.2541000	1.33.5-gke.1862000 e versioni successive 1.34.1-gke.2541000 e versioni successive	ComputeClass personalizzate con ImageType che non utilizzano i node pool GKE esistenti. Quando utilizzi una ComputeClass personalizzata che definisce un campo ImageType, il gestore della scalabilità automatica dei cluster crea e scala ripetutamente nuovi pool di nodi anziché scalare i pool di nodi esistenti. Lo stato di ComputeClass non è integro. Soluzione temporanea: Esegui l'upgrade del cluster a una delle seguenti versioni corrette: 1.33.5-gke.1862000 o versioni successive 1.34.1-gke.2541000 o versioni successive In alternativa, puoi mitigare questo problema non definendo determinati campi nella ComputeClass personalizzata. Se non utilizzi una ComputeClass personalizzata Autopilot, non definire il campo ImageType. In questo caso, il valore utilizzato è l'impostazione predefinita a livello di cluster, che per impostazione predefinita è cos_containerd. Se utilizzi una ComputeClass personalizzata di Autopilot, non definire il campo nodePoolConfig, che è un livello ImageType.

Passaggi successivi

• Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta Assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:

  • Aprire una richiesta di assistenza contattando l'assistenza clienti Google Cloud.
  • Ricevere assistenza dalla community facendo domande su StackOverflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per ricevere ulteriore assistenza dalla community.
  • Apertura di problemi o richieste di funzionalità utilizzando l'Issue Tracker pubblico.