GKE Dataplane V2

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

Questa pagina presuppone che tu conosca 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 quanto segue:

  • Un'esperienza utente coerente per il networking.
  • Visibilità in tempo reale dell'attività di rete.
  • 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 instradarli 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 la registrazione.

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

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 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 piano dati legacy per GKE è implementato utilizzando Calico.

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

Programmi eBPF personalizzati

GKE Dataplane V2 utilizza programmi eBPF per gestire il traffico di rete, inclusi routing, bilanciamento del carico e applicazione dei criteri di rete. Poiché questi programmi sono essenziali per la connettività di rete, GKE non supporta l'installazione di programmi eBPF personalizzati sui nodi che utilizzano GKE Dataplane V2. I programmi eBPF personalizzati possono interferire con i programmi GKE Dataplane V2 e potrebbero interrompere il networking del cluster.

Se nel cluster viene rilevato un programma eBPF personalizzato, GKE fornisce un suggerimento che ti informa della presenza del programma.

Vantaggi di GKE Dataplane V2

GKE Dataplane V2 offre i seguenti vantaggi:

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 limitate a 260.000 endpoint in tutti i servizi.

Sicurezza

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

Operazioni

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

Coerenza

GKE Dataplane V2 offre un'esperienza di networking coerente.

Per maggiori 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 15.000 500 500
Numero di pod per cluster 400.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 dei pod per ogni servizio sommato in tutti i servizi deve rientrare nella mappa dei servizi, che può contenere fino a 260.000 voci. Se questo limite viene superato, il cluster potrebbe non funzionare come previsto.

Limiti di nodi

Il numero massimo di nodi per cluster dipende dalla località del cluster GKE Dataplane V2:

  • Cluster regionali: fino a 5000, 15.000 o 65.000 nodi per cluster. Non tutti gli aumenti dei nodi sono automatici. A seconda del numero di nodi di destinazione, esistono requisiti di infrastruttura specifici e potresti dover contattare l'assistenza clienti Google Cloud. Lo scalabilità a 65.000 nodi richiede la modalità ottimizzata per la scalabilità di Dataplane V2, che disabilita l'applicazione dei criteri di rete. Per informazioni dettagliate, consulta Limiti e requisiti delle dimensioni del cluster.
  • Cluster zonali: fino a 1000 nodi.

Per raggiungere limiti di scalabilità dei nodi superiori a 5000 nodi nei cluster regionali, il tuo ambiente deve soddisfare le seguenti condizioni:

  • Nel cluster deve essere abilitato Private Service Connect. Per verificare se il cluster utilizza Private Service Connect, consulta Cluster con Private Service Connect.
  • I cluster che utilizzano la CRD CiliumNetworkPolicy sono limitati a limiti di cluster zonali fino a 1000 nodi. Utilizza invece la CRD CiliumClusterwideNetworkPolicy per supportare lo scale up 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 utilizzata. Google Distributed Cloud supporta 500 servizi LoadBalancer 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 saperne di più, consulta Scalabilità.

Supporto Maglev

Per i cluster GKE che eseguono la versione 1.36.0-gke.2882000 e successive, puoi configurare i servizi in modo che utilizzino l'algoritmo di hashing coerente Maglev per la selezione del backend.

Per impostazione predefinita, i servizi Kubernetes utilizzano l'algoritmo random per selezionare i backend. L'algoritmo random può causare il reindirizzamento e il ripristino delle connessioni integre quando il set di pod di backend cambia (ad esempio, durante gli eventi di scalabilità). Maglev mitiga questo problema continuando a instradare il traffico al backend assegnato a una connessione finché rimane integro, anche quando vengono aggiunti o rimossi altri pod.

Vantaggi dell'utilizzo dell'algoritmo Maglev

L'utilizzo dell'algoritmo Maglev offre i seguenti vantaggi:

  • Può migliorare la stabilità della connessione indirizzando il traffico di una connessione allo stesso backend.
  • Può mitigare i problemi di connessione quando vengono aggiunti o rimossi pod di backend, ad esempio durante i riavvii dei pod.

Limitazioni dell'utilizzo dell'algoritmo Maglev

