GKE Dataplane V2

Questa pagina fornisce una panoramica di cosa fa e come funziona GKE Dataplane V2.

Prima di leggere questa pagina, assicurati di conoscere la networking all'interno dei cluster GKE.

Panoramica di GKE Dataplane V2

GKE Dataplane V2 è un piano dati ottimizzato per la rete Kubernetes. GKE Dataplane V2 fornisce:

  • Un'esperienza utente coerente per il networking.
  • Visibilità in tempo reale dell'attività di rete.
  • Un'architettura più semplice che semplifica la gestione e la risoluzione dei problemi dei cluster.

GKE Dataplane V2 è abilitato per impostazione predefinita per tutti i nuovi cluster Autopilot.

Come funziona GKE Dataplane V2

GKE Dataplane V2 viene implementato utilizzando eBPF. Quando i pacchetti arrivano a un nodo GKE, i programmi eBPF installati nel kernel decidono come inoltrarli ed elaborarli. A differenza dell'elaborazione dei pacchetti con iptables, i programmi eBPF possono utilizzare metadati specifici di Kubernetes nel pacchetto. In questo modo, GKE Dataplane V2 può elaborare i pacchetti di rete nel kernel in modo più efficiente e segnalare le azioni annotate allo spazio utente per il logging.

Il seguente diagramma mostra il percorso di un pacchetto attraverso un nodo che utilizza GKE Dataplane V2:

Il percorso di un pacchetto attraverso un nodo che utilizza GKE Dataplane V2.

GKE esegue il deployment del controller GKE Dataplane V2 come DaemonSet chiamato anetd su ogni nodo del cluster. anetd interpreta gli oggetti Kubernetes e programma le topologie di rete in eBPF. I pod anetd vengono eseguiti nello spazio dei nomi kube-system.

GKE Dataplane V2 e NetworkPolicy

GKE Dataplane V2 viene implementato utilizzando Cilium. Il dataplane legacy per GKE è implementato utilizzando Calico.

Entrambe queste tecnologie gestiscono NetworkPolicy di Kubernetes. Cilium utilizza eBPF e l'interfaccia CNI (Container Network Interface) di Calico utilizza iptables nel kernel Linux.

Vantaggi di GKE Dataplane V2

Scalabilità

GKE Dataplane V2 ha caratteristiche di scalabilità diverse rispetto al piano dati precedente.

Per le versioni di GKE in cui GKE Dataplane V2 non utilizza kube-proxy e non si basa su iptables per il routing dei servizi, GKE rimuove alcuni colli di bottiglia correlati a iptables, ad esempio il numero di servizi.

GKE Dataplane V2 si basa su mappe eBPF limitate a 260.000 endpoint in tutti i servizi.

Sicurezza

Il criterio di rete Kubernetes è sempre attivo nei cluster con GKE Dataplane V2. Per applicare i criteri di rete, non è necessario installare e gestire componenti aggiuntivi software di terze parti come Calico.

Operazioni

Quando crei un cluster con GKE Dataplane V2, il logging dei criteri di rete è integrato. Configura il record CRD di logging sul tuo cluster per vedere quando le connessioni sono consentite e negate dai pod.

Coerenza

GKE Dataplane V2 offre un'esperienza di networking coerente.

Per ulteriori informazioni, consulta Disponibilità di GKE Dataplane V2.

Specifiche tecniche di GKE Dataplane V2

GKE Dataplane V2 supporta i cluster con le seguenti specifiche:

Specifica GKE Google Distributed Cloud Edge Google Distributed Cloud Hosted
Numero di nodi per cluster 7.500 500 500
Numero di pod per cluster 200.000 15.000 27.500
Numero di pod dietro un servizio 10.000 1000 1000
Numero di servizi ClusterIP 10.000 1000 1000
Numero di servizi LoadBalancer per cluster 750 500 1000

GKE Dataplane V2 gestisce una mappa dei servizi per tenere traccia di quali servizi fanno riferimento a quali pod come backend. Il numero di backend del pod per ogni servizio sommato tra tutti i servizi deve essere compreso nella mappa dei servizi, che può contenere fino a 260.000 voci. Se questo limite viene superato, il cluster potrebbe non funzionare come previsto.

Aumento del limite di nodi a 7500 nella versione 1.31

A partire dalle versioni 1.31 di Kubernetes, il limite di 5000 nodi per cluster GKE Dataplane V2 è stato aumentato a 7500. Si applicano ancora le condizioni precedentemente imposte ai cluster (limite di 5000 nodi).

Aumento del limite di nodi a 5000 nella versione 1.23

A partire dalle versioni 1.23 di Kubernetes, il limite di 500 nodi per cluster GKE Dataplane V2 è stato aumentato a 5000, con le seguenti condizioni aggiuntive imposte ai cluster:

  • Cluster che utilizzano Private Service Connect. Per verificare se il tuo cluster utilizza Private Service Connect, consulta Cluster con Private Service Connect.
  • Solo cluster a livello di regione
  • Solo i cluster creati con GKE 1.23 o versioni successive hanno un limite di 5000 nodi aumentato. I cluster creati con versioni precedenti di GKE potrebbero richiedere l'aumento di una quota di dimensioni del cluster. Contatta l'assistenza per ricevere aiuto.
  • I cluster che utilizzano i CRD di Cilium (CiliumNetworkPolicy e CiliumClusterwideNetworkPolicy) non possono scalare fino a 5000 nodi.

