高可用性コンテナ アプリケーションをデプロイする

コンソール

1. ナビゲーション メニューで、[Kubernetes Engine] > [クラスタ] を選択します。

2. [クラスタを作成] をクリックします。

3. [名前] フィールドに、クラスタの名前を指定します。

4. クラスタの Kubernetes バージョンを選択します。

5. クラスタを作成するゾーンを選択します。

6. [プロジェクトを接続] をクリックし、既存のプロジェクトを選択してクラスタに接続します。オンにして [保存] をクリックします。クラスタの作成後に、[プロジェクトの詳細] ページでプロジェクトを関連付けたり、関連付けを解除したりできます。コンテナ ワークロードをデプロイする前に、クラスタにプロジェクトを関連付ける必要があります。

7. [次へ] をクリックします。

8. クラスタのネットワーク設定を構成します。クラスタの作成後にこれらのネットワーク設定を変更することはできません。Kubernetes クラスタでサポートされているデフォルトのインターネット プロトコルは、インターネット プロトコル バージョン 4（IPv4）のみです。

   1. ロードバランサの IP アドレス プールのサイズ（20 など）を指定します。

   2. 使用するサービス CIDR（クラスレス ドメイン間ルーティング）を選択します。ロードバランサなどのデプロイされたサービスには、この範囲から IP アドレスが割り当てられます。

   3. 使用する Pod CIDR を選択します。クラスタは、この範囲から Pod と VM に IP アドレスを割り当てます。

   4. [次へ] をクリックします。

9. クラスタ用に自動生成されたデフォルトのノードプールの詳細を確認します。edit [編集] をクリックして、デフォルトのノードプールを変更します。

10. 追加のノードプールを作成するには、[ノードプールを追加] を選択します。デフォルトのノードプールを編集するときや、新しいノードプールを追加するときに、次のオプションを使用してカスタマイズします。

    1. ノードプールに名前を割り当てます。ノードプールの作成後に名前を変更することはできません。
    2. ノードプール内に作成するワーカーノードの数を指定します。

    3. ワークロードの要件に最も適したマシンクラスを選択します。次の設定のリストを表示します。

       • マシンタイプ
       • CPU
       • メモリ

    4. [保存] をクリックします。

    5. [作成] をクリックしてクラスタを作成します。

11. GDC ユニバース内の各ゾーンに対して、上記の手順を繰り返します。HA 戦略で必要なすべてのゾーンに Kubernetes クラスタが存在することを確認します。

API

API を直接使用して新しい Kubernetes クラスタを作成するには、各 GDC ゾーンにカスタム リソースを適用します。

1. Cluster カスタム リソースを作成し、ゾーンの Management API サーバーにデプロイします。

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF \
   apiVersion: cluster.gdc.goog/v1
   kind: Cluster
   metadata:
     name: CLUSTER_NAME
     namespace: platform
   spec:
     clusterNetwork:
       podCIDRSize: POD_CIDR
       serviceCIDRSize: SERVICE_CIDR
     initialVersion:
       kubernetesVersion: KUBERNETES_VERSION
     loadBalancer:
       ingressServiceIPSize: LOAD_BALANCER_POOL_SIZE
     nodePools:
     - machineTypeName: MACHINE_TYPE
       name: NODE_POOL_NAME
       nodeCount: NUMBER_OF_WORKER_NODES
       taints: TAINTS
       labels: LABELS
       acceleratorOptions:
         gpuPartitionScheme: GPU_PARTITION_SCHEME
     releaseChannel:
       channel: UNSPECIFIED
   EOF
   

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

   • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。詳細については、ゾーン コンテキストに切り替えるをご覧ください。
   • CLUSTER_NAME: クラスタの名前。クラスタ名の末尾を -system にすることはできません。-system 接尾辞は、GDC によって作成されたクラスタ用に予約されています。
   • POD_CIDR: Pod の仮想 IP アドレス（VIP）が割り当てられるネットワーク範囲のサイズ。設定しない場合、デフォルト値の 21 が使用されます。
   • SERVICE_CIDR: サービス VIP が割り当てられるネットワーク範囲のサイズ。設定されていない場合、デフォルト値の 23 が使用されます。
   • KUBERNETES_VERSION: クラスタの Kubernetes バージョン（1.26.5-gke.2100 など）。構成可能な Kubernetes バージョンを一覧表示するには、クラスタで使用可能な Kubernetes バージョンを一覧表示するをご覧ください。
   • LOAD_BALANCER_POOL_SIZE: ロードバランサ サービスで使用される重複しない IP アドレスプールのサイズ。設定されていない場合、デフォルト値の 20 が使用されます。
   • MACHINE_TYPE: ノードプールのワーカーノードのマシンタイプ。構成可能な内容については、使用可能なマシンタイプをご覧ください。
   • NODE_POOL_NAME: ノードプールの名前。
   • NUMBER_OF_WORKER_NODES: ノードプールにプロビジョニングするワーカーノードの数。
   • TAINTS: このノードプールのノードに適用する taint。このフィールドは省略できます。
   • LABELS: このノードプールのノードに適用するラベル。Key-Value ペアのリストが含まれています。このフィールドは省略可能です。
   • GPU_PARTITION_SCHEME: GPU ワークロード（mixed-2 など）を実行している場合の GPU パーティショニング スキーム。このフィールドが設定されていない場合、GPU はパーティショニングされません。利用可能なマルチインスタンス GPU（MIG）プロファイルについては、サポートされている MIG プロファイルをご覧ください。

