内部ロードバランサを構成する

内部ロードバランサ（ILB）は、組織に割り当てられた内部 IP プールから組織内のサービスを公開します。ILB サービスには、組織外のエンドポイントからアクセスできません。

デフォルトでは、組織内の任意のクラスタから同じプロジェクト内の ILB サービスにアクセスできます。デフォルトのプロジェクト ネットワーク ポリシーでは、プロジェクト外からプロジェクト リソースにアクセスできません。この制限は ILB サービスにも適用されます。プラットフォーム管理者（PA）が、他のプロジェクトからプロジェクトへのアクセスを許可するプロジェクト ネットワーク ポリシーを構成すると、同じ組織内の他のプロジェクトからも ILB サービスにアクセスできるようになります。

始める前に

ILB を構成するには、次のものが必要です。

  • ロードバランサを構成するプロジェクトのオーナーである。詳細については、プロジェクトを作成するをご覧ください。

  • 必要な ID とアクセスロール:

    • 組織の IAM 管理者に、ロードバランサ管理者（load-balancer-admin）ロールを付与するよう依頼します。
    • グローバル ILB の場合は、組織 IAM 管理者にグローバル ロードバランサ管理者（global-load-balancer-admin）ロールの付与を依頼してください。詳細については、事前定義ロールの説明をご覧ください。

内部ロードバランサを作成する

グローバル ILB またはゾーン ILB を作成できます。グローバル ILB のスコープは GDC ユニバース全体に及びます。ゾーン ILB のスコープは、作成時に指定されたゾーンに限定されます。詳細については、グローバル ロードバランサとゾーン ロードバランサをご覧ください。

GDC で 3 つの異なる方法を使用して ILB を作成します。

  • gdcloud CLI を使用して、グローバル ILB またはゾーン ILB を作成します。
  • Networking Kubernetes Resource Model（KRM）API を使用して、グローバルまたはゾーン ILB を作成します。
  • Kubernetes クラスタで Kubernetes Service を直接使用します。このメソッドは、ゾーン ILB でのみ使用できます。

KRM API と gdcloud CLI を使用して、Pod または VM ワークロードをターゲットにできます。Kubernetes クラスタから Kubernetes Service を直接使用する場合は、Service オブジェクトが作成されたクラスタ内のワークロードのみをターゲットにできます。

ゾーン ILB を作成する

gcloud CLI、KRM API、または Kubernetes クラスタの Kubernetes Service を使用して、ゾーン ILB を作成します。

gdcloud

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

この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。

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

  1. ILB のエンドポイントを定義する Backend リソースを作成します。

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

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

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

  2. この ILB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ILB を構成する場合は、ILB のヘルスチェックを定義します。

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE

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

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
    • HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。デフォルト値は 5 です。このフィールドは省略可能です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。このフィールドは省略可能です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。このフィールドは省略可能です。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。このフィールドは省略可能です。
    • ZONE: この ILB を作成するゾーン。

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

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

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

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

  4. 前に作成した Backend リソースに BackendService リソースを追加します。

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

  5. サービスが利用可能な 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 \
  --zone=ZONE \
  --project=PROJECT_NAME

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

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

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

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME

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

      curl http://FORWARDING_RULE_VIP:PORT

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

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

API

KRM API を使用して、Pod または VM ワークロードをターゲットとする 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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

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

    • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。詳細については、ゾーン コンテキストに切り替えるをご覧ください。
    • PROJECT_NAME: プロジェクトの名前。
    • BACKEND_NAME: Backend リソースの名前。
    • CLUSTER_NAME: これは省略可能なフィールドです。このフィールドは、定義されたセレクタのスコープが制限されるクラスタを指定します。このフィールドは VM ワークロードには適用されません。Backend リソースに clusterName フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。

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

  2. この ILB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ILB を構成する場合は、ILB のヘルスチェックを定義します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

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

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。
    • HEALTHY_THRESHOLD: エンドポイントが正常とみなされるために連続して成功しなければならないプローブの数。デフォルト値は 2 です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。

  3. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。VM ワークロード用に ILB を構成する場合は、HealthCheck リソースを含めます。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

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

    • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
    • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。Pod ワークロードの ILB を構成する場合は、このフィールドを含めないでください。

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

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

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

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

      ports:
- port: 80
  protocol: TCP

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

    1. VIP を取得するには、kubectl get を使用します。

      kubectl get forwardingruleinternal -n PROJECT_NAME

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

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

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

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP は、転送ルールの VIP に置き換えます。

Kubernetes Service

GDC で ILB を作成するには、Kubernetes クラスタでタイプ LoadBalancer の Kubernetes Service オブジェクトを作成します。この ILB は、Service オブジェクトが作成されたクラスタ内のワークロードのみをターゲットにします。

