準備 GKE 周邊網路

本頁面說明如何在新的或現有叢集上啟用微光網路，註冊命名空間和工作負載以啟用微光流量重新導向，以及設定 mTLS 和授權政策。

如要進一步瞭解微光網路架構、優點和功能，請參閱「微光網路總覽」。

必要條件和限制

設定環境網路前，請先瞭解下列功能限制、版本需求和範圍限制：

  • GKE 版本：需要 GKE 1.35.2-gke.1842000 以上版本。
  • 區域支援：叢集必須在區域 Cloud Service Mesh 支援的區域中建立。
  • 工作負載互通性：在私有搶先體驗版中，註冊使用環境網路的工作負載無法與邊車注入工作負載或無 Proxy 的 gRPC 互通。
  • 不支援的功能：
    • Kubernetes Service trafficDistribution 欄位。
    • 無頭服務。
    • GKE Sandbox (gVisor)。
  • 安全注意事項：如果節點上的 gke-ambient-nriplugin 元件無法使用，系統可能會略過連入流量的驗證和授權強制執行程序。

事前準備

在 Cloud de Confiance by S3NS中完成下列必要設定步驟：

  1. 建立或選取專案。

  2. 啟用必要的 API：

    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

  3. 為 GKE 設定受管理的工作負載身分驗證。

在新叢集上啟用環境網路

執行下列指令，建立啟用環境網路的新 GKE 叢集：

  1. 建立啟用環境網路的 GKE 叢集

    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.s3ns.svc.id.goog

    現在有兩個 DaemonSet 在 gke-managed-ambient 命名空間中執行。

在現有叢集上啟用環境網路

如要在現有的 GKE 叢集上啟用 ambient mesh，請按照下列步驟操作：

  1. 確認叢集符合下列規定：

    • 1.35.2-gke.1842000 以上版本。
    • 已啟用 GKE Dataplane V2。
    • 機型必須為 e2-standard-4 以上。
    • 叢集必須新增至機群。
    • 叢集必須啟用 Gateway API 和 Workload Identity。

  2. 在現有叢集上啟用環境網路：

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

    現在有兩個 DaemonSet 在 gke-managed-ambient 命名空間中執行。

  3. 如要驗證，請將 CLI 指向叢集：

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

  4. 在 gke-managed-ambient 命名空間中取得 daemonset：

    kubectl get daemonset -n gke-managed-ambient

    輸出內容大致如下：

    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

註冊命名空間以使用周邊網路

請按照下列步驟部署範例應用程式，並在其命名空間中啟用環境流量重新導向：

  1. 部署範例應用程式：

    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

  2. 標記 ambient-test 命名空間，透過 GKE 微光代理啟用流量重新導向：

    kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient

  3. 確認命名空間中的個別 Pod 已設定流量重新導向：

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

    輸出內容大致如下：

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

  4. 測試用戶端到伺服器的流量：

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

  5. 如要確認明文流量是否流經 gke-ambient-proxy，請在 Logs Explorer 中檢查存取記錄，並搜尋 gke-ambient-node-proxy-accesslog：

    前往「Logs Explorer」頁面

  6. 視需要為命名空間中的工作負載啟用第 4 層指標產生功能：

    kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled

    啟用後，您就能透過 Network Services Monitoring 在 Cloud Monitoring 中查看工作負載指標。

為服務啟用 mTLS

為命名空間中的工作負載啟用流量重新導向功能後，請套用政策，強制執行加密、驗證和授權。

  1. 在伺服器端工作負載上設定寬鬆的 mTLS 政策：

    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

    這項政策可讓 Pod 接受 mTLS 和明文流量。請注意，寬鬆 mTLS 會使用流量監聽功能，偵測流量是否為 mTLS 或純文字。這會中斷使用自有 TLS 或「伺服器優先」通訊協定 (例如 MySQL) 的應用程式流量。

  2. 確認控制者已接受政策：

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

    輸出內容大致如下：

    [...]

    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

    控制器接受後，政策傳播作業最多可能需要三分鐘。 請等待三分鐘再繼續操作。

  3. 設定以服務為目標的用戶端 mTLS 政策：

    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.s3ns.svc.id.goog/ns/ambient-test/sa/server
EOF

    這項政策會將已註冊的用戶端設定為將 mTLS 流量傳送至伺服器服務。你可能需要等待至少兩分鐘，才能繼續下一個步驟。

  4. 確認控制者已接受政策：

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

    輸出內容大致如下：

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

  5. 測試用戶端到伺服器的流量：

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

    從已註冊環境網路的 Pod 到 ambient-test 命名空間中伺服器服務的流量，現在應會使用 mTLS。

  6. 如要確認連線是否使用 mTLS，請在 Logs Explorer 中檢查存取記錄，並搜尋自訂記錄名稱：

    前往「Logs Explorer」頁面

  7. 更新現有的 GCPServerTLSPolicy，將伺服器服務的 mode 從「Permissive」變更為「Strict」，這樣一來，工作負載 Pod 就不會再接受純文字流量：

    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

  8. 確認政策已獲接受：

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

    輸出內容大致如下：

    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

    現在，系統會拒絕傳送至伺服器服務的所有純文字流量。

  9. 如要確認系統現在會拒絕純文字流量，請從未註冊環境網路的用戶端，將流量傳送至伺服器服務：

    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

    這個連線應該會失敗，並顯示類似下列的訊息：

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

設定第 4 層授權政策

如要強制執行以身分為依據的授權，工作負載擁有者會在政策選取器中指定 Pod 標籤。命名空間擁有者會套用命名空間範圍的政策，而不使用選取器。

  1. 套用下列政策，強制規定只有用戶端可以與伺服器通訊：

    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.s3ns.svc.id.goog/ns/ambient-test/sa/client
EOF

    這項政策會強制套用至 ambient-test 命名空間中伺服器 Pod 的流量。這可確保只允許來自 SPIFFE 身分 spiffe://PROJECT_ID.s3ns.svc.id.goog/ns/ambient-test/sa/client 的來源流量。

  2. 從用戶端服務帳戶傳送範例要求，確認政策執行允許。

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

  3. 從伺服器服務帳戶傳送範例要求，確認政策強制執行「不允許」。

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

    輸出內容大致如下：

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

  4. 您可以使用記錄檔探索工具查看授權強制執行記錄。前往 Cloud de Confiance 控制台的「Logs Explorer」頁面。

    前往「Logs Explorer」頁面