Panoramica di Ambient Networking

Ambient Networking di GKE fornisce un modello di deployment semplificato e senza sidecar per un mesh di servizi con funzionalità di livello 4. Spostando la funzionalità proxy ai componenti a livello di nodo integrati in GKE Dataplane V2 (DPv2), Ambient Networking riduce l'overhead delle risorse, elimina i riavvii dei workload per gli aggiornamenti del proxy e semplifica la gestione del ciclo di vita del mesh.

Funzionalità

L'anteprima di Ambient Networking di GKE supporta la funzionalità mesh di livello 4 per un singolo cluster:

  • Mutual TLS (mTLS): applica il transito criptato e l'autenticazione dell'identità.
  • Service Discovery: rileva i servizi e instrada automaticamente le connessioni tra i workload.
  • Gestione del traffico di livello 4: bilancia il carico e instrada il traffico TCP.
  • Telemetria di livello 4: invia metriche relative a traffico di rete, connessioni ed errori a Cloud Observability. Per informazioni dettagliate sulla visualizzazione e sull'analisi di queste metriche, consulta la panoramica di Monitoraggio dei servizi di rete.

Vantaggi dell'Ambient Networking

Rispetto alle architetture di mesh di servizi basate su sidecar, Ambient Networking offre diversi vantaggi operativi e di risorse chiave:

  • Gestione del ciclo di vita semplificata: elimina il modello di destino condiviso tra i proxy sidecar e i container delle applicazioni. Puoi applicare aggiornamenti del proxy, patch di sicurezza e upgrade a livello di nodo senza riavviare i pod dei workload o causare tempi di inattività dell'applicazione.

  • Consumo di risorse ridotto: consolida il proxying in istanze condivise a livello di nodo, riducendo l'overhead di CPU e memoria fino al 90% rispetto ai modelli sidecar.

  • Eliminazione dei rischi legati ai sidecar: risolve i problemi comuni dei sidecar, come le vulnerabilità di bypass del proxy dei container, l'interruzione delle connessioni sticky e la propagazione inaffidabile della terminazione delle connessioni.

  • Integrazione nativa della piattaforma Cloud de Confiance by S3NS : si integra in modo nativo con GKE Dataplane V2 (DPv2), Workload Identity gestito, Certificate Authority Service (CAS) e Google Cloud Observability.

Interoperabilità e ambito

Durante questa anteprima di Ambient Networking, tieni presente i seguenti vincoli di ambito e interoperabilità:

  • Requisito dell'API Gateway: l'Ambient Networking richiede l'API Gateway. Le API Istio non sono supportate.
  • Interoperabilità dei workload: i workload registrati in Ambient Networking non possono interagire con i workload con iniezione sidecar (su GKE, Compute Engine o Cloud Run) o con i workload gRPC senza proxy.

Architettura e componenti

Ambient Networking si integra direttamente in GKE Dataplane V2 (DPv2) su ogni nodo, anziché inserire sidecar Envoy nei pod dei workload.

Componenti del control plane esistenti

Ambient Networking si basa sui componenti del control plane per distribuire le policy, tradurre la configurazione ed emettere certificati:

  • Traffic Director: fornisce il control plane xDS per la distribuzione delle policy e la configurazione del routing.
  • GKE Gateway Controller: traduce le risorse personalizzate di Kubernetes nella configurazione di Traffic Director.
  • Certificate Authority Service (CAS): emette certificati di identità X.509 per i workload utilizzando Workload Identity gestita.
  • Control plane del cluster GKE: approva le richieste di firma del certificato (CSR) e le instrada a CAS.

Componenti dei nodi

Ambient Networking installa i seguenti componenti per nodo per intercettare e eseguire il proxy del traffico dei workload direttamente su ogni nodo del cluster:

  • Plug-in NRI GKE Ambient: plug-in Node Resource Interface (NRI) che configura il networking di basso livello per intercettare e reindirizzare il traffico dei pod al proxy.

  • Proxy GKE Ambient: proxy a livello di nodo che gestisce i socket di ascolto, riceve le regole xDS da Traffic Director, recupera i certificati di identità X.509 on demand dal control plane di GKE e funge da proxy per il traffico di livello 4.

I componenti del piano dati ambientale a livello di nodo vengono eseguiti come DaemonSet nello spazio dei nomi gke-managed-ambient e vengono sottoposti automaticamente a controllo delle versioni, applicazione di patch e upgrade insieme al control plane GKE.

Scala e limiti di destinazione

Durante l'anteprima, l'Ambient Networking ha i seguenti limiti di ambito e interoperabilità:

Metrica risorsa GKE DPv2 (con ambient) GKE DPv2 standard (senza ambient)
Nodi per cluster 500 7500
Servizi per cluster 300 10.000
Pod per cluster 5000 200.000
Numero massimo di pod per nodo 256 256

Per le quote generali dei cluster GKE, consulta i limiti dei cluster e le specifiche di GKE Dataplane V2.

Prezzi

Consulta i seguenti dettagli relativi ai prezzi e agli addebiti per le risorse operative per Ambient Networking:

  • Tutti i pod in qualsiasi spazio dei nomi con l'etichetta ambient networking.gke.io/dataplane-mode=ambient verranno fatturati a 0,004 $l'ora (0,00006667 $ al minuto o circa 2,90 $al mese). La fatturazione non verrà applicata durante l'anteprima.
  • Si applicano le tariffe di utilizzo standard per Cloud Observability (Cloud Monitoring/Cloud Logging) e Certificate Authority Service.

Informazioni sulle risorse dell'API Gateway

Quando utilizzi Ambient Networking, le risorse personalizzate dell'API Gateway di Kubernetes che gestisci nel cluster vengono tradotte automaticamente in un insieme di risorse APICloud de Confiance by S3NS gestite.

Funzionalità Risorsa API Cloud de Confiance by S3NS gestita Ambito Cardinality
Mesh Mesh Regionale 1 per cluster
Routing dei servizi TCPRoute Regionale 1 per cluster, più 1 per servizio scelto come target da un GCPClientTLSPolicy
Rappresentazione del servizio BackendService Regionale 1 per cluster
Autenticazione client ClientTlsPolicy Regionale 1 per cluster
Autenticazione server ServerTlsPolicy Regionale 3 per cluster
Autenticazione server EndpointPolicy Regionale 1 per GCPServerTLSPolicy, più 1 per modalità mTLS distinta nel relativo portOverrides
Autorizzazione AuthzPolicy Regionale 1 per pod targetRef in ogni GCPAuthzPolicy con enforcementLevel: L4
Routing in uscita EgressRouting Regionale 1 per spazio dei nomi con un GCPEgressPolicy

Passaggi successivi