標準クラスタの Cloud NAT ゲートウェイ

Google Distributed Cloud(GDC)エアギャップは、標準クラスタをサポートしています。これは、アプリケーション オペレータ グループによって管理される単一プロジェクトのセルフサービス Kubernetes クラスタで、カスタム ワークロードの柔軟性を高めます。このページでは、標準クラスタの Cloud NAT を設定する方法について説明します。また、このクラスタタイプの NAT 構成に関する制約と制限についても説明します。

始める前に

ゲートウェイを設定する前に、適切な Identity and Access Management(IAM)権限を取得し、プロジェクトに適切なネットワーク ポリシーがあることを確認して、下り(外向き)を有効にする必要があります。

詳細については、Cloud NAT を始める前にをご覧ください。

Cloud NAT ゲートウェイは、外部 leaf サブネットを入力として使用します。Cloud NAT の外部サブネットの構成の詳細については、Cloud NAT の外部サブネットを作成するをご覧ください。

概要

標準クラスタの Cloud NAT ゲートウェイの設定を示す図

Cloud NAT ゲートウェイは、標準クラスタで実行されているワークロードの下り(外向き)トラフィックを処理するように、次の 2 つの方法で構成できます。

  • プロジェクト スコープのゲートウェイ: プロジェクト内のクラスタのすべてのワークロード トラフィックに適用されるゲートウェイ。これには、すべての共有クラスタと標準クラスタが含まれます。これは、Cloud NAT ゲートウェイを作成するで説明されている構成です。
  • クラスタ スコープの Gateway: 単一の指定された標準クラスタ内のワークロードにのみ適用される Gateway。このページで説明するゲートウェイ タイプです。

これらの 2 つの方法はワークロード専用であり、標準クラスタを構成するノードには適用されません。標準クラスタを形成するノードで Cloud NAT を有効にするには、標準クラスタ オブジェクトにラベル cluster.gdc.goog/enable-node-egress-to-outside-the-org: "true" を追加します。

Cloud NAT ゲートウェイを作成する

標準クラスタのゲートウェイを作成するプロセスは、プロジェクト スコープの Cloud NAT ゲートウェイの作成と同じです。

この例では、標準クラスタ Cloud NAT のクラスタ フィルタリング機能に焦点を当て、最初のシナリオと同様の設定を作成します。ただし、ゲートウェイを介してトラフィックを転送するエンドポイントが配置されている標準クラスタ user-vc-1 の名前を指定します。その結果、このゲートウェイはこの特定のクラスタにスコープ設定されます。

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:    # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:           # Mutable
  - subnet-1
  - subnet-2

この構成では、標準クラスタ user-vc-1 のすべての Namespace で app: aa ラベルが付いているすべてのワークロードが選択されます。

ゲートウェイのステータスを確認する

次の kubectl コマンドを実行して、ゲートウェイのステータスを確認します。

export MGMT_KUBECONFIG=<path_to_management_kubeconfig>
kubectl get cloudnatgateways gateway-1 -n project-1 --kubeconfig "${MGMT_KUBECONFIG:?}"

正しく構成されている場合、Cloud NAT ゲートウェイのステータス条件フィールドには、次の出力例に示すように、タイプ Ready の条件が true に設定され、サブネットが OK としてマークされていることが表示されます。

apiVersion: networking.gdc.goog/v1
kind: CloudNATGateway
metadata:
  namespace: project-1
  name: gateway-1
spec:
  workloadSelector:       # Immutable
    labelSelector:
      workloads:
        matchLabels:
          app: aa
      clusters:
        matchLabels:
          kubernetes.io/metadata.name: user-vc-1
  subnetRefs:       # Mutable
  - subnet-1
  - subnet-2
status:
  conditions:
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: SubnetsReady
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: PerimeterConfigurationReady
  - lastTransitionTime: "2025-08-20T21:31:36Z"
    message: ""
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: EgressRoutesReady
  subnets:
  - name: subnet-1
    status: OK
  - name: subnet-2
    status: OK

テスト トラフィック

標準クラスタのゲートウェイに割り当てられた Pod または VM のいずれかから、外部エンドポイントに対して curl コマンドを発行して、トラフィックをテストします。受信エンドポイントには、ゲートウェイに関連付けられた下り(外向き)IP のいずれかからのパケットが表示されます。同じラベルを持つ共有クラスタ内のエンドポイントは、このゲートウェイを使用してトラフィックを送信できません。

クラスタ固有のゲートウェイ構成の制約

クラスタ スコープのゲートウェイのワークロード ラベル マッチャー(workloadSelector.labelSelector.workloads.matchLabels)は、他のプロジェクト スコープのゲートウェイのワークロード ラベル マッチャーと重複してはなりません。Cloud NAT 構成の制約で説明したように、workloadSelector.labelSelector.workloads.matchLabels は同じプロジェクトとゾーン内のゲートウェイ間で重複してはなりません。

Cloud NAT 構成の制約に記載されている他の制約も、クラスタ スコープのゲートウェイ構成に適用されます。