Problemi noti relativi al networking di GKE

Questa pagina elenca i problemi noti relativi al networking di GKE. Questa pagina è rivolta agli amministratori e agli architetti che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base e rispondono agli avvisi e alle pagine quando gli obiettivi di livello del 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 problema:

Versioni identificate Versioni corrette Problema e soluzione alternativa
1.30, 1.31, 1.32 1.32.1-gke.1002000 e versioni successive

I nodi appena creati non vengono aggiunti ai bilanciatori del carico interni di livello 4

I Google Cloud bilanciatori del carico creati per i servizi LoadBalancer interni potrebbero non includere i nodi appena creati nel gruppo di istanze di backend.

Il problema sarà più visibile in un cluster che è stato scalato a zero nodi e poi riportato a uno o più nodi.

Soluzioni:

  • Attiva il sottoinsieme GKE e ricrea il servizio.

    Nota: il sottoinsieme GKE non può essere disattivato dopo l'attivazione.

  • Crea un altro servizio di bilanciamento del carico interno. Durante la sincronizzazione, verrà corretto anche il gruppo di istanze per il servizio interessato. Il nuovo servizio può essere rimosso dopo la sincronizzazione.
  • Aggiungi e poi rimuovi l'etichetta node.kubernetes.io/exclude-from-external-load-balancers da uno dei nodi.
  • Aggiungi un nodo al cluster. Puoi rimuovere il nodo dopo l'avvio del servizio.
1.27,1.28,1.29,1.30,1.31

Il controller NEG smette di gestire gli endpoint quando la porta viene rimossa dal servizio

Quando 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. In oltre ai servizi in cui l'utente crea un'annotazione NEG autonoma, questo influisce anche sui servizi a cui viene fatto riferimento da GKE Gateway, MCI e GKE Multi Cluster Gateway.

Soluzione:

Quando rimuovi una porta da un servizio con un'annotazione NEG autonoma, anche l'annotazione deve essere aggiornata per rimuovere la porta in questione.

1,28

Errore di configurazione TLS del gateway

Abbiamo identificato un problema con la configurazione di TLS per i gateway nei cluster che eseguono GKE versione 1.28.4-gke.1083000. Questo influisce sulle configurazioni TLS che utilizzano un SSLCertificate o un 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, non verrà eseguito il provisioning dei bilanciatori del carico. Questo problema verrà risolto in una futura versione della patch GKE 1.28.

1.27,1.28,1.29
  • 1.26.13-gke.1052000 e versioni successive
  • 1.27.10-gke.1055000 e versioni successive
  • 1.28.6-gke.1095000 e versioni successive
  • 1.29.1-gke.1016000 e versioni successive

Errori intermittenti di connessione

I cluster con il piano di controllo versione 1.26.6-gke.1900 e successive potrebbero riscontrare fallimenti intermittenti nell'instaurazione della connessione.

Le probabilità di errori sono ridotte e non interessano tutti i cluster. I fallimenti dovrebbero interrompersi completamente dopo alcuni giorni dall'inizio dei sintomi.

1.27,1.28,1.29
  • 1.27.11-gke.1118000 o versioni successive
  • 1.28.7-gke.1100000 o successive
  • 1.29.2-gke.1217000 o successive

Problemi di risoluzione DNS con Container-Optimized OS

I carichi di lavoro in esecuzione sui 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

Il criterio di rete interrompe una connessione a causa di una ricerca di monitoraggio delle connessioni errata

Per i cluster con il dataplane GKE 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 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 2 pod di backend, la connessione non riesce 50% delle volte.

Soluzione:

Puoi attenuare il problema configurando port e containerPort nel file manifest del servizio in modo che abbiano lo stesso valore.

1.27,1.28
  • 1.28.3-gke.1090000 o versioni successive
  • 1.27.11-gke.1097000 o versioni successive

Perdite di pacchetti per i flussi di connessione a tornanti

Per i cluster in cui è abilitato GKE Dataplane V2, quando un pod crea una connessione TCP con se stesso utilizzando un servizio, in modo che il pod sia sia la sorgente sia la destinazione della connessione, il monitoraggio delle connessioni eBPF di GKE Dataplane V2 monitora in modo errato gli stati di connessione, causando la fuga 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:

Utilizza una delle seguenti soluzioni alternative:

  • Attiva il riutilizzo TCP (keep-alive) per un'applicazione in esecuzione in un pod che potrebbe comunicare con se stessa utilizzando un servizio. In questo modo, viene impedito l'emissione del flag TCP FIN ed evitata la fuga della voce conntrack.
  • Quando utilizzi connessioni di breve durata, esponi il pod utilizzando un bilanciatore del carico del proxy, ad esempio Gateway, per esporre il servizio. Di conseguenza, la destinazione della richiesta di connessione viene impostata sull'indirizzo IP del bilanciatore del carico, impedendo a GKE Dataplane V2 di eseguire SNAT sull'indirizzo IP loopback.
Versioni precedenti a 1.31.0-gke.1506000 1.31.0-gke.1506000 e versioni successive

La rete digitata del dispositivo in GKE multi-network non riesce con nomi di rete lunghi

La creazione del cluster non riesce con il seguente errore:

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

Soluzione:

Limita la lunghezza dei nomi degli oggetti di rete di tipo dispositivo a un massimo di 41 caratteri. Viene composto il percorso completo di ogni socket di dominio UNIX, incluso il nome di rete corrispondente. Linux ha una limitazione per la lunghezza dei percorsi della socket (meno di 107 byte). Dopo aver tenuto conto della directory, del prefisso del nome file e dell'estensione .sock, il nome della rete è limitato a un massimo di 41 caratteri.
1,27, 1,28, 1,29, 1,30
  • 1.30.4-gke.1282000 o versioni successive
  • 1.29.8-gke.1157000 o 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 piano di controllo

I cluster con criterio di rete abilitato 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 piano di controllo GKE di un cluster a una delle seguenti versioni di GKE

  • 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:

Esegui l'upgrade o ricrea i nodi immediatamente dopo l'upgrade del piano di controllo GKE.
1.28, 1.29, 1.30, 1.31

Pod Calico non integri in cluster con meno di 3 nodi totali e vCPU insufficienti

I 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 criterio di rete abilitato. Ciò è dovuto a risorse CPU insufficienti.

Soluzioni:

  • Esegui la scalabilità a un minimo di 3 pool di nodi con 1 nodo che utilizza 1 vCPU allocabile.
  • Ridimensiona un singolo node pool a un minimo di 3 nodi con 1 vCPU allocatable.
  • Utilizza un tipo di macchina con almeno 2 vCPU allocabili in un pool di nodi con un singolo nodo.