Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Ambient-Netzwerk für GKE vorbereiten

Autopilot Standard

Auf dieser Seite erfahren Sie, wie Sie Ambient Networking in einem neuen oder vorhandenen Cluster aktivieren, Namespaces und Arbeitslasten registrieren, um die Ambient-Traffic-Weiterleitung zu aktivieren, und mTLS- und Autorisierungsrichtlinien konfigurieren.

Weitere Informationen zur Architektur, zu den Vorteilen und Funktionen von Ambient Networking finden Sie in der Übersicht zu Ambient Networking.

Voraussetzungen und Einschränkungen

Bevor Sie Ambient Networking einrichten, sollten Sie sich die folgenden Funktionseinschränkungen, Versionsanforderungen und Bereichseinschränkungen ansehen:

GKE-Version: Erfordert GKE-Version 1.36.4-gke.1391000 oder höher.
Regionale Unterstützung: Cluster müssen in einer Region erstellt werden, die von regionalem Cloud Service Mesh unterstützt wird.
Arbeitslast-Interoperabilität: Arbeitslasten, die für Ambient Networking registriert sind, können in der Vorabversion nicht mit Arbeitslasten mit Sidecar-Injektion oder proxylosen gRPC-Arbeitslasten interagieren.
Nicht unterstützte Funktionen:
- Feld trafficDistribution des Kubernetes-Dienstes.
- Monitorlose Dienste.
- GKE Sandbox (gVisor).
Sicherheitshinweis: Wenn die Komponente gke-ambient-nriplugin auf einem Knoten nicht mehr verfügbar ist, werden die Authentifizierung und Autorisierung für eingehenden Traffic möglicherweise umgangen.

Hinweis

Führen Sie die folgenden erforderlichen Einrichtungsschritte in Google Cloudaus:

Erstellen Sie ein Projekt oder wählen Sie eines aus.

Aktivieren Sie die erforderlichen APIs:

gcloud services enable \
    privateca.googleapis.com \
    gkehub.googleapis.com \
    compute.googleapis.com \
    container.googleapis.com \
    trafficdirector.googleapis.com \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    telemetry.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com

Authentifizierung von verwalteten Workload Identity für GKE konfigurieren

Ambient Networking in einem neuen Cluster aktivieren

Führen Sie den folgenden Befehl aus, um einen neuen GKE-Cluster mit aktiviertem Ambient Networking zu erstellen:

GKE-Cluster mit aktiviertem Ambient Networking erstellen

gcloud beta container clusters create CLUSTER_NAME \
    --machine-type=e2-standard-4 \
    --enable-ambient-networking \
    --enable-dataplane-v2 \
    --enable-fleet \
    --gateway-api=standard \
    --location=CLUSTER_LOCATION \
    --release-channel=rapid \
    --workload-pool=PROJECT_ID.svc.id.goog

Im Namespace gke-managed-ambient werden jetzt zwei DaemonSets ausgeführt.

Ambient Networking für einen vorhandenen Cluster aktivieren

So aktivieren Sie Ambient Mesh in einem vorhandenen GKE-Cluster:

Prüfen Sie, ob Ihr Cluster die folgenden Anforderungen erfüllt:
- Version 1.36.4-gke.1391000 oder höher.
- GKE Dataplane V2 aktiviert.
- Der Maschinentyp muss „e2-standard-4“ oder größer sein.
- Der Cluster muss einer Flotte hinzugefügt werden.
- Für den Cluster müssen die Gateway API und Workload Identity aktiviert sein.

Ambient Networking für einen vorhandenen Cluster aktivieren:

gcloud beta container clusters update CLUSTER_NAME \
    --enable-ambient-networking \
    --location=CLUSTER_LOCATION \
    --enable-fleet

Im Namespace gke-managed-ambient werden jetzt zwei DaemonSets ausgeführt.

Verweisen Sie die Befehlszeile auf den Cluster, um dies zu prüfen:

gcloud beta container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION

Rufen Sie die DaemonSets im Namespace gke-managed-ambient ab:

kubectl get daemonset -n gke-managed-ambient

Die Ausgabe sieht etwa so aus:

NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
gke-ambient-nriplugin   9         9         9       9            9           4d1h
gke-ambient-proxy       9         9         9       9            9           4d1h

Namespace für Ambient Networking registrieren

So stellen Sie eine Beispielanwendung bereit und aktivieren die Ambient-Traffic-Weiterleitung für ihren Namespace:

Beispielanwendung bereitstellen:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: client
  namespace: ambient-test
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: server
  namespace: ambient-test
