GKE Dataplane V2

Questa pagina offre una panoramica delle funzionalità e del funzionamento di GKE Dataplane V2.

Prima di leggere questa pagina, è bene che tu abbia compreso il networking all'interno dei cluster GKE.

Panoramica di GKE Dataplane V2

GKE Dataplane V2 è un piano dati ottimizzato per il networking Kubernetes. GKE Dataplane V2 fornisce:

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

GKE Dataplane V2 è abilitato per tutti i nuovi cluster Autopilot nelle versioni 1.22.7-gke.1500 e successive, 1.23.4-gke.1500 e successive e per tutte le versioni 1.24 e successive.

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 instradare ed elaborare i pacchetti. A differenza dell'elaborazione dei pacchetti con iptables, i programmi eBPF possono utilizzare metadati specifici di Kubernetes nel pacchetto. Ciò consente a GKE Dataplane V2 di elaborare i pacchetti di rete nel kernel in modo più efficiente e di segnalare le azioni annotate nello spazio utente per il logging.

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

GKE esegue il deployment del controller GKE Dataplane V2 come DaemonSet denominato anetd su ciascun 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 viene implementato utilizzando Calico.

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

Vantaggi di GKE Dataplane V2

Scalabilità

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

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 che hanno un limite di 64.000 endpoint in tutti i servizi.

Sicurezza

Kubernetes NetworkPolicy è sempre attivo nei cluster con GKE Dataplane V2. Non è necessario installare e gestire componenti aggiuntivi software di terze parti come Calico per applicare i criteri di rete.

Suite operativa

Quando crei un cluster con GKE Dataplane V2, il logging dei criteri di rete è integrato. Configura il CRD di logging sul cluster per vedere quando le connessioni vengono 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 GKE su VMware Google Distributed Cloud Virtual per Bare Metal
Numero di nodi per cluster 5000 500 500
Numero di pod per cluster 50.000 15.000 27.500
Numero di servizi LoadBalancer per cluster 750 500 1000

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

Aumento del limite di nodi nella versione 1.23

A partire dalla versione 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 privati o pubblici che utilizzano Private Service Connect. Per verificare se il cluster utilizza Private Service Connect, consulta Cluster pubblici con Private Service Connect.
  • Solo cluster a livello di regione
  • Solo i cluster creati con GKE versione 1.23 o successive hanno un limite di 5000 nodi aumentato. I cluster creati con le versioni precedenti di GKE potrebbero richiedere l'aumento di una quota per le dimensioni del cluster. Contatta l'assistenza per ricevere aiuto.
  • I cluster che utilizzano CRD Cilium (CiliumNetworkPolicy e CiliumClusterwideNetworkPolicy) non possono scalare fino a 5000 nodi.

Servizi LoadBalancer in GKE su VMware

Il numero di servizi LoadBalancer supportati in GKE su VMware dipende dalla modalità del bilanciatore del carico utilizzata. GKE su VMware supporta 500 servizi di bilanciamento del carico quando si utilizza la modalità di bilanciamento del carico in bundle (Seesaw) e 250 quando si utilizza la modalità di bilanciamento del carico integrata con F5. Per maggiori informazioni, consulta Scalabilità.

Limitazioni

GKE Dataplane V2 presenta le seguenti limitazioni:

  • GKE Dataplane V2 può essere abilitato 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 abiliti GKE Dataplane V2 con NodeLocal DNSCache, non puoi configurare i pod con dnsPolicy: ClusterFirstWithHostNet oppure i tuoi pod riscontreranno errori di risoluzione DNS.
  • A partire dalla versione 1.21.5-gke.1300 di GKE, GKE Dataplane V2 non supporta le API CRD CiliumNetworkPolicy o CiliumClusterwideNetworkPolicy.
  • I bilanciatori del carico di rete passthrough interni creati manualmente e associati a un servizio di tipo NodePort non sono supportati.
  • Poiché GKE Dataplane V2 ottimizza l'elaborazione dei pacchetti kernel eBPF tramite eBPF, le prestazioni dei pod potrebbero risentirne se hai carichi di lavoro con un alto tasso di abbandono dei pod. L'obiettivo principale di GKE Dataplane V2 è raggiungere un eBPF ottimale.
  • Si è verificato 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, quindi è più probabile che le nuove funzionalità dei servizi vengano implementate in kube-proxy prima di essere implementate in cilium per GKE Dataplane V2. Un esempio di funzionalità dei servizi implementata per la prima volta in kube-proxy è KEP-1669: endpoint di chiusura proxy.
  • Per i servizi NodePort che eseguono la versione 1.25 o precedente con intervalli SNAT e PUPI predefiniti, devi aggiungere l'intervallo PUPI dei pod in nonMasqueradeCIDRs in ip-masq-agent ConfigMap per evitare problemi di connettività.
  • In alcuni casi, i pod dell'agente GKE Dataplane V2 (anetd) possono consumare una notevole quantità di risorse della CPU, fino a due o tre vCPU per istanza. Questo accade quando si verifica un volume elevato di connessioni TCP aperte e chiuse sul nodo. Per limitare 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 il piano di controllo versione 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 i Criteri per il traffico interno dei servizi.

GKE Dataplane V2 e kube-proxy

GKE Dataplane V2 non utilizza kube-proxy, ad eccezione dei pool di nodi Windows Server su GKE 1.25 e versioni precedenti.

Applicazione dei criteri di rete senza GKE Dataplane V2

Consulta Utilizzo dell'applicazione dei criteri di rete per le istruzioni su come abilitare l'applicazione dei criteri di rete nei cluster che non utilizzano GKE Dataplane V2.

Passaggi successivi