プロジェクト間のネットワーク ポリシーを作成する

このページでは、Google Distributed Cloud（GDC）エアギャップでプロジェクト間のトラフィック ネットワーク ポリシーを構成する手順について説明します。

プロジェクト間のトラフィックとは、異なるプロジェクト Namespace のサービスとワークロード間の通信を指しますが、同じ組織内に存在します。

プロジェクト内のサービスとワークロードは、デフォルトで外部のサービスとワークロードから分離されています。ただし、異なるプロジェクト Namespace に属し、同じ組織内のサービスとワークロードは、クロス プロジェクト トラフィック ネットワーク ポリシーを適用することで相互に通信できます。

デフォルトでは、これらのポリシーはすべてのゾーンにグローバルに適用されます。GDC ユニバースのグローバル リソースの詳細については、マルチゾーンの概要をご覧ください。

単一ゾーン内でプロジェクト間のトラフィックを適用するには、単一ゾーンのワークロード レベルのクロス プロジェクト ポリシーを作成するをご覧ください。

始める前に

クロス プロジェクト トラフィック ネットワーク ポリシーを構成するには、次のものが必要です。

  • 必要な ID とアクセスロール。特定のプロジェクトのポリシーを管理するには、project-networkpolicy-admin ロールが必要です。すべてのゾーンにまたがるポリシーを管理する必要があるマルチゾーン環境では、global-project-networkpolicy-admin ロールが必要です。詳細については、事前定義ロールとアクセスを準備するをご覧ください。
  • 既存のプロジェクト。詳細については、プロジェクトを作成するをご覧ください。
  • 下り（外向き）ネットワーク ポリシーの場合は、プロジェクトのデータ漏洩保護も無効にする必要があります。

クロスプロジェクト ポリシーを作成する

上り（内向き）または下り（外向き）のプロジェクト間トラフィック ポリシーを定義して、プロジェクト間の通信を管理できます。

内向き（上り）クロスプロジェクト ポリシーを作成する

組織内の別のプロジェクトのワークロードからプロジェクトのワークロードまたはサービスへの接続を許可するには、上り（内向き）ファイアウォール ルールを構成する必要があります。

このポリシーは、組織内のすべてのゾーンに適用されます。

次の手順に沿って、新しいファイアウォール ルールを作成し、別のプロジェクトのワークロードからの上り（内向き）トラフィックを許可します。

コンソール

  1. 構成するプロジェクトの GDC コンソールで、ナビゲーション メニューの [ネットワーキング] > [ファイアウォール] に移動して、[ファイアウォール] ページを開きます。
  2. アクションバーの [作成] をクリックして、新しいファイアウォール ルールの作成を開始します。

  3. [ファイアウォール ルールの詳細] ページで、次の情報を入力します。

    1. [名前] フィールドに、ファイアウォール ルールの有効な名前を入力します。
    2. [トラフィックの方向] セクションで、[上り（内向き）] を選択して、他のプロジェクトのワークロードからの上り（内向き）トラフィックを許可します。
    3. [ターゲット] セクションで、次のいずれかのオプションを選択します。
      • すべてのユーザー ワークロード: 構成しているプロジェクトのワークロードへの接続を許可します。
      • サービス: このファイアウォール ルールが、構成しているプロジェクト内の特定のサービスをターゲットにしていることを示します。
    4. ターゲットがプロジェクト サービスの場合は、[サービス] プルダウン メニューの利用可能なサービスのリストからサービスの名前を選択します。
    5. [From] セクションで、次の 2 つのオプションのいずれかを選択します。
      • すべてのプロジェクト: 同じ組織のすべてのプロジェクトのワークロードからの接続を許可します。
      • [別のプロジェクト] と [すべてのユーザー ワークロード]: 同じ組織の別のプロジェクトのワークロードからの接続を許可します。
    6. 別のプロジェクトからのみワークロードを転送する場合は、[プロジェクト ID] プルダウン メニューのプロジェクトのリストから、アクセス可能なプロジェクトを選択します。
    7. ターゲットがすべてのユーザー ワークロードの場合は、[プロトコルとポート] セクションで次のいずれかのオプションを選択します。
      • すべて許可: 任意のプロトコルまたはポートを使用した接続を許可します。
      • 指定したプロトコルとポート: 上り（内向き）ファイアウォール ルールの対応するフィールドで指定したプロトコルとポートのみを使用する接続を許可します。

  4. [ファイアウォール ルールの詳細] ページで、[作成] をクリックします。

