Problemi noti relativi al networking di GKE

• 1.33.1-gke.1107000 e versioni successive

Interruzioni dei bilanciatori del carico Ingress e Service sui cluster con una rete legacy

Un'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 hanno 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:

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 non riesci a eseguire questa migrazione in questo momento, contatta l'assistenza clienti Google Cloud.

• 1.30.10-gke.1070000 e versioni successive
• 1.31.5-gke.1068000 e versioni successive
• 1.32.1-gke.1002000 e versioni successive

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

I bilanciatori del carico Trusted Cloud by S3NS 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:

• 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. Quando viene sincronizzato, anche il gruppo di istanze verrà corretto 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.

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

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

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. 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.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 stabilimento della connessione

I 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 guasti dovrebbero cessare completamente dopo alcuni giorni dalla comparsa del sintomo.

• 1.27.11-gke.1118000 o versioni successive
• 1.28.7-gke.1100000 o versioni successive
• 1.29.2-gke.1217000 o versioni successive

Problemi di risoluzione DNS con Container-Optimized OS

I carichi di lavoro in esecuzione su cluster GKE con nodi basati su Container-Optimized OS potrebbero riscontrare problemi di risoluzione DNS.

Network Policy interrompe una connessione a causa di una ricerca di tracciamento delle connessioni errata

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

Puoi risolvere questo problema configurando port e containerPort nel manifest del servizio in modo che abbiano lo stesso valore.

• 1.28.3-gke.1090000 o versioni successive
• 1.27.11-gke.1097000 o versioni successive

Pacchetti eliminati per i flussi di connessione hairpin

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

Utilizza una delle seguenti soluzioni alternative:

• Abilita il riutilizzo di TCP (keep-alive) per un'applicazione in esecuzione in un pod che potrebbe comunicare con se stessa utilizzando un servizio. In questo modo, il flag TCP FIN non viene emesso e si evita la perdita della voce conntrack.
• Quando utilizzi connessioni di breve durata, esponi il pod utilizzando un bilanciatore del carico 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 di loopback.

La rete digitata dal dispositivo in GKE multi-network non va a buon fine 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 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 .sock, il nome della rete è limitato a un massimo di 41 caratteri.

• 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 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 il control plane GKE di un cluster viene aggiornato 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
• 1.27.12-gke.1107000 a 1.27.16-gke.1341999

Soluzione:

Esegui l'upgrade o ricrea i nodi immediatamente dopo l'upgrade del control plane GKE.

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

• 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

Pod Calico non integri su 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 policy di rete abilitata. Ciò è dovuto a risorse CPU insufficienti.

Soluzioni:

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