2. HA 戦略でコンテナ アプリケーションをホストするゾーンごとに、前の手順を繰り返します。

gdcloud

gdcloud CLI を使用して、Pod ワークロードをターゲットとする ILB を作成します。

この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。Backend カスタム リソースは、ゾーンにスコープ設定する必要があります。

gcloud CLI を使用して ILB を作成するには、次の操作を行います。

1. ポッドが実行されている各ゾーンにゾーン Backend リソースを作成して、ILB のエンドポイントを定義します。

   gdcloud compute backends create BACKEND_NAME \
       --labels=LABELS \
       --project=PROJECT \
       --cluster=CLUSTER_NAME \
       --zone=ZONE
   

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

   • BACKEND_NAME: バックエンド リソースに選択した名前（my-backend など）。
   • LABELS: このバックエンド リソースに使用する Pod 間のエンドポイントを定義するセレクタ（app=web など）。
   • PROJECT: プロジェクトの名前。
   • CLUSTER_NAME: 定義されたセレクタのスコープが制限される Kubernetes クラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
   • ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドに対してゾーンフラグをプリセットするには、gdcloud config set core/zone ZONE を実行します。ゾーンフラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。

   この手順を GDC ユニバースの各ゾーンで繰り返します。

2. グローバル BackendService リソースを作成します。

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
       --project=PROJECT \
       --target-ports=TARGET_PORTS \
       --global
   

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

   • BACKEND_SERVICE_NAME: バックエンド サービスの名前。
   • PROJECT: プロジェクトの名前。
   • TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは protocol:port:targetport 形式（TCP:80:8080 など）にする必要があります。このフィールドは省略可能です。

3. 各ゾーンで、前に作成した Backend リソースに BackendService リソースを追加します。

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
       --backend-zone=ZONE \
       --backend=BACKEND_NAME \
       --project=PROJECT \
       --global
   

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

   • BACKEND_SERVICE_NAME: グローバル バックエンド サービスの名前。
   • ZONE: バックエンドのゾーン。
   • BACKEND_NAME: ゾーン バックエンドの名前。
   • PROJECT: プロジェクトの名前。

   この手順は、以前に作成したゾーン バックエンドごとに行います。

4. サービスが利用可能な仮想 IP アドレス（VIP）を定義する内部 ForwardingRule リソースを作成します。

   gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
       --backend-service=BACKEND_SERVICE_NAME \
       --cidr=CIDR \
       --ip-protocol-port=PROTOCOL_PORT \
       --load-balancing-scheme=INTERNAL \
       --project=PROJECT \
       --global
   

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

   • FORWARDING_RULE_INTERNAL_NAME: 転送ルールの名前。
   • CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
   • PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

5. 構成された ILB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

   1. 割り当てられた VIP を取得するには、転送ルールを説明します。

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global
      

   2. 転送ルールのフィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT
      

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

   • FORWARDING_RULE_VIP: 転送ルールの VIP。
   • PORT: 転送ルールのポート番号。

API

KRM API を使用して、コンテナ ワークロードをターゲットとする ILB を作成します。この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してグローバル ILB を作成する手順は次のとおりです。

1. Backend リソースを作成して、ILB のエンドポイントを定義します。コンテナ ワークロードが配置されているゾーンごとに Backend リソースを作成します。

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

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

   • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。詳細については、ゾーン コンテキストに切り替えるをご覧ください。
   • PROJECT: プロジェクトの名前。
   • BACKEND_NAME: Backend リソースの名前。
   • CLUSTER_NAME: 定義されたセレクタのスコープが制限される Kubernetes クラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
   • APP_NAME: コンテナ アプリケーションの名前。

   各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。

2. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。HealthCheck リソースを含めてください。

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
     targetPorts:
     - port: PORT
       protocol: PROTOCOL
       targetPort: TARGET_PORT
   EOF
   

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

   • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。
   • PROJECT: プロジェクトの名前。
   • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
   • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。
   • BACKEND_NAME: ゾーン Backend リソースの名前。

   • ZONE: Backend リソースが存在するゾーン。backendRefs フィールドで複数のバックエンドを指定できます。次に例を示します。

     - name: my-backend-1
       zone: us-east1-a
     - name: my-backend-2
       zone: us-east1-b
     

     targetPorts フィールドは省略可能です。このリソースは、この BackendService リソースが変換するポートを一覧表示します。このオブジェクトを使用する場合は、次の値を指定します。

   • PORT: サービスによって公開されるポート。

   • PROTOCOL: トラフィックが一致する必要があるレイヤ 4 プロトコル。TCP と UDP のみがサポートされます。

   • TARGET_PORT: 値の変換先となるポート（8080 など）。値は、特定のオブジェクト内で繰り返すことはできません。

     targetPorts の例を次に示します。

     targetPorts:
       - port: 80
         protocol: TCP
         targetPort: 8080
     

3. サービスが利用可能な仮想 IP アドレス（VIP）を定義する内部 ForwardingRule リソースを作成します。

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleInternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_INTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

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

   • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。
   • PROJECT: プロジェクトの名前。
   • FORWARDING_RULE_INTERNAL_NAME: ForwardingRuleInternal リソースに選択した名前。
   • CIDR: 転送ルールに使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
   • PORT: 転送ルールで公開するポート。ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

   • PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。

     ports:
     - port: 80
       protocol: TCP
     

4. 構成された ILB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

   1. VIP を取得します。

      kubectl get forwardingruleinternal -n PROJECT
      

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

      NAME           BACKENDSERVICE                  CIDR              READY
      ilb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. 転送ルールのフィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックをテストします。

      curl http://FORWARDING_RULE_VIP:PORT
      

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

      • FORWARDING_RULE_VIP: 転送ルールの VIP。
      • PORT: 転送ルールのフィールドのポート番号。

gdcloud

gdcloud CLI を使用して、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットとするグローバル ELB を作成します。Backend カスタム リソースはゾーンにスコープ設定する必要があります。

1. ELB サービスが機能するには、独自のカスタマイズされた ProjectNetworkPolicy データ転送をポリシーで構成して適用し、この ELB サービスのワークロードへのトラフィックを許可する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開します。このため、外部トラフィックがワークロード ポート（8080 など）にアクセスできるように、明示的なネットワーク ポリシーが必要です。

   この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-inbound-traffic-from-external
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
     - from:
       - ipBlock:
           cidr: CIDR
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

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

   • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。グローバル API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
   • PROJECT: プロジェクトの名前。
   • CIDR: ELB にアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織間のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。
   • PORT: ロードバランサの背後にある Pod のバックエンド ポート。この値は、Service リソースのマニフェストの .spec.ports[].targetPortfield フィールドにあります。このフィールドは省略可能です。

   この構成により、プロジェクト内のすべてのリソースが指定された CIDR 範囲にアクセスできるようになります。

2. 各ゾーンに Backend リソースを作成して、ELB のエンドポイントを定義します。

   gdcloud compute backends create BACKEND_NAME \
     --labels=LABELS \
     --project=PROJECT \
     --cluster=CLUSTER_NAME \
     --zone=ZONE
   

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

   • BACKEND_NAME: バックエンド リソースの名前（my-backend など）。
   • LABELS: このバックエンド リソースに使用する Pod 間のエンドポイントを定義するセレクタ（app=web など）。
   • PROJECT: プロジェクトの名前。
   • CLUSTER_NAME: 定義されたセレクタのスコープが制限される Kubernetes クラスタ。このフィールドが指定されていない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
   • ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドに対してゾーンフラグをプリセットするには、gdcloud config set core/zone ZONE を実行します。ゾーンフラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。

   各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。

3. グローバル BackendService リソースを作成します。

   gdcloud compute backend-services create BACKEND_SERVICE_NAME \
     --project=PROJECT \
     --target-ports=TARGET_PORTS \
     --health-check=HEALTH_CHECK_NAME \
     --global
   

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

   • BACKEND_SERVICE_NAME: このバックエンド サービスに選択した名前。
   • PROJECT: プロジェクトの名前。
   • TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは、TCP:80:8080 などの protocol:port:targetport 形式にする必要があります。このフィールドは省略可能です。
   • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。

