GKE Dataplane V2

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

Prima di leggere questa pagina, tieni presente che networking all'interno di cluster GKE.

Panoramica di GKE Dataplane V2

GKE Dataplane V2 è un dataplane ottimizzato per il networking di 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 e la risoluzione dei problemi dei cluster.

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 tutte le versioni 1.24 e in un secondo momento.

Come funziona GKE Dataplane V2

GKE Dataplane V2 viene implementato eBPF. Quando i pacchetti arrivano a un nodo GKE, i programmi eBPF installati il kernel decide come instradare ed elaborare i pacchetti. A differenza dell'elaborazione dei pacchetti con iptables, eBPF possono utilizzare metadati specifici di Kubernetes nel pacchetto. Ciò consente GKE Dataplane V2 elabora i pacchetti di rete nel kernel in modo più efficiente riporta 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 per ciascun nodo nel cluster. anetd interpreta gli oggetti Kubernetes e dei programmi in eBPF. I pod anetd vengono eseguiti kube-system.

GKE Dataplane V2 e NetworkPolicy

GKE Dataplane V2 viene implementato Cilium. L'eredità Dataplane per GKE viene implementato Calico.

Entrambe queste tecnologie gestiscono Kubernetes NetworkPolicy. Cilium utilizza eBPF, mentre la 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 ai dati legacy aereo.

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, come il numero di Servizi.

GKE Dataplane V2 si basa su mappe eBPF limitate a 64.000 endpoint su per tutti i servizi.

Sicurezza

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

Operazioni

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

Coerenza

GKE Dataplane V2 fornisce un'esperienza di networking coerente.

Per ulteriori informazioni le informazioni, vedi 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 Google Distributed Cloud
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 mantiene una mappa dei servizi per tenere traccia dei servizi a cui fanno riferimento quali pod come backend. Il numero di backend dei pod per ogni servizio, sommato di tutti i Servizi devono rientrare tutti 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 dalle versioni di Kubernetes 1.23, il limite di 500 nodi per Il cluster GKE Dataplane V2 è stato portato a 5000, con quanto segue condizioni aggiuntive imposte ai cluster:

  • Cluster privati o cluster 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 aumentato il limite di 5000 nodi. Cluster creati con le versioni precedenti di GKE potrebbero richiedere l'aumento della quota per le dimensioni del cluster. Contatta l'assistenza per ricevere aiuto.
  • Cluster che utilizzano CRD Cilium (CiliumNetworkPolicy e CiliumClusterwideNetworkPolicy) non è in grado di scalare a 5000 nodi.

Servizi LoadBalancer in Google Distributed Cloud

Il numero di servizi LoadBalancer supportati in Google Distributed Cloud dipende da il modalità bilanciatore del carico in uso. Google Distributed Cloud supporta 500 servizi LoadBalancer quando utilizzi modalità di bilanciamento del carico in bundle (Seesaw) e 250 quando si utilizza il carico integrato di bilanciamento del carico con F5. Per ulteriori informazioni, vedi Scalabilità.

Limitazioni

GKE Dataplane V2 ha le seguenti limitazioni:

  • GKE Dataplane V2 può essere abilitato solo quando si crea un nuovo cluster. Esistente non è possibile eseguire l'upgrade dei cluster per utilizzare GKE Dataplane V2.
  • Nelle versioni GKE precedenti alla 1.20.12-gke.500, se abiliti GKE Dataplane V2 con NodeLocal DNSCache, non possono configurare i pod con dnsPolicy: ClusterFirstWithHostNet, né i tuoi pod sperimenteranno Errori di risoluzione DNS.
  • A partire da GKE versione 1.21.5-gke.1300, GKE Dataplane V2 non supporta le API CRD CiliumNetworkPolicy o CiliumClusterwideNetworkPolicy. In fase di avvio nelle versioni GKE 1.28.6-gke.1095000 e 1.29.1-gke.1016000, può abilitare CiliumClusterwideNetworkPolicy su cluster nuovi o esistenti.
  • Bilanciatori del carico di rete passthrough interni creati manualmente associati a un servizio di tipo NodePort non supportati.
  • Poiché GKE Dataplane V2 ottimizza l'elaborazione dei pacchetti del kernel eBPF tramite eBPF, le prestazioni dei pod potrebbero risentirne se hai carichi di lavoro con un il tasso di abbandono dei pod. L'obiettivo principale di GKE Dataplane V2 è raggiungere prestazioni eBPF.
  • Esiste un problema noto con i servizi multi-cluster con più (TCP/UDP) su GKE Dataplane V2. Per ulteriori informazioni, vedi Servizi MCS con più porte.
  • GKE Dataplane V2 utilizza cilium anziché kube-proxy per implementare Kubernetes Servizi. kube-proxy è gestito e sviluppato da Kubernetes community, pertanto è più probabile che vengano implementate nuove funzioni per i servizi kube-proxy prima dell'implementazione in cilium per GKE Dataplane V2. Uno. un esempio di funzionalità dei 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 precedenti utilizzando SNAT e Intervalli PUPI, devi aggiungere l'intervallo PUPI dei pod in nonMasqueradeCIDRs nel ip-masq-agent ConfigMap per evitare problemi di connettività.
  • In alcuni casi, i pod dell'agente GKE Dataplane V2 (anetd) possono utilizzare un una notevole quantità di risorse CPU, fino a due o tre vCPU per istanza. Questo si verifica quando c'è un volume elevato di connessioni TCP aperte rapidamente sul nodo. Per limitare il problema, consigliamo l'implementazione di keep-alive per le chiamate HTTP e il pooling di connessioni per carichi di lavoro pertinenti.
  • I cluster GKE Dataplane V2 che eseguono il piano di controllo 1.27 o versioni precedenti non supportino il campo .spec.internalTrafficPolicy del servizio. L'efficace il criterio del traffico interno per un servizio è Cluster. su qualsiasi nodo considerati candidati per la risoluzione del Servizio. Per ulteriori informazioni sul consulta Norme sul traffico interno dei servizi.

GKE Dataplane V2 e kube-proxy

GKE Dataplane V2 non utilizza kube-proxy ad eccezione dei pool di nodi di Windows Server sulle versioni GKE 1.25 e in precedenza.

Applicazione dei criteri di rete senza GKE Dataplane V2

Consulta Utilizzare l'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