Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

GKE アンビエントネットワーキングを準備する

Autopilot Standard

このページでは、新規または既存のクラスタでアンビエントネットワーキングを有効にする方法、アンビエントトラフィックのリダイレクトを有効にするために Namespace とワークロードを登録する方法、mTLS と認可ポリシーを構成する方法について説明します。

アンビエントネットワーキングのアーキテクチャ、メリット、機能について詳しくは、アンビエントネットワーキングの概要をご覧ください。

前提条件と制限事項

アンビエントネットワーキングを設定する前に、次の機能の制限事項、バージョンの要件、スコープの制限事項を確認してください。

GKE バージョン: GKE バージョン 1.35.2-gke.1842000 以降が必要です。
リージョンサポート: クラスタは、リージョン Cloud Service Mesh でサポートされているリージョンに作成する必要があります。
ワークロードの相互運用性: アンビエントネットワーキングに登録されたワークロードは、サイドカー挿入ワークロードやプライベートプレビューのプロキシレス gRPC と相互運用できません。
サポートされていない機能:
- Kubernetes Service の trafficDistribution フィールド。
- ヘッドレスサービス。
- GKE Sandbox（gVisor）。
セキュリティに関する注意: ノードで gke-ambient-nriplugin コンポーネントが使用できなくなると、インバウンドトラフィックの認証と認可の適用がバイパスされる可能性があります。

始める前に

Google Cloudで次の前提条件の設定手順を完了します。

プロジェクトを作成または選択します。

必要な 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

GKE 用のマネージドワークロード ID 認証を構成する。

新しいクラスタでアンビエントネットワーキングを有効にする

次のコマンドを実行して、アンビエントネットワーキングが有効になっている新しい GKE クラスタを作成します。

アンビエントネットワーキングを有効にして 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.svc.id.goog

gke-managed-ambient Namespace で 2 つの DaemonSet が実行されるようになりました。

既存のクラスタでアンビエントネットワーキングを有効にする

既存の GKE クラスタでアンビエントメッシュを有効にする手順は次のとおりです。

クラスタが次の要件を満たしていることを確認します。
- バージョン 1.35.2-gke.1842000 以降。
- GKE Dataplane V2 が有効になっている。
- マシンタイプは e2-standard-4 以上にする必要があります。
- クラスタはフリートに追加されている必要があります。
- クラスタで Gateway API と Workload Identity が有効になっている必要があります。
既存のクラスタでアンビエントネットワーキングを有効にします。
```
gcloud beta container clusters update CLUSTER_NAME \
    --enable-ambient-networking \
    --location=CLUSTER_LOCATION \
    --enable-fleet
```
gke-managed-ambient Namespace で 2 つの DaemonSet が実行されるようになりました。

確認するには、CLI をクラスタにポイントします。

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

gke-managed-ambient Namespace の 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

アンビエントネットワーキング用に Namespace を登録する

次の手順に沿って、サンプルアプリケーションをデプロイし、その Namespace でアンビエントトラフィックのリダイレクトを有効にします。

サンプルアプリケーションをデプロイします。

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

ambient-test Namespace にラベルを付けて、GKE アンビエントプロキシを介したトラフィックのリダイレクトを有効にします。
```
kubectl label namespace ambient-test networking.gke.io/dataplane-mode=ambient
```

Namespace 内の個々の Pod がトラフィックリダイレクト用に構成されていることを確認します。

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

出力は次のようになります。

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

クライアントからサーバーへのトラフィックをテストします。

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

プレーンテキストトラフィックが gke-ambient-proxy を通過していることを確認するには、ログエクスプローラでアクセスログを確認し、gke-ambient-node-proxy-accesslog を検索します。

[ログエクスプローラ] に移動
必要に応じて、Namespace 内のワークロードのレイヤ 4 指標の生成を有効にします。
```
kubectl label namespace ambient-test networking.gke.io/ambient-network-metrics=enabled
```
有効にすると、ワークロード指標はネットワークサービスモニタリングを介して Cloud Monitoring で使用できます。

サービスの mTLS を有効にする

Namespace のワークロードのトラフィックリダイレクトを有効にした後、ポリシーを適用して暗号化、認証、認可を適用します。

サーバーサイドワークロードに許可型の 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 などの「サーバーが最初に話す」プロトコルを使用するアプリケーショントラフィックが中断されます。

コントローラによってポリシーが承認されたことを確認します。

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 分かかることがあります。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.svc.id.goog/ns/ambient-test/sa/server
EOF
```
このポリシーは、登録されたクライアントがサーバー Service への mTLS トラフィックを発信するように構成します。次のステップに進む前に、少なくとも 2 分待つ必要がある場合があります。

コントローラによってポリシーが承認されたことを確認します。

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

クライアントからサーバーへのトラフィックをテストします。
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
アンビエントネットワーキングに登録された Pod から ambient-test Namespace のサーバーサービスへのトラフィックは、mTLS を使用するようになります。
接続で mTLS が使用されていることを確認するには、ログエクスプローラでアクセスログを確認し、カスタムログ名を検索します。

[ログエクスプローラ] に移動

既存の 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

ポリシーが承認されたことを確認します。

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

サーバーサービスへのプレーンテキストトラフィックは拒否されるようになります。

平文のトラフィックが拒否されるようになったことを確認するには、アンビエントネットワーキングに登録されていないクライアントからサーバーサービスにトラフィックを送信します。
```
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 認可ポリシーを設定する

ID ベースの認可を適用するには、ワークロードオーナーがポリシーセレクタで Pod ラベルを指定します。Namespace のオーナーは、セレクタなしで Namespace 全体にポリシーを適用します。

次のポリシーを適用して、クライアントのみがサーバーと通信できるようにします。

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

このポリシーは、ambient-test Namespace のサーバー Pod へのトラフィックに適用されます。これにより、SPIFFE ID spiffe://PROJECT_ID.svc.id.goog/ns/ambient-test/sa/client を持つ送信元からのトラフィックのみが許可されます。

クライアント サービスアカウントからサンプルリクエストを送信して、ポリシーの適用が許可されていることを確認します。
```
kubectl exec -it deploy/client -n ambient-test -- \
    /bin/curl -fsLS server.ambient-test.svc.cluster.local
```
サーバー サービスアカウントからサンプルリクエストを送信して、ポリシーの適用が許可されていないことを確認します。
```
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
```
ログエクスプローラを使用して、認可の適用ロギングを確認できます。 Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。

[ログエクスプローラ] に移動

GKE アンビエント ネットワーキングを準備する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

前提条件と制限事項

始める前に

新しいクラスタでアンビエント ネットワーキングを有効にする

既存のクラスタでアンビエント ネットワーキングを有効にする

アンビエント ネットワーキング用に Namespace を登録する

サービスの mTLS を有効にする

レイヤ 4 認可ポリシーを設定する

GKE アンビエントネットワーキングを準備する

新しいクラスタでアンビエントネットワーキングを有効にする

既存のクラスタでアンビエントネットワーキングを有効にする

アンビエントネットワーキング用に Namespace を登録する