4. グローバル BackendService リソースを、前に作成したゾーン Backend リソースに追加します。

   gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --backend=BACKEND_NAME \
     --backend-zone=ZONE \
     --project=PROJECT \
     --global
   

   この手順は、以前に作成したゾーン バックエンドごとに行います。

5. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

   gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
     --backend-service=BACKEND_SERVICE_NAME \
     --cidr=CIDR \
     --ip-protocol-port=PROTOCOL_PORT \
     --load-balancing-scheme=EXTERNAL \
     --project=PROJECT \
     --global
   

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

   • FORWARDING_RULE_EXTERNAL_NAME: 転送ルールの名前。
   • CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
   • PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
   • PROJECT: プロジェクトの名前。

6. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

   1. 割り当てられた VIP を取得するには、転送ルールを説明します。

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME
      

   2. 転送ルールの PROTOCOL_PORT フィールドで指定されたポートの VIP への curl リクエストでトラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT
      

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

      • FORWARDING_RULE_VIP: 転送ルールの VIP。
      • PORT: 転送ルールの PROTOCOL_PORT フィールドのポート番号。

API

KRM API を使用して、Pod ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してゾーン ELB を作成する手順は次のとおりです。

1. ELB サービスが機能するには、独自のカスタマイズされた ProjectNetworkPolicy データ転送をポリシーで構成して適用し、この ELB サービスのワークロードへのトラフィックを許可する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開します。このため、外部トラフィックがワークロード ポート（8080 など）にアクセスできるように、明示的なネットワーク ポリシーが必要です。

   この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: allow-inbound-traffic-from-external
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
     ingress:
     - from:
       - ipBlock:
           cidr: CIDR
       ports:
       - protocol: TCP
         port: PORT
   EOF
   

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

   • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。グローバル API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
   • PROJECT: プロジェクトの名前。
   • CIDR: ELB にアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織間のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。
   • PORT: ロードバランサの背後にある Pod のバックエンド ポート。この値は、Service リソースのマニフェストの .spec.ports[].targetPortfield フィールドにあります。このフィールドは省略可能です。

2. Backend リソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに Backend リソースを作成します。

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: Backend
   metadata:
     namespace: PROJECT
     name: BACKEND_NAME
   spec:
     clusterName: CLUSTER_NAME
     endpointsLabels:
       matchLabels:
         app: APP_NAME
   EOF
   

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

   • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。ターゲット ゾーンの API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
   • PROJECT: プロジェクトの名前。
   • BACKEND_NAME: Backend リソースの名前。
   • CLUSTER_NAME: 定義されたセレクタのスコープが制限される Kubernetes クラスタ。このフィールドを指定しない場合、指定されたラベルを持つすべてのエンドポイントが選択されます。このフィールドは省略可能です。
   • APP_NAME: コンテナ アプリケーションの名前。

   各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。

3. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: BackendService
   metadata:
     namespace: PROJECT
     name: BACKEND_SERVICE_NAME
   spec:
     backendRefs:
     - name: BACKEND_NAME
       zone: ZONE
     healthCheckName: HEALTH_CHECK_NAME
   EOF
   

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

   • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
   • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。Pod ワークロードの ELB を構成する場合は、このフィールドを含めないでください。
   • ZONE: Backend リソースが存在するゾーン。backendRefs フィールドで複数のバックエンドを指定できます。次に例を示します。

   - name: my-backend-1
     zone: us-east1-a
   - name: my-backend-2
     zone: us-east1-b
   

4. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ForwardingRuleExternal
   metadata:
     namespace: PROJECT
     name: FORWARDING_RULE_EXTERNAL_NAME
   spec:
     cidrRef: CIDR
     ports:
     - port: PORT
       protocol: PROTOCOL
     backendServiceRef:
       name: BACKEND_SERVICE_NAME
   EOF
   

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

   • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal リソースに選択した名前。
   • CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
   • PORT: 転送ルールで公開するポート。ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
   • PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。

   ports:
   - port: 80
     protocol: TCP
   

5. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックをテストします。

   1. プロジェクトの VIP を取得します。

      kubectl get forwardingruleexternal -n PROJECT
      

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

      NAME           BACKENDSERVICE                  CIDR              READY
      elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True
      

   2. 転送ルールの PORT フィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT
      

      FORWARDING_RULE_VIP:PORT は、転送ルールの VIP とポート（192.0.2.0:80 など）に置き換えます。