In questa pagina sono elencati i problemi noti relativi al networking 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.
Per filtrare i problemi noti in base a una versione del prodotto, seleziona i filtri dai seguenti menu a discesa.
Seleziona la tua versione di GKE:
In alternativa, cerca il problema:
| Versioni identificate | Versione/i corretta/e | Problema e soluzione alternativa |
|---|---|---|
| 1,36 | Correzione in corso |
Errori di connettività e pod di sistema in crash loop sui nodi Windows che utilizzano bilanciatori del carico di livello 4I cluster GKE con pool di nodi Windows Server che eseguono la versione 1.36 potrebbero riscontrare uno dei seguenti problemi:
Questo problema si verifica quando i cluster utilizzano bilanciatori del carico interni di livello 4 senza GKE Subsetting o bilanciatori del carico di rete passthrough esterni che utilizzano pool di destinazione o gruppi di istanze meno recenti. In GKE 1.36, l'agente guest di Compute Engine attiva Soluzione temporanea: Per mitigare questo problema, utilizza uno dei seguenti metodi:
|
| Grafico Helm InferencePool v1.1.0 |
InferencePool Flag targetPortNumber ignoratoNella versione Soluzione temporanea: Verifica la porta dopo l'installazione: kubectl get inferencepool POOL_NAME -o jsonpath='{.spec.targetPorts}' \ --context=CLUSTER_CONTEXT Se la porta non è corretta, applica una patch alla risorsa personalizzata kubectl patch inferencepool POOL_NAME --type=merge \ -p '{"spec":{"targetPorts":[{"number":TARGET_PORT}]}}' \ --context=CLUSTER_CONTEXT |
|
| 1.33, 1.34, 1.35 |
|
Connettività dei pod intermittente o errori DNS dovuti all'eliminazione di
|
| 1.29, 1.30, 1.31, 1.32, 1.33 | 1,34 |
Il container
|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
Perdita di indirizzi IP dei pod sui nodi con GKE Dataplane V2I cluster con GKE Dataplane V2 abilitato potrebbero riscontrare l'esaurimento degli indirizzi IP dei pod sui nodi. Questo problema è causato da un bug del runtime dei container che può causare la perdita di indirizzi IP allocati quando i pod riscontrano errori CNI temporanei durante la creazione. 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:
Quando si verifica questo problema, i nuovi pod pianificati sul nodo interessato non si avviano e restituiscono un messaggio di errore simile al seguente: Soluzione temporanea: Per attenuare questo problema, puoi applicare il DaemonSet di mitigazione al cluster per ripulire le risorse IP trapelate: apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31, 1.32, 1.33 |
|
Interruzioni dei bilanciatori del carico Ingress e Service sui cluster con una rete legacyUn'incompatibilità con le reti legacy causa lo scollegamento dei backend di un bilanciatore del carico gestito da GKE di cui è stato eseguito il deployment utilizzando Ingress o Service. Di conseguenza, il bilanciatore del carico non ha backend attivi, il che a sua volta comporta l'eliminazione di tutte le richieste in entrata verso questi bilanciatori del carico. Il problema interessa i cluster GKE che utilizzano una rete legacy e sono nella versione 1.31 o successive. Per identificare i cluster GKE con una rete legacy, esegui questo comando:
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"
Un cluster con una rete legacy riceverà un output vuoto per questo comando. Soluzione temporanea: Poiché le reti legacy sono state ritirate da tempo, la soluzione preferita è eseguire la migrazione della rete legacy a una rete VPC. Per farlo, converti una rete legacy contenente cluster GKE. Se al momento non puoi eseguire questa migrazione, contatta l'assistenza clienti Google Cloud. |
| 1.30, 1.31, 1.32 |
|
I nodi appena creati non vengono aggiunti ai bilanciatori del carico interni di livello 4I bilanciatori del carico Google Cloud creati per i servizi LoadBalancer interni potrebbero non includere i nodi appena creati nel gruppo di istanza di backend. Il problema sarà più visibile su un cluster che è stato scalato a zero nodi e poi riportato a uno o più nodi. Soluzioni temporanee:
|
| 1.31,1.32 |
|
Problemi con l'API Gateway dovuti alla rimozione di storedVersions dallo stato CRD
Kube-Addon-Manager in GKE rimuove erroneamente Il tuo cluster potrebbe essere a rischio se soddisfa tutte le seguenti condizioni:
Soluzione temporanea: La soluzione alternativa consigliata è ritardare gli upgrade del cluster fino alla risoluzione del problema.
In alternativa, se devi eseguire l'upgrade della versione del cluster, devi aggiornare la versione di archiviazione per tutte le CRD dell'API Gateway interessate a
|
| 1.32 |
|
Impossibile inizializzare i nuovi pod bloccati su ContainerCreating
La creazione di nuovi pod non va a buon fine e i pod rimangono bloccati nello stato Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded Il problema interessa i cluster GKE con versioni comprese tra 1.32 e precedenti alla 1.32.3-gke.1170000, create con le versioni GKE 1.31 o 1.32. La causa principale è che una struttura di dati in memoria che gestiva una raccolta di identità Cilium allocate non era sincronizzata correttamente con lo stato del server API Kubernetes.
Per confermare la versione di GKE utilizzata per creare il cluster, puoi eseguire una query sulla risorsa gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
Se nel cluster GKE è abilitato il logging, il container resource.type="k8s_container" resource.labels.container_name="cilium-agent" Soluzione temporanea: Una mitigazione temporanea consiste nel riavviare il control plane. Per farlo, esegui l'upgrade del control plane alla stessa versione già in esecuzione: gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 1.27,1.28,1.29,1.30,1.31 |
Il controller NEG interrompe la gestione degli endpoint quando la porta viene rimossa dal servizioQuando il controller NEG è configurato per creare un NEG autonomo per un servizio e una delle porte configurate viene successivamente rimossa dal servizio, il controller NEG smetterà di gestire gli endpoint per il NEG. Oltre ai servizi in cui l'utente crea un'annotazione NEG autonomo, questo influisce anche sui servizi a cui fanno riferimento il gateway GKE, MCI e il gateway multi-cluster GKE. Soluzione temporanea: Quando rimuovi una porta da un servizio con un'annotazione NEG autonomo, l'annotazione deve essere aggiornata anche per rimuovere la porta in questione. |
|
| 1,28 |
Errore di configurazione TLS del gatewayAbbiamo 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. |
|
| 1.27,1.28,1.29 |
|
Errori intermittenti di stabilimento della connessioneI cluster con versioni del control plane 1.26.6-gke.1900 e successive potrebbero riscontrare errori intermittenti di stabilimento della connessione. Le probabilità di errori sono basse e non interessano tutti i cluster. Gli errori dovrebbero interrompersi completamente dopo alcuni giorni dall'insorgenza del sintomo. |
| 1.27,1.28,1.29 |
|
Problemi di risoluzione DNS con Container-Optimized OSI workload in esecuzione su cluster GKE con nodi basati su Container-Optimized OS potrebbero riscontrare problemi di risoluzione DNS. |
| 1,28 | 1.28.3-gke.1090000 o versioni successive |
La policy di rete interrompe una connessione a causa di una ricerca di monitoraggio della connessione errataPer i cluster con GKE Dataplane V2 abilitato, quando un pod client si connette a se stesso utilizzando un servizio o l'indirizzo IP virtuale di un bilanciatore del carico di rete passthrough interno, il pacchetto di risposta non viene identificato come parte di una connessione esistente a causa di una ricerca conntrack errata nel dataplane. Ciò significa che una policy di rete che limita il traffico in entrata per il pod viene applicata in modo errato al pacchetto. L'impatto di questo problema dipende dal numero di pod configurati per il servizio. Ad esempio, se il servizio ha un pod di backend, la connessione non riesce sempre. Se il servizio ha due pod di backend, la connessione non riesce il 50% delle volte. Soluzione temporanea:
Puoi mitigare questo problema configurando |
| 1.27,1.28 |
|
Pacchetti eliminati per i flussi di connessione hairpinPer i cluster con GKE Dataplane V2 abilitato, quando un pod crea una connessione TCP a se stesso utilizzando un servizio, in modo che il pod sia sia l'origine sia la destinazione della connessione, il monitoraggio della connessione eBPF di GKE Dataplane V2 monitora in modo errato gli stati della connessione, causando voci conntrack con leak. Quando è stata divulgata una tupla di connessione (protocollo, IP di origine/destinazione e porta di origine/destinazione), le nuove connessioni che utilizzano la stessa tupla di connessione potrebbero comportare l'eliminazione dei pacchetti di ritorno. Soluzione temporanea: Utilizza una delle seguenti soluzioni alternative:
|
| Precedente alla versione 1.31.0-gke.1506000 | 1.31.0-gke.1506000 e versioni successive |
La rete di tipo dispositivo in GKE multi-rete non funziona con nomi di rete lunghiLa creazione del cluster non riesce con il seguente errore:
Soluzione temporanea: Limita la lunghezza dei nomi degli oggetti di rete digitati dal dispositivo a un massimo di 41 caratteri. Viene composto il percorso completo di ogni socket di dominio UNIX, incluso il nome della rete corrispondente. Linux ha una limitazione per le lunghezze dei percorsi dei socket (meno di 107 byte). Dopo aver preso in considerazione la directory, il prefisso del nome file e l'estensione |
| 1.27, 1.28, 1.29, 1.30 |
|
Problemi di connettività per i pod
|
| 1.31, 1.32 |
|
Traffico UDP interrotto tra i pod in esecuzione sullo stesso nodoI cluster con visibilità tra nodi abilitata potrebbero riscontrare un'interruzione 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:
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.28, 1.29, 1.30, 1.31 |
Pod Calico non integri su cluster con meno di 3 nodi totali e vCPU insufficienteI pod calico-typha e calico-node non possono essere pianificati su cluster che soddisfano tutte le seguenti condizioni: meno di 3 nodi in totale, ogni nodo con 1 o meno vCPU allocabili e policy di rete abilitata. Ciò è dovuto a risorse CPU insufficienti. Soluzioni temporanee:
|
|
Interruzioni del gateway multi-cluster (MCG) sui cluster di zona durante gli upgrade del control planeI deployment che utilizzano il gateway multi-cluster (MCG) sui cluster GKE a livello di zona potrebbero subire interruzioni con errori "503" durante eventi che causano il riavvio del control plane, ad esempio un upgrade del cluster. Questo accade perché MCG si basa su un meccanismo legacy per il rilevamento dei gruppi di endpoint di rete (NEG) che segnala erroneamente zero backend quando i nodi di un cluster di zona diventano temporaneamente non disponibili durante il riavvio del control plane. In questo modo, il bilanciatore del carico rimuove tutti i backend, con conseguente perdita di traffico. Soluzioni temporanee:
|
||
Race condition del gate di idoneità del NEGIn determinate condizioni, i controlli di idoneità potrebbero restituire un "falso positivo" dello stato di idoneità, prima che il controllo di integrità dell'oggetto Ingress segnali uno stato integro, generando eventi di errore come i seguenti sull'oggetto Ingress:
Questo problema fa sì che il bilanciatore del carico segnali un errore La presenza di un numero relativamente ridotto di pod (ad esempio 2) rispetto al numero di NEG aumenta il rischio di questa race condition. I NEG vengono creati per ogni regione, con un NEG per zona, il che in genere si traduce in tre NEG. Se il numero di pod è relativamente elevato, in modo che ogni NEG abbia sempre più pod prima dell'inizio dell'aggiornamento in sequenza, è molto improbabile che si verifichi questa race condition. Soluzione temporanea: Il modo migliore per evitare questa race condition è avere più backend nel gruppo di endpoint di rete. Assicurati che la strategia di aggiornamento in sequenza sia configurata in modo da garantire che almeno un pod sia sempre in esecuzione. Ad esempio, se solo 2 pod vengono eseguiti normalmente, una configurazione di esempio potrebbe essere simile alla seguente: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 0 maxSurge: 1 L'esempio precedente è un suggerimento. Devi aggiornare la strategia in base a diversi fattori, ad esempio il numero di repliche. |
||
Garbage collection incompleta dei bilanciatori del carico nativi dei containerGKE esegue la garbage collection dei bilanciatori del carico nativi dei container ogni due minuti. Se un cluster viene eliminato prima che i bilanciatori del carico vengano rimossi completamente, devi eliminare manualmente i NEG del bilanciatore del carico. Soluzione temporanea: Visualizza i NEG nel tuo progetto eseguendo questo comando: gcloud compute network-endpoint-groups list Nell'output comando, cerca i NEG pertinenti. Per eliminare un NEG, esegui il seguente comando, sostituendo gcloud compute network-endpoint-groups delete <var>NEG_NAME</var> |
||
Allinea i rollout dei workload con la propagazione degli endpointQuesto problema non si verifica nei cluster che utilizzano il feedback di idoneità dei pod per gestire i rollout dei workload. Quando esegui il deployment di un workload nel cluster o quando aggiorni un workload esistente, il bilanciatore del carico nativo del container può impiegare più tempo per propagare i nuovi endpoint rispetto al tempo necessario per completare l'implementazione del workload. Soluzione temporanea: Configura i valori
|
||
initialDelaySeconds in readinessProbe del pod non rispettatoPotresti aspettarti che la configurazione |