これで、同じ組織内の他のプロジェクトのワークロードからの接続が許可されました。ファイアウォール ルールを作成すると、[ファイアウォール] ページの表にルールが表示されます。

逆方向の相互内向きポリシーを作成するには、他のプロジェクトの GDC コンソールにアクセスして、プロセスを繰り返します。

API

次のポリシーでは、PROJECT_1 プロジェクトのワークロードが PROJECT_2 プロジェクトのワークロードからの接続と、同じフローの戻りトラフィックを許可します。ポリシーを適用します。

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-inbound-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

GLOBAL_API_SERVER は、グローバル API サーバーの kubeconfig パスに置き換えます。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインをご覧ください。

上記のコマンドでは、PROJECT_2 から PROJECT_1 へのアクセスは許可されますが、PROJECT_1 から PROJECT_2 への接続は許可されません。後者の場合は、PROJECT_2 プロジェクトに相互ポリシーが必要です。相互主義ポリシーを適用します。

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-inbound-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

PROJECT_1 と PROJECT_2 との間の接続が許可されるようになりました。

外向き（下り）クロスプロジェクト ポリシーを作成する

1 つのプロジェクトのワークロードが別のプロジェクトのワークロードからの接続を許可するように、上り（内向き）のプロジェクト間トラフィック ポリシーを付与すると、同じフローの戻りトラフィックも付与されます。したがって、元のプロジェクトに下り（外向き）のプロジェクト間トラフィック ネットワーク ポリシーは必要ありません。

次の手順に沿って、新しいファイアウォール ルールを作成し、プロジェクト内のワークロードからのアウトバウンド トラフィックを許可します。

コンソール

  1. 構成するプロジェクトの GDC コンソールで、ナビゲーション メニューの [ネットワーキング] > [ファイアウォール] に移動して、[ファイアウォール] ページを開きます。
  2. アクションバーで [作成] をクリックして、新しいファイアウォール ルールを作成します。

  3. [ファイアウォール ルールの詳細] ページで、次の情報を入力します。

    1. [名前] フィールドに、ファイアウォール ルールの有効な名前を入力します。
    2. [トラフィックの方向] セクションで、[下り（外向き）] を選択して、このファイアウォール ルールがアウトバウンド トラフィックを制御していることを示します。
    3. [ターゲット] セクションで、次のいずれかのオプションを選択します。
      • すべてのユーザー ワークロード: 構成しているプロジェクトのワークロードからの接続を許可します。
      • サービス: このファイアウォール ルールが、構成しているプロジェクト内の特定のサービスをターゲットにしていることを示します。
    4. ターゲットがプロジェクト サービスの場合は、[サービス] プルダウン メニューの利用可能なサービスのリストからサービスの名前を選択します。
    5. [宛先] セクションで、次のいずれかのオプションを選択します。
      • すべてのプロジェクト: 同じ組織のすべてのプロジェクトのワークロードへの接続を許可します。
      • [別のプロジェクト] と [すべてのユーザー ワークロード]: 同じ組織の別のプロジェクトのワークロードへの接続を許可します。
    6. ワークロードを別のプロジェクトにのみ転送する場合は、[プロジェクト ID] プルダウン メニューのプロジェクトのリストから、アクセス可能なプロジェクトを選択します。
    7. ターゲットがすべてのユーザー ワークロードである場合は、[プロトコルとポート] セクションで次のいずれかのオプションを選択します。
      • すべて許可: 任意のプロトコルまたはポートを使用した接続を許可します。
      • 指定したプロトコルとポート: 下り（外向き）ファイアウォール ルールの対応するフィールドで指定したプロトコルとポートのみを使用する接続を許可します。

  4. [ファイアウォール ルールの詳細] ページで、[作成] をクリックします。

