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:

Il percorso di un pacchetto attraverso un nodo utilizzando 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 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 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 7500 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 IP cluster 10.000 1000 1000
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 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 versione e dalla località di Kubernetes del cluster GKE Dataplane V2:

  • Cluster regionali:
    • Kubernetes versione 1.31 o successive: fino a 7500 nodi.
    • Kubernetes versione 1.23 o successive: fino a 5000 nodi.
  • Cluster zonali: fino a 1000 nodi.
  • Tutti gli altri cluster: fino a 500 nodi.

Per raggiungere i limiti di nodi più elevati (5000 o 7500), il cluster regionale deve soddisfare anche 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.
  • Solo i cluster creati con GKE versione 1.23 o successive hanno un limite di 5000 nodi. I cluster creati con versioni GKE precedenti potrebbero richiedere l'aumento di una quota di dimensioni del cluster. Contatta l'assistenza per ricevere aiuto.
  • I cluster che utilizzano il CRD CiliumNetworkPolicy (Cilium) non possono scalare fino a 5000 nodi. Il CRD CiliumClusterwideNetworkPolicy supporta 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 maggiori informazioni, consulta Scalabilità.

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 maggiori 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 attenuare 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 maggiori informazioni, consulta Problemi di incompatibilità di Retina.

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