Ambient Networking – Übersicht

GKE Ambient Networking bietet ein vereinfachtes, Sidecar-freies Bereitstellungsmodell für ein Service Mesh mit Layer-4-Funktionen. Durch die Verlagerung der Proxy-Funktionalität auf Komponenten auf Knotenebene, die in GKE Dataplane V2 (DPv2) integriert sind, reduziert Ambient Networking den Ressourcenaufwand, eliminiert Neustarts von Arbeitslasten für Proxy-Updates und vereinfacht die Verwaltung des Mesh-Lebenszyklus.

Leistungsspektrum

Die Vorabversion von GKE Ambient Networking unterstützt die Layer-4-Mesh-Funktionalität für einzelne Cluster:

  • Gegenseitiges TLS (mTLS): Erzwingt die Verschlüsselung bei der Übertragung und die Identitätsauthentifizierung.
  • Service Discovery: Erkennt Dienste und leitet Verbindungen automatisch über Arbeitslasten hinweg weiter.
  • Layer-4-Traffic-Management: Load-Balancing und Routing von TCP-Traffic.
  • Ebene-4-Telemetrie: Sendet Messwerte zu Netzwerkverkehr, Verbindungen und Fehlern an Cloud Observability. Weitere Informationen zum Visualisieren und Analysieren dieser Messwerte finden Sie in der Übersicht über das Monitoring von Netzwerkdiensten.

Vorteile von Ambient Networking

Im Vergleich zu Sidecar-basierten Service-Mesh-Architekturen bietet Ambient Networking mehrere wichtige Betriebs- und Ressourcenvorteile:

  • Vereinfachte Verwaltung des Lebenszyklus: Das Fate-Sharing-Modell zwischen Sidecar-Proxys und Anwendungscontainern wird eliminiert. Sie können Proxy-Updates, Sicherheitspatches und Upgrades auf Knotenebene anwenden, ohne Arbeitslast-Pods neu starten oder Anwendungsausfallzeiten verursachen zu müssen.

  • Reduzierter Ressourcenverbrauch: Die Proxy-Funktion wird in freigegebenen Instanzen auf Knotenebene konsolidiert, wodurch der CPU- und Arbeitsspeicher-Overhead im Vergleich zu Sidecar-Modellen um bis zu 90 % reduziert wird.

  • Beseitigung von Sidecar-Risiken: Behebt gängige Sidecar-Probleme wie Sicherheitslücken bei der Umgehung von Container-Proxys, Unterbrechungen von Sticky-Verbindungen und unzuverlässige Weitergabe von Verbindungsabbrüchen.

  • Native Integration in die Google Cloud -Plattform: Native Integration in GKE Dataplane V2 (DPv2), verwaltete Workload Identity, Certificate Authority Service (CAS) und Google Cloud Observability.

Interoperabilität und Umfang

Beachten Sie während dieser Vorabversion von Ambient Networking die folgenden Einschränkungen hinsichtlich Umfang und Interoperabilität:

  • Anforderung an die Gateway API: Ambient Networking erfordert die Gateway API. Istio APIs werden nicht unterstützt.
  • Arbeitslastinteroperabilität: Arbeitslasten, die für Ambient Networking registriert sind, können nicht mit Arbeitslasten mit Sidecar-Injektion (in GKE, Compute Engine oder Cloud Run) oder proxylosen gRPC-Arbeitslasten interagieren.

Architektur und Komponenten

Ambient Networking wird direkt in GKE Dataplane V2 (DPv2) auf jedem Knoten eingebunden, anstatt Envoy-Sidecars in Arbeitslast-Pods einzufügen.

Vorhandene Komponenten der Steuerungsebene