これで、同じ組織内の他のプロジェクトのワークロードへの接続が許可されました。ファイアウォール ルールを作成すると、[ファイアウォール] ページの表にルールが表示されます。

逆方向の相互下り（外向き）ポリシーを作成するには、他のプロジェクトの GDC コンソールにアクセスして、プロセスを繰り返します。

API

次のポリシーでは、PROJECT_1 プロジェクトのワークロードが PROJECT_2 プロジェクトのワークロードへの接続を許可します。ポリシーを適用します。

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-outbound-traffic-to-PROJECT_2
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
EOF

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

  • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
  • PROJECT_1: トラフィックを受信するプロジェクトの名前。
  • PROJECT_2: トラフィックの送信元プロジェクトの名前。
  • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
  • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを受信しています。
  • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
  • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。

上記のコマンドは、PROJECT_1 から PROJECT_2 への外向き接続を許可しますが、PROJECT_2 から PROJECT_1 への接続は許可しません。後者の場合は、PROJECT_2 プロジェクトに相互ポリシーが必要です。相互主義ポリシーを適用します。

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-outbound-traffic-to-PROJECT_1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
EOF

下り（外向き）ワークロード レベルのクロスプロジェクト ポリシーを作成する

  • 外向きワークロード レベルのクロスプロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-cross-project-outbound-traffic-from-project-2-to-project-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを受信するプロジェクトの名前。
    • PROJECT_2: トラフィックの送信元プロジェクトの名前。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを送信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。

単一ゾーンのワークロード レベルのクロスプロジェクト ポリシーを作成する

ワークロード単位のネットワーク ポリシーは、単一のゾーンに沿って PNP を適用できます。特定のラベルを単一ゾーン内のワークロードに追加すると、そのゾーンのプロジェクト内または異なるプロジェクト内の個々のワークロード間の通信を制御できます。

単一ゾーンの内向きワークロード レベルのクロスプロジェクト ポリシーを作成する

  1. 単一ゾーンの Ingress ワークロード レベルのクロス プロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-inbound-traffic-from-project-2-to-project-1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを受信するプロジェクトの名前。
    • PROJECT_2: トラフィックの送信元プロジェクトの名前。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを受信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。
    • ZONE_SUBJECT_LABEL_KEY: サブジェクト ゾーンの選択に使用されるラベルのキー。例: zone、または region。
    • ZONE_SUBJECT_LABEL_VALUE: ZONE_SUBJECT_LABEL_KEY に関連付けられた値。トラフィックを受信するゾーンを指定します。たとえば、ZONE_SUBJECT_LABEL_KEY が zone で、ZONE_SUBJECT_LABEL_VALUE が us-central1-a の場合、ラベル zone: us-central1-a のワークロードがトラフィックを受信しています。
    • ZONE_PEER_LABEL_KEY: ピアに関連付けられたゾーンの選択に使用されるラベルのキー。
    • ZONE_PEER_LABEL_VALUE: ZONE_PEER_LABEL_KEY に関連付けられた値。

単一ゾーンの外向き（下り）ワークロード レベルのクロスプロジェクト ポリシーを作成する

  • 単一ゾーンの外向きワークロード レベルのクロスプロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-single-zone-cross-project-outbound-traffic-from-project-2-to-project-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
            ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_1
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
                ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを受信するプロジェクトの名前。
    • PROJECT_2: トラフィックの送信元プロジェクトの名前。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを送信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。
    • ZONE_SUBJECT_LABEL_KEY: サブジェクト ゾーンの選択に使用されるラベルのキー。例: zone、または region。
    • ZONE_SUBJECT_LABEL_VALUE: ZONE_SUBJECT_LABEL_KEY に関連付けられた値。たとえば、ZONE_SUBJECT_LABEL_KEY が zone で、ZONE_SUBJECT_LABEL_VALUE が us-central1-a の場合、ラベル zone: us-central1-a のワークロードがトラフィックを送信しています。
    • ZONE_PEER_LABEL_KEY: ピアに関連付けられたゾーンの選択に使用されるラベルのキー。
    • ZONE_PEER_LABEL_VALUE: ZONE_PEER_LABEL_KEY に関連付けられた値。

