Questa pagina elenca i problemi noti relativi al networking 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.
Per filtrare i problemi noti in base a una versione del prodotto, seleziona i filtri dai seguenti menu a discesa.
Seleziona la versione di GKE:
In alternativa, cerca il tuo problema:
| Versioni identificate | Versioni corrette | Problema e soluzione alternativa |
|---|---|---|
| 1,28, 1,29, 1,30, 1,31, 1,32, 1,33 |
Perdita dell'indirizzo IP del 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 del 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 il nodo del cluster GKE viene sottoposto ad upgrade o creato con una delle seguenti versioni di GKE:
Quando si verifica questo problema, i nuovi pod pianificati sul nodo interessato non vengono avviati e restituiscono un messaggio di errore simile al seguente: Soluzione temporanea: Per risolvere questo problema, puoi applicare il DaemonSet di mitigazione al cluster per pulire 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 il distacco 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 a questi bilanciatori del carico. Il problema interessa i cluster GKE che utilizzano una rete legacy e che eseguono la 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. Puoi farlo convertendo una rete legacy che contiene cluster GKE. Se al momento non riesci a 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 rilevare i nodi appena creati nel gruppo di istanza di backend. Il problema sarà più visibile su un cluster scalato a zero nodi e poi riportato a uno o più nodi. Soluzioni:
|
| 1.31,1.32 |
|
Problemi con l'API Gateway dovuti alla rimozione di storedVersions dallo stato di 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 finché il problema non viene risolto.
In alternativa, se devi eseguire l'upgrade della versione del cluster, devi aggiornare la versione di archiviazione di tutti i CRD dell'API Gateway interessati a
|
| 1.32 |
|
I nuovi pod non riescono a inizializzarsi e rimangono bloccati su ContainerCreating
I nuovi pod non vengono creati e rimangono 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 nelle versioni comprese tra 1.32 e precedenti alla 1.32.3-gke.1170000, creati nelle versioni 1.31 o 1.32 di GKE. La causa principale è che una struttura di dati in memoria che gestiva una raccolta di identità Cilium allocate non è stata 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 la registrazione è abilitata nel cluster GKE, il container resource.type="k8s_container" resource.labels.container_name="cilium-agent" Soluzione temporanea: Una soluzione temporanea è riavviare il control plane. A questo scopo, 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 smette di gestire gli 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 alla fine smetterà di gestire gli endpoint per il NEG. Oltre ai servizi in cui l'utente crea un'annotazione NEG autonoma, ciò influisce anche sui servizi a cui fanno riferimento GKE Gateway, MCI e GKE Multi Cluster Gateway. Soluzione temporanea: Quando rimuovi una porta da un servizio con un'annotazione NEG autonoma, l'annotazione deve essere aggiornata anche per rimuovere la porta in questione. |
|
| 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. |
|
| 1.27,1.28,1.29 |
|
Errori intermittenti di stabilimento della connessioneI cluster sulle 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. I malfunzionamenti dovrebbero cessare completamente dopo alcuni giorni dalla comparsa del sintomo. |
| 1.27,1.28,1.29 |
|
Problemi di risoluzione DNS con Container-Optimized OSI carichi di lavoro 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 |
Network Policy interrompe una connessione a causa di una ricerca di tracciamento delle connessioni 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 pass-through interno, il pacchetto di risposta non viene identificato come parte di una connessione esistente a causa di una ricerca conntrack errata nel piano dati. Ciò significa che un criterio di rete che limita il traffico in entrata per il pod viene applicato 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 risolvere 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 l'origine e la destinazione della connessione, il monitoraggio della connessione eBPF di GKE Dataplane V2 monitora in modo errato gli stati della connessione, causando la perdita di voci conntrack. Quando una tupla di connessione (protocollo, IP di origine/destinazione e porta di origine/destinazione) è stata compromessa, 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 digitata dal dispositivo in GKE multi-network non va a buon fine 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 sul dispositivo a un massimo di 41 caratteri. Il
percorso completo di ogni socket di dominio UNIX è composto, incluso il
nome di rete corrispondente. Linux ha una limitazione sulla lunghezza dei percorsi dei socket
(meno di 107 byte). Tenendo conto della directory, del prefisso del nome file e
dell'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 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:
|
| 1.28, 1.29, 1.30, 1.31 |
Pod Calico non integri su cluster con meno di 3 nodi totali e vCPU insufficientiI pod Calico-typha e calico-node non possono essere pianificati su cluster che soddisfano tutte le seguenti condizioni: meno di 3 nodi totali, ogni nodo con 1 o meno vCPU allocabili e policy di rete abilitata. Ciò è dovuto a risorse CPU insufficienti. Soluzioni:
|
|
Interruzioni del gateway multi-cluster (MCG) sui cluster di zona durante gli upgrade del control planeI deployment che utilizzano Multi-Cluster Gateway (MCG) sui cluster GKE di zona potrebbero subire interruzioni con errori `503` durante gli eventi che causano il riavvio del control plane, ad esempio un upgrade del cluster. Ciò si verifica perché MCG si basa su un meccanismo legacy per l'individuazione del gruppo di endpoint di rete (NEG) che segnala in modo errato zero backend quando i nodi di un cluster zonale diventano temporaneamente non disponibili durante il riavvio del control plane. In questo modo, il bilanciatore del carico rimuove tutti i backend, causando la perdita di traffico. Soluzioni:
|