Servizi LoadBalancer in Google Distributed Cloud

Il numero di servizi LoadBalancer supportati in Google Distributed Cloud dipende dalla modalità del bilanciatore del carico in uso. Google Distributed Cloud supporta 500 servizi LoadBalancer se utilizzi la modalità di bilanciamento del carico in bundle (Seesaw) e 250 se utilizzi la modalità di bilanciamento del carico integrata con F5. Per ulteriori informazioni, consulta la sezione Scalabilità.

Limitazioni

GKE Dataplane V2 presenta le seguenti limitazioni:

  • GKE Dataplane V2 può essere attivato solo durante la creazione di un nuovo cluster. Non è possibile eseguire l'upgrade dei cluster esistenti per utilizzare GKE Dataplane V2.
  • Nelle versioni di GKE precedenti alla 1.20.12-gke.500, se attivi GKE Dataplane V2 con NodeLocal DNSCache, non puoi configurare i pod con dnsPolicy: ClusterFirstWithHostNet, altrimenti i pod riscontreranno errori di risoluzione DNS.
  • A partire dalla versione GKE 1.21.5-gke.1300, GKE Dataplane V2 non supporta le API CRD CiliumNetworkPolicy o CiliumClusterwideNetworkPolicy. A partire dalle versioni GKE 1.28.6-gke.1095000 e 1.29.1-gke.1016000, puoi abilitare CiliumClusterwideNetworkPolicy su cluster nuovi o esistenti.
  • I bilanciatori del carico di rete passthrough interni creati manualmente associati a un servizio di tipo NodePort non sono supportati.
  • Poiché GKE Dataplane V2 ottimizza l'elaborazione dei pacchetti del kernel eBPF utilizzando eBPF, le prestazioni dei pod potrebbero essere interessate se i tuoi workload presentano un elevato turnover dei pod. L'obiettivo principale di GKE Dataplane V2 è ottenere un eBPF ottimale.
  • Esiste un problema noto con i servizi multi-cluster con più porte (TCP/UDP) su GKE Dataplane V2. Per ulteriori informazioni, consulta Servizi MCS con più porte.
  • GKE Dataplane V2 utilizza cilium anziché kube-proxy per implementare i servizi Kubernetes. kube-proxy è gestito e sviluppato dalla community Kubernetes, pertanto è più probabile che le nuove funzionalità per i servizi vengano implementate in kube-proxy prima che vengano implementate in cilium per GKE Dataplane V2. Un esempio di funzionalità di Servizi implementata per la prima volta in kube-proxy è KEP-1669: endpoint di terminazione proxy.
  • Per i servizi NodePort che eseguono la versione 1.25 o precedente e utilizzano gli intervalli SNAT e PUPI predefiniti, devi aggiungere l'intervallo PUPI dei pod in nonMasqueradeCIDRs nel ConfigMap ip-masq-agent per evitare problemi di connettività.
  • In alcuni casi, i pod dell'agente GKE Dataplane V2 (anetd) possono consumare una quantità significativa di risorse CPU, fino a due o tre vCPU per istanza. Questo si verifica quando sul nodo viene aperto e chiuso rapidamente un volume elevato di connessioni TCP. Per attenuare questo problema, consigliamo di implementare i keep-alive per le chiamate HTTP e il pool di connessioni per i carichi di lavoro pertinenti.
  • I cluster GKE Dataplane V2 che eseguono la versione del piano di controllo 1.27 o precedente non supportano il campo Servizio .spec.internalTrafficPolicy. Il criterio di traffico interno effettivo per un servizio è Cluster; i backend su qualsiasi nodo sono considerati candidati per la risoluzione del servizio. Per ulteriori informazioni sul campo, consulta le norme relative al traffico interno del servizio.
  • GKE Dataplane V2 utilizza eBPF per gestire il traffico di rete del cluster. Se installi un'applicazione di terze parti che utilizza anche eBPF, potrebbe interferire con GKE Dataplane V2. Ad esempio, l'utilizzo di Retina con GKE Dataplane V2 può impedire ai pod di connettersi ai servizi. Questo accade perché i programmi eBPF di Retina possono interrompere il modo in cui GKE Dataplane V2 instrada il traffico. Se visualizzi messaggi di errore che indicano che il traffico viene interrotto perché sta tentando di raggiungere direttamente l'indirizzo IP del servizio, potresti riscontrare questo problema. Questo perché i pod non sono autorizzati ad accedere direttamente all'indirizzo IP del servizio e il traffico deve passare attraverso i meccanismi di routing di Dataplane V2. Per ulteriori informazioni, consulta Problemi di incompatibilità con Retina.

GKE Dataplane V2 e kube-proxy

GKE Dataplane V2 non utilizza kube-proxy tranne che nei node pool Windows Server nelle versioni GKE 1.25 e precedenti.

Applicazione dei criteri di rete senza GKE Dataplane V2

Consulta Utilizzare l'applicazione dei criteri di rete per istruzioni su come attivare l'applicazione dei criteri di rete nei cluster che non utilizzano GKE Dataplane V2.

Passaggi successivi