L'utilizzo dell'algoritmo Maglev potrebbe richiedere molte risorse:

  • Potrebbe causare un aumento della memoria utilizzata su anetd in ogni cluster. Per saperne di più, consulta la sezione successiva "Considerazioni sulla memoria utilizzata di Maglev".
  • Potrebbe essere correlato a un maggiore anetd utilizzo della CPU (fino a tre volte di più) durante le modifiche al backend.

Considerazioni sulla memoria utilizzata da Maglev

Per monitorare le connessioni e i backend, l'algoritmo Maglev utilizza una tabella hash: esegue l'hashing della 5-tupla del pacchetto (indirizzo IP di origine, indirizzo IP di destinazione, porta di origine, porta di destinazione e protocollo).

Le dimensioni della tabella di ricerca sono configurate su 16.381 voci. Poiché ogni voce ha una dimensione di 4 byte, un servizio configurato per utilizzare l'algoritmo Maglev richiede 65,5 KB (16.381 × 4 byte) della memoria allocabile di ogni nodo.

Numero di servizi con Maglev abilitato Memoria utilizzata aggiuntiva
100 6,5 MB
1000 65 MB
10.000 650 MB

Applicazione dell'algoritmo Maglev

Per applicare l'algoritmo Maglev a un servizio di tipo NodePort o LoadBalancer, aggiungi l'annotazione gke.networking.io/lb-algorithm: "maglev" ai metadati del servizio durante la creazione del servizio.

Esempio:

apiVersion: v1
kind: Service
metadata:
  name: maglev-service
  annotations:
    gke.networking.io/lb-algorithm: "maglev"
spec:
  type: LoadBalancer
  selector:
    app: application
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

L'annotazione gke.networking.io/lb-algorithm ha effetto durante la creazione del servizio. Per modificare l'algoritmo di un servizio esistente, devi eliminare e ricreare il servizio. La modifica del valore dell'annotazione senza ricrearla causa un comportamento incoerente. anetd sui nuovi nodi tenta di utilizzare l'algoritmo appena configurato, mentre i pod esistenti continuano a utilizzare l'algoritmo precedente.

Esegui il deployment dei carichi di lavoro con SCTP

Puoi eseguire il deployment di carichi di lavoro che utilizzano il protocollo Stream Control Transmission Protocol (SCTP) su cluster abilitati con GKE Dataplane V2. SCTP è un protocollo di livello di trasporto che fornisce una trasmissione affidabile e orientata ai messaggi. Per saperne di più, consulta Eseguire il deployment dei workload con SCTP.

Limitazioni

GKE Dataplane V2 presenta le seguenti limitazioni:

  • GKE Dataplane V2 può essere abilitato solo quando crei un nuovo cluster. I cluster esistenti non possono essere aggiornati per utilizzare GKE Dataplane V2.
  • I bilanciatori del carico di rete passthrough interni creati manualmente associati a un servizio di tipo NodePort non sono supportati.
  • 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 di essere implementate in cilium per GKE Dataplane V2.
  • 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. Ciò si verifica quando sul nodo vengono aperte e chiuse rapidamente un numero elevato di connessioni TCP. Per risolvere il problema, ti consigliamo di implementare keep-alive per le chiamate HTTP e il raggruppamento delle connessioni per i carichi di lavoro pertinenti.

  • L'utilizzo di memoria segnalato dei pod dell'agente GKE Dataplane V2 (anetd) dipende dalla memoria totale disponibile sul nodo. I nodi con una memoria totale maggiore segnalano una memoria utilizzata più elevata per i pod anetd. I pod anetd non utilizzano effettivamente più memoria; l'utilizzo segnalato aumenta perché questa metrica include la prenotazione di memoria della mappa eBPF.

    In GKE, la prenotazione di memoria per le mappe eBPF più grandi è lo 0,25% della memoria totale del nodo. Potrebbe essere riservata memoria aggiuntiva per altre funzionalità specifiche di GKE.

  • 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 tuoi pod di connettersi ai servizi. Ciò 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 eliminato perché tenta di raggiungere direttamente l'indirizzo IP del servizio, potresti riscontrare questo problema. Questo perché ai pod non è consentito 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.

  • I pacchetti ICMP frammentati non sono supportati e vengono eliminati da GKE Dataplane V2.

Applicazione delle policy di rete senza GKE Dataplane V2

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

Passaggi successivi