Standard クラスタのクロスプロジェクト ポリシーを作成する

Standard クラスタは、プロジェクト スコープの Kubernetes クラスタであり、より優れた制御、柔軟性、クラスタ管理者の権限を提供します。

Standard クラスタの内向き（上り）クロスプロジェクト ポリシーを作成する

  1. Standard クラスタ間で上り（内向き）クラスタ間ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: STANDARD_CLUSTER_1_PROJECT
  name: allow-ingress-from-standard-cluster-2-to-standard-cluster-1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_2_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • STANDARD_CLUSTER_1_PROJECT: トラフィックを受信する標準クラスタ プロジェクトの名前。
    • STANDARD_CLUSTER_2_PROJECT: トラフィックの送信元となる Standard クラスタ プロジェクトの名前。
    • STANDARD_CLUSTER_1_NAME: トラフィックを受信する Standard クラスタの名前。
    • STANDARD_CLUSTER_2_NAME: トラフィックの送信元となる Standard クラスタの名前。
    • SUBJECT_NAMESPACE: 標準クラスタのサブジェクト Namespace。
    • PEER_NAMESPACE: Standard クラスタのピア Namespace。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを受信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。

  2. Standard クラスタと共有クラスタ間の上り（内向き）クラスタ間ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: SHARED_CLUSTER_PROJECT
  name: allow-ingress-from-standard-cluster-to-shared-cluster
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • STANDARD_CLUSTER_PROJECT: 標準クラスタ プロジェクトの名前。
    • SHARED_CLUSTER_PROJECT: 共有クラスタ プロジェクトの名前。
    • STANDARD_CLUSTER_NAME: Standard クラスタの名前。
    • PEER_NAMESPACE: Standard クラスタのピア Namespace。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを受信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。

Standard クラスタの外向き（下り）クロスプロジェクト ポリシーを作成する

  1. Standard クラスタ間に下り（外向き）クラスタ間ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: STANDARD_CLUSTER_2_PROJECT
  name: allow-egress-from-standard-cluster-2-to-standard-cluster-1
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_2_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - STANDARD_CLUSTER_1_PROJECT
        workloadSelector:
          labelSelector:
            clusters:
              matchLabels:
                kubernetes.io/metadata.name: STANDARD_CLUSTER_1_NAME
            namespaces:
              matchLabels:
                kubernetes.io/metadata.name: PEER_NAMESPACE
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • STANDARD_CLUSTER_1_PROJECT: トラフィックを受信する標準クラスタ プロジェクトの名前。
    • STANDARD_CLUSTER_2_PROJECT: トラフィックの送信元となる Standard クラスタ プロジェクトの名前。
    • STANDARD_CLUSTER_1_NAME: トラフィックを受信する Standard クラスタの名前。
    • STANDARD_CLUSTER_2_NAME: トラフィックの送信元となる Standard クラスタの名前。
    • SUBJECT_NAMESPACE: 標準クラスタのサブジェクト Namespace。
    • PEER_NAMESPACE: Standard クラスタのピア Namespace。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを送信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。

  2. Standard クラスタと共有クラスタ間の下り（外向き）クラスタ間ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: STANDARD_CLUSTER_PROJECT
  name: allow-egress-from-standard-cluster-to-shared-cluster
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: SUBJECT_NAMESPACE
        workloads:
          matchLabels:
            SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - SHARED_CLUSTER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                PEER_LABEL_KEY: PEER_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • STANDARD_CLUSTER_PROJECT: 標準クラスタ プロジェクトの名前。
    • SHARED_CLUSTER_PROJECT: 共有クラスタ プロジェクトの名前。
    • STANDARD_CLUSTER_NAME: Standard クラスタの名前。
    • SUBJECT_NAMESPACE: 標準クラスタのサブジェクト Namespace。
    • SUBJECT_LABEL_KEY: サブジェクト ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィックを送信しています。
    • PEER_LABEL_KEY: ピア ワークロードの選択に使用されるラベルのキー。
    • PEER_LABEL_VALUE: PEER_LABEL_KEY に関連付けられた値。