Service オブジェクトを使用して ILB を作成する手順は次のとおりです。

  1. タイプ LoadBalancer の Service 定義の YAML ファイルを作成します。networking.gke.io/load-balancer-type: internal アノテーションを使用して、ILB サービスを内部として設計する必要があります。

    次の Service オブジェクトは、ILB サービスの例です。

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

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

    • ILB_SERVICE_NAME: ILB サービスの名前。
    • PROJECT_NAME: バックエンド ワークロードを含むプロジェクトの Namespace。

    port フィールドは、VIP アドレスで公開するフロントエンド ポートを構成します。targetPort フィールドは、バックエンド ワークロードのトラフィックを転送するバックエンド ポートを構成します。ロードバランサはネットワーク アドレス変換（NAT）をサポートしています。フロントエンド ポートとバックエンド ポートは異なる場合があります。

  2. Service 定義の selector フィールドで、バックエンド ワークロードとして Pod または仮想マシンを指定します。

    セレクタは、指定したラベルとワークロードのラベルを照合して、このサービスのバックエンド ワークロードとして使用するワークロードを定義します。Service は、Service を定義するプロジェクトとクラスタ内のバックエンド ワークロードのみ選択できます。

    サービス選択の詳細については、https://kubernetes.io/docs/concepts/services-networking/service/ をご覧ください。

  3. Service 定義ファイルをバックエンド ワークロードと同じプロジェクトに保存します。ILB サービスは、Service 定義と同じクラスタ内のワークロードのみを選択できます。

  4. Service 定義ファイルをクラスタに適用します。

    kubectl apply -f ILB_FILE

    ILB_FILE は、ILB サービスの Service 定義ファイルの名前に置き換えます。

    ILB サービスを作成すると、サービスに IP アドレスが割り当てられます。ILB サービスの IP アドレスは、サービス ステータスを表示することで取得できます。

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

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

    • PROJECT_NAME: バックエンド ワークロードを含むプロジェクトの Namespace。
    • ILB_SERVICE_NAME: ILB サービスの名前。

    次のような出力を取得する必要があります。

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    CLUSTER-IP フィールドと EXTERNAL-IP フィールドには、ILB サービスの IP アドレスと同じ値を指定する必要があります。この IP アドレスは、プロジェクトが持つプロジェクト ネットワーク ポリシーに従って、組織内の他のクラスタからアクセスできるようになりました。

    出力が得られない場合は、ILB サービスが正常に作成されていることを確認してください。

    GDC は、サービスのドメイン ネーム システム（DNS）名をサポートしています。ただし、これらの名前は ILB サービスと同じクラスタでのみ機能します。他のクラスタから ILB サービスにアクセスするには、IP アドレスを使用する必要があります。

グローバル ILB を作成する

gdcloud CLI または KRM API を使用して、グローバル ILB を作成します。

gdcloud

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

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

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

  1. ILB のエンドポイントを定義する Backend リソースを作成します。

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

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

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

  2. この ILB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ILB を構成する場合は、ILB のヘルスチェックを定義します。

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

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

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
    • HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。デフォルト値は 5 です。このフィールドは省略可能です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。このフィールドは省略可能です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。このフィールドは省略可能です。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。このフィールドは省略可能です。

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

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

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

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

  4. 前に作成した Backend リソースに BackendService リソースを追加します。

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend-zone BACKEND_ZONE \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --global

  5. サービスが利用可能な 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_NAME \
  --global

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

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

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

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

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

      curl http://FORWARDING_RULE_VIP:PORT

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

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

API

KRM API を使用して、Pod または VM ワークロードをターゲットとする 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
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

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

    • MANAGEMENT_API_SERVER: グローバル管理 API サーバーの kubeconfig パス。詳細については、グローバル コンテキストに切り替えるをご覧ください。
    • PROJECT_NAME: プロジェクトの名前。
    • BACKEND_NAME: Backend リソースの名前。
    • CLUSTER_NAME: これは省略可能なフィールドです。このフィールドは、定義されたセレクタのスコープが制限されるクラスタを指定します。このフィールドは VM ワークロードには適用されません。Backend リソースに clusterName フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。

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

  2. この ILB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ILB を構成する場合は、ILB のヘルスチェックを定義します。

    apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD

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

    • HEALTH_CHECK_NAME: ヘルスチェック リソースに選択した名前（my-health-check など）。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。
    • HEALTHY_THRESHOLD: エンドポイントが正常とみなされるために連続して成功しなければならないプローブの数。デフォルト値は 2 です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。

    これはグローバル ILB であるため、グローバル API でヘルスチェックを作成します。

  3. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。VM ワークロード用に ILB を構成する場合は、HealthCheck リソースを含めます。

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

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

    • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
    • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。Pod ワークロードの ILB を構成する場合は、このフィールドを含めないでください。

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

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

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

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

      • TARGET_PORT: PORT 値が変換されるポート（8080 など）。TARGET_PORT の値は、特定のオブジェクト内で重複して使用することはできません。targetPorts の例を次に示します。

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

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

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

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

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

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

      ports:
- port: 80
  protocol: TCP

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

    1. VIP を取得するには、kubectl get を使用します。

      kubectl get forwardingruleinternal -n PROJECT_NAME

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

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

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

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP は、転送ルールの VIP に置き換えます。