GKE Ambient Networking bietet ein vereinfachtes, sidecarloses Bereitstellungsmodell für ein Service Mesh mit Layer 4-Funktionen. Durch die Verlagerung der Proxyfunktionen auf Knotenkomponenten, die in GKE Dataplane V2 (DPv2) integriert sind, reduziert Ambient Networking den Ressourcenaufwand, vermeidet Neustarts von Arbeitslasten für Proxy-Updates und vereinfacht die Verwaltung des Mesh-Lebenszyklus.
Leistungsspektrum
Die Vorschau von GKE Ambient Networking unterstützt die Mesh-Funktionalität der Ebene 4 für einzelne Cluster:
- Gegenseitiges TLS (mTLS): Erzwingt die verschlüsselte Übertragung und Identitätsauthentifizierung.
- Service Discovery:Dienste werden automatisch erkannt und Verbindungen werden automatisch über Arbeitslasten hinweg weitergeleitet.
- Layer-4-Traffic-Management:Load-Balancing und Routing von TCP-Traffic.
- Telemetrie der Schicht 4:Gibt Messwerte für Netzwerkverkehr, Verbindungen und Fehler an Cloud Observability aus. Weitere Informationen zum Visualisieren und Analysieren dieser Messwerte finden Sie in der Übersicht zum Monitoring von Netzwerkdiensten.
Vorteile von Ambient Networking
Im Vergleich zu Sidecar-basierten Service-Mesh-Architekturen bietet Ambient Networking mehrere wichtige betriebliche und ressourcenbezogene Vorteile:
Vereinfachte Verwaltung des Lebenszyklus:Das Shared-Fate-Modell zwischen Sidecar-Proxys und Anwendungscontainern wird nicht mehr verwendet. Sie können Proxy-Updates, Sicherheitspatches und Upgrades auf Knotenebene anwenden, ohne Arbeitslast-Pods neu zu starten oder Ausfallzeiten der Anwendung zu verursachen.
Geringerer Ressourcenverbrauch: Durch die Konsolidierung des Proxyings in freigegebenen Instanzen auf Knotenebene wird der CPU- und Arbeitsspeicher-Aufwand im Vergleich zu Sidecar-Modellen um bis zu 90% reduziert.
Beseitigung von Sidecar-Risiken:Damit werden häufige Sidecar-Probleme wie Container-Proxy-Bypass-Schwachstellen, Unterbrechungen von Sticky-Verbindungen und die Weitergabe von unzuverlässigen Verbindungsbeendigungen behoben.
Native Google Cloud Plattformintegration:Die Lösung lässt sich nativ in GKE Dataplane V2 (DPv2), Managed Workload Identity, Certificate Authority Service (CAS) und Google Cloud Observability einbinden.
Interoperabilität und Umfang
Beachten Sie während dieser Vorschau von Ambient Networking die folgenden Einschränkungen in Bezug auf Umfang und Interoperabilität:
- Anforderung an die Gateway API:Für Ambient Networking ist die Gateway API erforderlich. Istio-APIs werden nicht unterstützt.
- Interoperabilität von Arbeitslasten:Arbeitslasten, die für Ambient Networking registriert sind, können nicht mit Arbeitslasten mit Sidecar-Injection (in GKE, Compute Engine oder Cloud Run) oder proxylosen gRPC-Arbeitslasten zusammenarbeiten.
Architektur und Komponenten
Ambient Networking wird direkt in GKE Dataplane V2 (DPv2) auf jedem Knoten integriert, 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:Bietet die xDS-Steuerungsebene für die Richtlinienverteilung und Routingkonfiguration.
- 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.
- GKE-Cluster-Steuerungsebene:Genehmigt Zertifikatsignierungsanfragen (Certificate Signing Requests, CSRs) und leitet sie an CAS weiter.
Knotenkomponenten
Bei Ambient Networking werden die folgenden Komponenten pro Knoten installiert, um Arbeitslasttraffic direkt auf jedem Clusterknoten abzufangen und weiterzuleiten:
GKE Ambient NRI-Plug‑in:Ein Node Resource Interface (NRI)-Plug‑in, das die Low-Level-Netzwerkfunktionen konfiguriert, um Pod-Traffic abzufangen und zum Proxy umzuleiten.
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.
Umgebungs-Datenebenenkomponenten auf Knotenebene werden als DaemonSets im Namespace gke-managed-ambient ausgeführt und automatisch mit der GKE-Steuerungsebene versioniert, gepatcht und aktualisiert.
Zielskalierung und ‑limits
Während der Vorschau gelten für Ambient Networking die folgenden Einschränkungen in Bezug auf 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 unter Clusterlimits und in den Spezifikationen für GKE Dataplane V2.
Preise
Hier finden Sie Informationen zu Preisen und Gebühren für Betriebsressourcen für Ambient Networking:
- Alle Pods in einem beliebigen Namespace mit dem Ambient-Label
networking.gke.io/dataplane-mode=ambientwerden 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 gelten die Standardnutzungsgebühren für Cloud Observability (Cloud Monitoring / Cloud Logging) und den Certificate Authority Service.
Gateway API-Ressourcen
Wenn Sie Ambient Networking verwenden, werden die benutzerdefinierten Kubernetes Gateway API-Ressourcen, 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 |
|---|---|---|---|
| Service Routing | TCPRoute |
Regional | 1 pro Kubernetes-Dienst mit aktiviertem mTLS |
| Dienstdarstellung | BackendService |
Regional | 2 pro Cluster |
| Authentifizierung | ClientTlsPolicy, ServerTlsPolicy |
Regional | 1 pro entsprechender Kubernetes-Richtlinie |
| Autorisierung | EndpointPolicy, TcpFilter |
Regional | 1 pro entsprechender Kubernetes-Richtlinie |
Nächste Schritte
- GKE-Ambient-Netzwerk vorbereiten
- Informationen zur Gateway API
- Monitoring von Netzwerkdiensten – Übersicht