Ambient Networking basiert auf Komponenten der Steuerungsebene, um Richtlinien zu verteilen, Konfigurationen zu übersetzen und Zertifikate auszustellen:

  • Traffic Director: stellt die xDS-Steuerungsebene für die Richtlinienverteilung und Routingkonfiguration bereit.
  • GKE-Gateway-Controller: Übersetzt benutzerdefinierte Kubernetes-Ressourcen in die Traffic Director-Konfiguration.
  • Certificate Authority Service (CAS): stellt X.509-Identitätszertifikate für Arbeitslasten mithilfe von verwalteter Workload Identity aus.
  • Steuerungsebene des GKE-Clusters: Genehmigt Zertifikatsignierungsanfragen (Certificate Signing Requests, CSRs) und leitet sie an CAS weiter.

Knotenkomponenten

Bei Ambient Networking werden die folgenden Komponenten pro Knoten installiert, um den Traffic von Arbeitslasten direkt auf jedem Clusterknoten abzufangen und weiterzuleiten:

  • GKE-NRI-Plug-in für Ambient: Node Resource Interface-Plug-in (NRI), das Low-Level-Netzwerke konfiguriert, um Pod-Traffic abzufangen und an den Proxy weiterzuleiten.

  • GKE-Ambient-Proxy: Proxy auf Knotenebene, der Listening-Sockets verwaltet, xDS-Regeln von Traffic Director empfängt, X.509-Identitätszertifikate bei Bedarf von der GKE-Steuerungsebene abruft und Layer-4-Traffic weiterleitet.

Ambient-Dataplane-Komponenten auf Knotenebene werden als DaemonSets im Namespace gke-managed-ambient ausgeführt und zusammen mit der GKE-Steuerungsebene automatisch versioniert, gepatcht und aktualisiert.

Zielskalierung und Limits

Während der Vorabversion gelten für Ambient Networking die folgenden Einschränkungen hinsichtlich Umfang und Interoperabilität:

Ressourcenmesswert GKE DPv2 (mit Ambient) Standard-GKE-DPv2 (ohne Ambient)
Knoten pro Cluster 500 7.500
Dienste pro Cluster 300 10.000
Pods pro Cluster 5.000 200.000
Maximale Anzahl von Pods pro Knoten 256 256

Allgemeine GKE-Clusterkontingente finden Sie in den Clusterlimits und den Spezifikationen für GKE GKE Dataplane V2.

Preise

Sehen Sie sich die folgenden Details zu Preisen und Gebühren für Betriebsressourcen für Ambient Networking an:

  • Alle Pods in einem beliebigen Namespace mit dem Ambient-Label networking.gke.io/dataplane-mode=ambient werden mit 0,004 $ pro Stunde (0,00006667 $ pro Minute oder etwa 2,90 $ pro Monat) abgerechnet. Während der Vorabversion wird die Abrechnung nicht erzwungen.
  • Es fallen die standardmäßigen Nutzungsgebühren für Cloud Observability (Cloud Monitoring/Cloud Logging) und Certificate Authority Service an.

Gateway API-Ressourcen verstehen

Wenn Sie Ambient Networking verwenden, werden die benutzerdefinierten Ressourcen der Kubernetes Gateway API, die Sie in Ihrem Cluster verwalten, automatisch in eine Reihe von verwaltetenGoogle Cloud -API-Ressourcen übersetzt.

Funktionen Verwaltete Google Cloud API-Ressource Umfang Kardinalität
Mesh Mesh Regional 1 pro Cluster
Service Routing TCPRoute Regional 1 pro Cluster, plus 1 pro Dienst, der von einem GCPClientTLSPolicy angesprochen wird
Dienstvertretung BackendService Regional 1 pro Cluster
Clientauthentifizierung ClientTlsPolicy Regional 1 pro Cluster
Serverauthentifizierung ServerTlsPolicy Regional 3 pro Cluster
Serverauthentifizierung EndpointPolicy Regional 1 pro GCPServerTLSPolicy, plus 1 pro eindeutigem mTLS-Modus in der zugehörigen portOverrides
Autorisierung AuthzPolicy Regional 1 pro Pod-targetRef in jedem GCPAuthzPolicy mit enforcementLevel: L4
Routing für ausgehenden Traffic EgressRouting Regional 1 pro Namespace mit einem GCPEgressPolicy

Nächste Schritte