GKE Dataplane V2

Questa pagina fornisce una panoramica di GKE Dataplane V2 e del suo funzionamento.

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.
• 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 instradare ed elaborare i pacchetti. A differenza dell'elaborazione dei pacchetti con iptables, i programmi eBPF possono utilizzare i 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 che utilizza GKE Dataplane V2:

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

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

Programmi eBPF personalizzati

GKE Dataplane V2 utilizza i programmi eBPF per gestire il traffico di rete, inclusi routing, bilanciamento del carico e applicazione delle policy 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.

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 delle policy di rete è integrata. Configura il CRD di logging sul 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:

GKE Dataplane V2 gestisce una mappa dei servizi per tenere traccia dei servizi che fanno riferimento ai pod come backend. Il numero di backend dei pod per ogni servizio sommato a 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. La scalabilità a 65.000 nodi richiede la modalità ottimizzata per la scalabilità di Dataplane V2, che disabilita l'applicazione delle policy di rete. Per informazioni dettagliate, consulta Limiti e requisiti delle dimensioni dei cluster.
• Cluster zonali: fino a 1000 nodi.

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

• Il cluster deve avere Private Service Connect abilitato. Per verificare se il cluster utilizza Private Service Connect, consulta Cluster con Private Service Connect.
• I cluster che utilizzano il CRD CiliumNetworkPolicy sono limitati ai limiti dei cluster zonali fino a 1000 nodi. Utilizza invece il CRD CiliumClusterwideNetworkPolicy per supportare la scalabilità fino a 5000 nodi.

Servizi LoadBalancer in Google Distributed Cloud

Il numero di servizi LoadBalancer supportati in Google Distributed Cloud dipende da la modalità di bilanciamento 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 ulteriori informazioni, consulta Scalabilità.

Supporto di 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 la reimpostazione 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 per 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 ulteriori informazioni, consulta la sezione successiva "Considerazioni sull'utilizzo della memoria utilizzata Maglev".
• Potrebbe essere collegato a un utilizzo della CPU anetd più elevato (fino a tre volte di più) durante le modifiche del backend.

Considerazioni sulla memoria utilizzata da Maglev

Per tenere traccia delle connessioni e dei 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).

La dimensione della tabella di ricerca è configurata 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.

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 ricreare il servizio 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 dei carichi di lavoro che utilizzano il protocollo SCTP (Stream Control Transmission Protocol) sui cluster in cui è abilitato GKE Dataplane V2. SCTP è un protocollo di livello di trasporto che fornisce una trasmissione affidabile e orientata ai messaggi. Per ulteriori informazioni, consulta Eseguire il deployment dei carichi di lavoro con SCTP.

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.
• 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 viene gestito e sviluppato dalla community di Kubernetes, quindi è 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 un nodo apre e chiude rapidamente un volume elevato di connessioni TCP. Per mitigare questo problema, ti consigliamo di implementare i keep-alive per le chiamate HTTP e il pool di connessioni per i carichi di lavoro pertinenti.

• L'utilizzo della memoria segnalato dei pod dell'agente GKE Dataplane V2 (anetd) dipende dalla memoria totale disponibile sul nodo. I nodi con una memoria totale più elevata 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 della memoria della mappa eBPF.

  In GKE, la prenotazione della memoria per le mappe eBPF più grandi è pari allo 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 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 eliminato 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à di Retina.

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

Applicazione delle policy di rete senza GKE Dataplane V2

Per istruzioni su come abilitare l'applicazione delle policy di rete nei cluster che non utilizzano GKE Dataplane V2, consulta Utilizzare l'applicazione delle policy di rete.

Passaggi successivi

• Leggi Utilizzare GKE Dataplane V2.
• Scopri di più sull'osservabilità di GKE Dataplane V2.
• Scopri come utilizzare la registrazione delle policy di rete.
• Scopri in quali ambienti cluster GKE Enterprise è disponibile GKE Dataplane V2.