---
apiVersion: v1
kind: Service
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    app: server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
  namespace: ambient-test
  labels:
    app: client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      serviceAccountName: client
      containers:
      - name: nginx
        image: nginx:1.29.6
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: server
  namespace: ambient-test
  labels:
    app: server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: server
  template:
    metadata:
      labels:
        app: server
    spec:
      serviceAccountName: server
      containers:
      - name: nginx
        image: nginx:1.29.6
        readinessProbe:
          httpGet:
            path: /
            port: 80
EOF

Fügen Sie dem Namespace ambient-test ein Label hinzu, um die Weiterleitung von Traffic über den GKE-Ambient-Proxy zu aktivieren:
```
kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient
```

Prüfen Sie, ob einzelne Pods im Namespace für die Traffic-Weiterleitung konfiguriert wurden:

kubectl get pods -n ambient-test -o yaml | grep redirection

Die Ausgabe sieht etwa so aus:

ambient.networking.gke.io/redirection: enabled
ambient.networking.gke.io/redirection: enabled

Testen Sie den Client-zu-Server-Traffic:

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Um zu prüfen, ob Klartext-Traffic über gke-ambient-proxy fließt, rufen Sie die Zugriffslogs im Log-Explorer auf und suchen Sie nach dem Lognamen gke-ambient-node-proxy-accesslog:

Zum Log-Explorer
Optional können Sie die Generierung von Layer-4-Messwerten für Arbeitslasten im Namespace aktivieren:
```
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled
```
Nach der Aktivierung sind Arbeitslastmesswerte in Cloud Monitoring über Network Services Monitoring verfügbar.

mTLS für einen Dienst aktivieren

Nachdem Sie die Traffic-Weiterleitung für Arbeitslasten in einem Namespace aktiviert haben, wenden Sie Richtlinien an, um Verschlüsselung, Authentifizierung und Autorisierung zu erzwingen.

Konfigurieren Sie eine permissive mTLS-Richtlinie für die serverseitigen Arbeitslasten:
```
kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Permissive
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF
```
Durch diese Richtlinie akzeptieren die Pods sowohl mTLS- als auch Nur-Text-Traffic. Beachten Sie, dass bei permissivem mTLS Traffic-Sniffing verwendet wird, um zu erkennen, ob es sich bei dem Traffic um mTLS oder Nur-Text handelt. Dadurch wird der Anwendungstraffic unterbrochen, der ein eigenes TLS- oder ein „Server spricht zuerst“-Protokoll wie MySQL verwendet.

Prüfen Sie, ob die Richtlinie vom Controller akzeptiert wurde:

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

Die Ausgabe sieht etwa so aus:

[...]

    Conditions:
    Last Transition Time:  2026-03-25T17:47:30Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                   From                   Message
