プロジェクトのデフォルトの下り（外向き）NAT を管理する

このページでは、ワークロードが組織外に接続できるようにするために使用できる、非推奨となったプロジェクトのデフォルトの下り（外向き）NAT 構成について説明します。このページには、推奨ソリューションである Cloud NAT に移行する方法も記載されています。

概要

このページでは、（非推奨の）プロジェクトのデフォルトの下り（外向き）NAT 構成オプションを使用して、ワークロードが組織外に送信されるようにするために、プロジェクト内の仮想マシン（VM）または Pod で実行する必要がある下り（外向き）接続アクションについて説明します。

この手順では、必要なラベルをデプロイに追加して、アウトバウンド トラフィックを明示的に有効にし、ワークロードが組織外で通信できるようにする方法を示します。

デフォルトでは、Google Distributed Cloud（GDC）エアギャップは、プロジェクト内のワークロードが組織外に出るのをブロックします。プラットフォーム管理者（PA）がプロジェクトのデータ漏洩保護を無効にしている場合、ワークロードは組織を終了できます。PA は、プロジェクトにラベル networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true" を追加することで、これを行うことができます。データ漏洩保護を無効にするだけでなく、アプリケーション オペレーター（AO）は、ポッドのワークロードにラベル egress.networking.gke.io/enabled: true を追加して、そのポッドの下り（外向き）接続を有効にする必要があります。プロジェクトに既知の IP アドレスを割り当てて使用すると、組織からのアウトバウンド トラフィックに対して送信元ネットワーク アドレス変換（NAT）が実行されます。

Pod または VM のワークロードからの下り（外向き）接続を管理できます。

Pod 内のワークロードからのアウトバウンド トラフィックを管理する

下り（外向き）接続用に Pod のワークロードを構成するには、まずプロジェクトでデータ漏洩保護が無効になっていることを確認する必要があります。次に、Pod に egress.networking.gke.io/enabled: true ラベルが追加されていることを確認します。Deployment などの上位レベルのコンストラクトまたは Daemonset コンストラクトを使用して Pod のセットを管理している場合は、これらの仕様で Pod ラベルを構成する必要があります。

次の例は、マニフェスト ファイルから Deployment を作成する方法を示しています。サンプル ファイルの labels フィールドには、プロジェクトからのアウトバウンド トラフィックを明示的に有効にする値 egress.networking.gke.io/enabled: true が含まれています。このラベルは Deployment 内の各 Pod に追加され、Pod 内のワークロードが組織から離脱できるようになります。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  replicas: NUMBER_OF_REPLICAS
  selector:
    matchLabels:
      run: APP_NAME
  template:
    metadata:
      labels: # The labels given to each pod in the deployment, which are used
              # to manage all pods in the deployment.
        run: APP_NAME
        egress.networking.gke.io/enabled: true
    spec: # The pod specification, which defines how each pod runs in the deployment.
      containers:
      - name: CONTAINER_NAME
        image: CONTAINER_IMAGE
EOF

次のように置き換えます。

  • USER_CLUSTER_KUBECONFIG: コンテナ ワークロードをデプロイするユーザー クラスタの kubeconfig ファイル。

  • DEPLOYMENT_NAME: コンテナ ワークロードをデプロイするユーザー クラスタの kubeconfig ファイル。

  • APP_NAME: デプロイ内で実行するアプリケーションの名前。

  • NUMBER_OF_REPLICAS: Deployment が管理する複製 Pod オブジェクトの数。

  • CONTAINER_NAME: コンテナの名前。

  • CONTAINER_IMAGE: コンテナ イメージの名前。REGISTRY_PATH/hello-app:1.0 など、コンテナ レジストリのパスとイメージのバージョンを含める必要があります。

次に例を示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      run: my-app
  template:
    metadata:
      labels:
        run: my-app
        egress.networking.gke.io/enabled: true
    spec:
      containers:
      - name: hello-app
        image: REGISTRY_PATH/hello-app:1.0

VM 内のワークロードからのアウトバウンド トラフィックを管理する

下り（外向き）接続用に VM のワークロードを構成するには、VM 構成に GDC コンソールを使用するか、VirtualMachineExternalAccess リソースを作成します。外部アクセスが可能な VM でデータ転送を有効にする方法については、VM に接続するの外部アクセスを有効にするをご覧ください。

Cloud NAT に移行する

バージョン 1.15 で Cloud NAT が利用可能になったため、プロジェクトごとのデフォルトのプロジェクト下り（外向き）NAT 構成は非推奨になります。ユーザーは、デフォルト プロジェクトの下り（外向き）NAT 構成から Cloud NAT に下り（外向き）構成を移行することをおすすめします。

デフォルト プロジェクトの下り（外向き）NAT と Cloud NAT には互換性がありません。つまり、特定の Pod または VM エンドポイントは、この 2 つのうちの 1 つしか使用できません。エンドポイントをある構成から別の構成に移行するには、一方の構成でエンドポイントを無効にしてから、もう一方の構成で有効にする必要があります。

移行を開始するには、移行するエンドポイントの古い構成を無効にします。これには次の 2 つの方法があります。

  • プロジェクト全体のプロジェクトのデフォルトの下り（外向き）NAT を無効にする: ラベル networking.gdc.goog/allocate-egress-ip: "false" をプロジェクトに割り当てることで、プロジェクト内のすべてのエンドポイントのプロジェクトのデフォルトの下り（外向き）NAT を無効にします。
  • エンドポイントごとにプロジェクトのデフォルトの下り（外向き）NAT を無効にする: Pod または VM からラベル egress.networking.gke.io/enabled:"true" を削除して、特定の Pod または VM エンドポイントのプロジェクトのデフォルトの下り（外向き）NAT を無効にします。

移行を続行するには、各エンドポイントがデフォルトの外向き NAT から削除されるたびに、選択したゲートウェイのラベルセレクタと一致するラベルをエンドポイントに追加して、Cloud NAT ゲートウェイに追加します。

Cloud NAT の設定方法については、Cloud NAT と次のページをご覧ください。

下り（外向き）IP のトラッキング

デフォルトの下り（外向き）NAT では、下り（外向き）トラフィックの NAT に使用される下り（外向き）IP がプロジェクトのステータスに含まれます。Cloud NAT を使用すると、プロジェクト オブジェクトに下り（外向き）IP は含まれません。代わりに、ゲートウェイに割り当てられたサブネットを一覧表示することで、Cloud NAT ゲートウェイで使用されている IP を一覧表示できます。