Questa pagina elenca i problemi noti di GKE. Questa pagina è dedicata 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 raggiunti o le applicazioni non funzionano.
Questa pagina elenca i problemi noti per tutte le versioni supportate e per le due versioni secondarie che precedono immediatamente la prima versione nel supporto esteso. Quando una versione raggiunge la fine del supporto esteso, tutti i problemi N-2 vengono rimossi. Ad esempio, quando la versione 1.30 raggiunge la fine del supporto esteso, i problemi noti specifici delle versioni 1.28 e precedenti vengono rimossi.
Se fai parte del programma per sviluppatori Google, salva questa pagina per ricevere notifiche quando viene pubblicata una nota di rilascio correlata a questa pagina. Per scoprire di più, vedi Pagine salvate.
Per filtrare i problemi noti in base a una versione o categoria di prodotto, seleziona i filtri dai seguenti menu a discesa.
Seleziona la versione di GKE:
Seleziona la categoria del problema:
In alternativa, cerca il tuo problema:
| Categoria | Versioni identificate | Versioni corrette | Problema e soluzione alternativa |
|---|---|---|---|
| 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 dinamicoQuando viene eseguito il provisioning dinamico di un'istanza Lustre, la creazione dell'istanza non va a buon fine e viene visualizzato un errore Soluzione temporanea: Esegui l'upgrade del cluster GKE alla versione 1.33.4-gke.1036000 o successive. Se utilizzi il canale stabile, una versione più recente potrebbe non essere ancora disponibile. In questo caso, puoi selezionare manualmente una versione dai canali Regolare o Rapido che include la correzione. |
| Operazione |
|
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 FUSEQuando utilizzi una versione interessata del driver CSI di Cloud Storage FUSE, la ridenominazione o lo spostamento di file nei bucket Cloud Storage potrebbe non riuscire e generare un errore I/O. Soluzione temporanea: Aggiungi temporaneamente una definizione di immagine sidecar specifica al manifest del pod. Nella sezione # 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 ulteriori informazioni, consulta il manifest del pod in Configurare 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 |
| Logging e monitoraggio | Tutte le versioni | Da definire |
Race condition nei DaemonSet
|
| Upgrade | 1,33 | 1.33.2-gke.1043000 |
Limite di file aperti inferiore con containerd 2.0Per i pool di nodi che eseguono GKE versione 1.33, che utilizza containerd 2.0, il limite soft predefinito per i file aperti ( Si tratta di una modifica apportata a containerd (vedi PR #8924 di containerd) in cui I workload che prevedono un limite soft predefinito più elevato (ad esempio quelli che si basano implicitamente sul precedente limite predefinito più elevato) potrebbero riscontrare errori, ad esempio errori 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 carichi di lavoro utilizzando uno dei seguenti metodi:
|
| Upgrade | 1.31.5-gke.1169000, 1.32.1-gke.1376000 | 1.31.7-gke.1164000, 1.32.3-gke.1512000 |
Invalid CRD status.storedVersions for managed CRDsAlcune CRD gestite da GKE potrebbero avere un campo Questo problema interessa i cluster che soddisfano entrambe le seguenti condizioni:
Soluzione temporanea: La soluzione alternativa consigliata è ritardare gli upgrade del cluster finché il problema non viene risolto. In alternativa, se sai che il tuo cluster contiene versioni non supportate di
oggetti CRD, puoi aggiungere queste versioni al campo |
| Operazione, logging e monitoraggio | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
Metriche mancanti o scalabilità automatica del carico di lavoro non in scalabilitàPotresti notare lacune nei dati delle metriche nelle versioni interessate dopo l'aumento delle dimensioni del cluster 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 creati di recente dovrebbero funzionare come previsto. Soluzione temporanea: Se il problema ti riguarda, puoi eseguire il downgrade di una versione patch o l'upgrade alle versioni corrette più recenti. |
| Operazione |
Limiti di dimensioni e collegamento di Google Cloud HyperdiskIn 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 il workload non viene avviato 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 saperne di più, consulta Limiti di prestazioni di Hyperdisk. Soluzione temporanea: I prodotti Hyperdisk attivano il provisioning automatico su altre forme di VM. Ti consigliamo una forma che supporti solo Hyperdisk. |
||
| Operazione | 1.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 viene terminato per errore OOM sui nodi TPU/GPUSui nodi TPU (ad esempio Soluzione temporanea: Se osservi |
|
| Operazione |
|
|
Il ridimensionamento dei volumi potrebbe bloccarsi a causa dello stato NodePendingResize in sospeso sulle PVC.I cluster nella versione 1.32 con nodi nelle versioni 1.31 o precedenti non riusciranno ad aggiornare lo stato di PersistentVolumeClaim durante il ridimensionamento. Questo stato errato impedisce l'inizio delle successive operazioni di ridimensionamento, impedendo di fatto ulteriori ridimensionamenti. Un PVC in questo stato ha un campo Se è stato creato un PVC mentre il cluster utilizzava una versione interessata, potresti notare che il problema persiste anche dopo l'upgrade del cluster a una versione corretta nota. In questo scenario, la PVC deve essere patchata per rimuovere il campo Soluzione temporanea: Le PVC bloccate a causa dello stato sospeso possono essere patchate per rimuovere questo stato. Puoi utilizzare un comando patch come il seguente per rimuovere lo stato sospeso: 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 |
|
|
Il driver PDCSI potrebbe registrare un numero eccessivo di logI cluster GKE su versioni specifiche di 1.32 potrebbero emettere un numero eccessivo di messaggi di log dal driver PDCSI. Questo logging in eccesso 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 |
|
|
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à ROPer 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 precedente montaggio RO sullo stesso nodo. Soluzione temporanea: Esegui il downgrade dei node pool a una versione precedente a quelle interessate. |
| Operazioni |
|
|
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 questi casi, 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" 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.1302000 |
|
I pod che utilizzano chiamate di sistema correlate a io_uring potrebbero bloccarsi in stato di terminazione
I pod che utilizzano chiamate di sistema correlate a io_uring potrebbero entrare nello stato D (disk sleep), chiamato anche TASK_UNINTERRUPTIBLE, a causa di un bug nel kernel Linux. I processi nello stato D non possono essere riattivati dai segnali, incluso
Quando un pod è interessato da questo problema noto, i relativi container potrebbero non terminare normalmente. Nei log di containerd, potresti notare messaggi ripetuti simili al seguente:
o
Questi sintomi indicano che i processi all'interno del container sono bloccati in uno stato di sospensione non interrompibile (stato D), il che impedisce la corretta terminazione del pod.
I carichi di lavoro che utilizzano io_uring direttamente o indirettamente tramite un runtime del linguaggio come NodeJS potrebbero essere interessati da questo problema noto. I carichi di lavoro interessati hanno un processo nello stato D (sospensione del disco) nel file Soluzione temporanea: Esegui l'upgrade dei nodi del cluster a una versione corretta o successiva. |
| Operazione | 1.28, 1.29, 1.30, 1.31 |
|
I workload che utilizzano lo streaming di immagini non riescono a eseguire l'autenticazione e generano erroriUn bug nella funzionalità di streaming delle immagini potrebbe causare l'errore dei carichi di lavoro quando viene soddisfatto un insieme di condizioni specifiche durante la lettura dei file da parte del container. Nel log gcfsd potrebbero essere visibili messaggi di errore relativi a errori di autenticazione.
Per verificare se il tuo account è interessato, cerca nei log con questa query di ricerca:
La presenza di questi errori indica che i nodi sono interessati. Se il problema ti riguarda, puoi eseguire l'upgrade dei tuoi pool di nodi a una versione GKE con patch. |
| Operazione |
|
|
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
L'opzione di configurazione Potresti non vedere sempre un tasso di espulsione dei pod insolito perché questo problema dipende dal pattern di utilizzo della memoria del workload. Esiste un rischio maggiore che kubelet elimini i pod per i workload che non hanno impostato un limite di memoria nel campo delle risorse. Questo perché i carichi di lavoro potrebbero richiedere più memoria di quella segnalata da kubelet come disponibile. Se noti un maggiore utilizzo della memoria di un'applicazione dopo l'upgrade alle versioni di GKE menzionate senza altre modifiche, potresti essere interessato dall'opzione del kernel.
Per verificare se i tassi di espulsione dei pod sono insoliti, analizza le seguenti metriche con
Esplora metriche:
Puoi utilizzare le seguenti query PromQL. Sostituisci i valori di
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 nell'utilizzo della memoria che superano la memoria richiesta, il workload potrebbe essere rimosso più spesso. Soluzione alternativaSe non puoi eseguire l'upgrade alle versioni corrette e se esegui l'applicazione in un ambiente GKE in cui puoi eseguire il deployment di pod con privilegi, puoi disattivare l'opzione LRU multigen utilizzando un DaemonSet.
Una volta che il DaemonSet è in esecuzione in tutti i pool di nodi selezionati, la modifica è immediatamente effettiva e il calcolo dell'utilizzo della memoria di kubelet torna alla normalità. |
| Operazione | 1.28, 1.29, 1.30, 1.31 |
|
Pod bloccati nello stato TerminatingUn bug nel runtime del container (containerd) potrebbe causare il blocco di pod e 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 corretta di containerd. |
| Operazione | 1.28,1.29 |
|
Lo streaming delle immagini non riesce a causa di link simboliciUn bug nella funzionalità di streaming delle immagini potrebbe impedire l'avvio dei container. I container in esecuzione su un nodo con lo streaming delle immagini abilitato su versioni GKE specifiche potrebbero non essere creati 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"
Se il problema ti riguarda, puoi controllare 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 |
|
Lo streaming delle immagini non riesce a causa di file mancantiUn bug nella funzionalità di streaming delle immagini potrebbe causare errori nei 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. Di seguito sono riportati alcuni esempi di questi errori:
Se riscontri questo problema, puoi disattivare lo streaming delle immagini. |
| Networking,aggiornamenti e update | 1,28 |
Errore di configurazione TLS del gatewayAbbiamo identificato un problema con la 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 andranno a buon fine. Per i nuovi gateway, i bilanciatori del carico non verranno di cui è stato eseguito il provisioning. 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 vengono aggiornati dalla versione 1.26 a una versione patch 1.27 precedente alla 1.27.8 potrebbero riscontrare problemi con i plug-in del dispositivo GPU dei nodi (
|
| Operazione | 1.27,1.28 |
|
La scalabilità automatica per tutti i workload si interrompe
HorizontalPodAutoscaler (HPA) e VerticalPodAutoscaler (VPA) potrebbero
interrompere la scalabilità automatica di tutti i carichi di lavoro in un cluster se contiene
oggetti HPA Soluzione temporanea:
Correggi gli oggetti HPA
Per ulteriori dettagli su come configurare gli oggetti HPA |
| Operazione | 1.28,1.29 |
|
Il deployment di Container Threat Detection non riesceIl deployment di Container Threat Detection potrebbe non riuscire nei cluster Autopilot che eseguono le seguenti versioni di GKE:
|
| Networking, aggiornamenti | 1.27, 1.28, 1.29, 1.30 |
|
Problemi di connettività per i pod
|
| Networking | 1.31, 1.32 |
|
Traffico UDP interrotto tra i pod in esecuzione sullo stesso nodoI cluster con la visibilità tra nodi abilitata potrebbero riscontrare un traffico UDP interrotto tra i pod in esecuzione sullo stesso nodo. Il problema si verifica quando il nodo del cluster GKE viene sottoposto ad upgrade o creato con una delle seguenti versioni di GKE:
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:
|
| Operazione | 1.29,1.30,1.31 |
|
Operatore Ray e crittografia del database Cloud KMS incompatibiliAlcune versioni di Ray Operator non sono compatibili con la crittografia del database Cloud KMS. Soluzioni: Esegui l'upgrade del control plane del cluster a una versione corretta o successiva. |
| Upgrade e aggiornamenti | 1.30, 1.31 |
|
Pod del gestore della manutenzione della GPU bloccato nello stato CrashLoopBackOffCon questo problema, i pod gpu-maintenance-handler sono bloccati nello stato `CrashLoopBackOff` sui rispettivi nodi. Questo stato impedisce l'applicazione dell'etichetta "manutenzione imminente" ai nodi GKE, il che può influire sia sui processi di svuotamento dei nodi che 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 riscontri questo problema, 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 |
I pod non vengono avviati 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:
I log della porta seriale di un nodo interessato contengono anche la seguente firma di errore:
La presenza di queste due firme di errore indica un deadlock in uno dei componenti di streaming delle immagini. Questo deadlock impedisce l'avvio corretto dei pod. Mitigazione: Riavvia il nodo per una mitigazione rapida. Tieni presente che il nodo riavviato potrebbe comunque riscontrare di nuovo il deadlock. Per una mitigazione più efficace, disattiva lo streaming di immagini sul pool di nodi eseguendo questo comando: gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
Passaggi successivi
Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedere assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:
- Aprire una richiesta di assistenza contattando l'assistenza clienti cloud.
- Ricevere assistenza dalla community
ponendo domande su StackOverflow e utilizzando il tag
google-kubernetes-engineper cercare problemi simili. Puoi anche unirti al canale Slack#kubernetes-engineper ulteriore assistenza della community. - Apertura di bug o richieste di funzionalità utilizzando lo strumento di monitoraggio dei problemi pubblico.