----    ------  ----                  ----                   -------
Normal  Sync    108s (x2 over 2m20s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-fqtx-mesh succeeded

Die Richtlinienweitergabe kann nach der Annahme durch den Controller bis zu drei Minuten dauern. Warten Sie drei Minuten, bevor Sie fortfahren.

Konfigurieren Sie eine clientseitige mTLS-Richtlinie, die auf den Dienst abzielt:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPClientTLSPolicy
metadata:
  name: server-mtls
  namespace: ambient-test
spec:
  targetRefs:
  - group: ""
    kind: Service
    name: server
  subjectAltNames:
  - uri: spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/server
EOF

Mit dieser Richtlinie werden registrierte Clients so konfiguriert, dass sie mTLS-Traffic an den Serverdienst senden. Möglicherweise müssen Sie mindestens zwei Minuten warten, bevor Sie mit dem nächsten Schritt fortfahren.

Prüfen Sie, ob die Richtlinie vom Controller akzeptiert wurde:

kubectl describe gcpclienttlspolicies -n ambient-test server-mtls | grep -A50 Status

Die Ausgabe sieht etwa so aus:

[...]
Status:
Conditions:
    Last Transition Time:  2024-10-13T01:15:03Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted

Testen Sie den Client-zu-Server-Traffic:
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
Der Traffic von Pods, die für Ambient Networking registriert sind, zum Serverdienst im Namespace „ambient-test“ sollte jetzt mTLS verwenden.
Wenn Sie prüfen möchten, ob Verbindungen mTLS verwenden, rufen Sie die Zugriffslogs im Log-Explorer auf und suchen Sie nach dem Lognamen gke-ambient-node-proxy-accesslog:

Zum Log-Explorer

Aktualisieren Sie die vorhandene GCPServerTLSPolicy, um den mode im Serverdienst von Permissive in Strict zu ändern, damit die Arbeitslast-Pods keinen Klartext-Traffic mehr akzeptieren:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPServerTLSPolicy
metadata:
  name: server
  namespace: ambient-test
spec:
  mtlsMode: Strict
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
EOF

Prüfen Sie, ob die Richtlinie akzeptiert wurde:

kubectl describe gcpservertlspolicies -n ambient-test server | grep -A50 Status

Die Ausgabe sieht etwa so aus:

Name:         server

<...>

UID:                 e4f2a7a3-69aa-4528-8ea6-6f1bf2142011
Spec:
Mtls Mode:  Strict
Target Refs:
Group:
Kind:   Pod
Selector:
  Match Labels:
    App:  server
Status:
Ancestors:
    Ancestor Ref:
    Group:
    Kind:   Pod
    Name:   app=server
    Conditions:
    Last Transition Time:  2026-03-25T22:33:54Z
    Message:
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Controller Name:         networking.gke.io/dpv2-1n
Events:
Type    Reason  Age                  From                   Message
----    ------  ----                 ----                   -------
Normal  Sync    43s (x5 over 4m57s)  sc-dpv2-1n-controller  Sync on Mesh dpv2-1n-2cdi-mesh succeeded

Der gesamte Klartext-Traffic zu Ihrem Serverdienst wird jetzt abgelehnt.

Prüfen Sie, ob Klartext-Traffic jetzt abgelehnt wird. Senden Sie dazu Traffic von einem Client, der NICHT für Ambient Networking registriert ist, an den Serverdienst:

kubectl create namespace noambient-test && \
kubectl run -it -n noambient-test --rm curl --image=nginx -- \
    /bin/curl -fsLSv http://server.ambient-test.svc.cluster.local

Diese Verbindung sollte mit einer Meldung wie der folgenden fehlschlagen:

* Request completely sent off
* Empty reply from server
* shutting down connection #0
curl: (52) Empty reply from server

Layer-4-Autorisierungsrichtlinie festlegen

Um die identitätsbasierte Autorisierung zu erzwingen, geben Arbeitslastinhaber Pod-Labels im Richtlinienselektor an. Namespace-Inhaber wenden Richtlinien ohne Selektoren auf den gesamten Namespace an.

Wenden Sie die folgende Richtlinie an, um zu erzwingen, dass nur der Client mit dem Server kommunizieren darf:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPAuthzPolicy
metadata:
  name: allow-client
  namespace: ambient-test
spec:
  action: ALLOW
  enforcementLevel: L4
  targetRefs:
  - group: ""
    kind: Pod
    selector:
      matchLabels:
        app: server
  rules:
  - from:
      sources:
      - principals:
        - principalSelector: CLIENT_CERT_URI_SAN
          principal:
            type: Exact
            value: spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client
EOF

Diese Richtlinie wird auf Traffic zu Server-Pods im Namespace ambient-test angewendet. Dadurch wird sichergestellt, dass Traffic nur von Quellen mit der SPIFFE-Identität spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client zugelassen wird.

Prüfen Sie, ob die Richtlinienerzwingung zulässig ist, indem Sie eine Beispielanfrage vom Dienstkonto client senden.

kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Prüfen Sie, ob die Richtlinienerzwingung nicht zulässig ist, indem Sie eine Beispielanfrage vom Dienstkonto server senden.

kubectl exec -it deploy/server -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local

Die Ausgabe sieht etwa so aus:

curl: (52) Empty reply from server
command terminated with exit code 52

Mit dem Log-Explorer können Sie das Logging der Autorisierungserzwingung aufrufen. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf und suchen Sie mit dem Lognamen gke-ambient-node-proxy-accesslog nach abgelehnten Anfragen:
```
resource.type="k8s_container"
logName="projects/PROJECT_ID/logs/gke-ambient-node-proxy-accesslog"
jsonPayload.error_details=~"rbac_access_denied"
```
Zum Log-Explorer

Ambient-Netzwerk für GKE vorbereiten Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Voraussetzungen und Einschränkungen

Hinweis

Ambient Networking in einem neuen Cluster aktivieren

Ambient Networking für einen vorhandenen Cluster aktivieren

Namespace für Ambient Networking registrieren

mTLS für einen Dienst aktivieren

Layer-4-Autorisierungsrichtlinie festlegen

Ambient-Netzwerk für GKE vorbereiten