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

外部ロードバランサ（ELB）は、より大きなインスタンス外部 IP プールから組織に割り当てられたプールの IP アドレスから、組織外からのアクセス用にサービスを公開します。

ELB 仮想 IP（VIP）アドレスは組織間で競合せず、すべての組織で一意です。そのため、ELB サービスは、組織外のクライアントがアクセスする必要があるサービスにのみ使用する必要があります。

ワークロードが組織内からアクセスできるように設定されていれば、組織内で実行されているワークロードは ELB サービスにアクセスできます。このトラフィック パターンでは、内部サービスに戻る前に、組織からの下り（外向き）トラフィックが事実上必要になります。

始める前に

ELB サービスを構成するには、次のものが必要です。

  • ロードバランサを構成するプロジェクトのオーナーである。詳細については、プロジェクトを作成するをご覧ください。
  • この ELB サービスへのトラフィックを許可するカスタマイズされた ProjectNetworkPolicy（PNP）上り（内向き）ポリシー。詳細については、ELB へのトラフィックを許可するように PNP を構成するをご覧ください。

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

    • プロジェクト NetworkPolicy 管理者: プロジェクト Namespace のプロジェクト ネットワーク ポリシーを管理する権限があります。組織 IAM 管理者に、プロジェクト NetworkPolicy 管理者（project-networkpolicy-admin）ロールの付与を依頼してください。
    • ロードバランサ管理者: 組織 IAM 管理者にロードバランサ管理者（load-balancer-admin）ロールの付与を依頼します。
    • グローバル ロードバランサ管理者: グローバル ELB の場合は、組織 IAM 管理者にグローバル ロードバランサ管理者（global-load-balancer-admin）ロールの付与を依頼します。詳細については、事前定義ロールの説明をご覧ください。

ELB へのトラフィックを許可するように PNP を構成する

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

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

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.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

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

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

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

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

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

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

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

ゾーン ELB を作成する

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

gdcloud

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

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

gdcloud CLI を使用して ELB を作成する手順は次のとおりです。

  1. ELB のエンドポイントを定義する 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. この ELB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ELB を構成する場合は、ELB のヘルスチェックを定義します。

    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: この ELB を作成するゾーン。

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

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

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

  5. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、gdcloud compute load-balancer-policy create コマンドを使用してバックエンド サービス ポリシーを作成します。

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

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

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティが無効になっています。リクエストは、使用可能なバックエンドに転送されます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドに転送されます。

    • RESOURCE_LABEL: プロジェクト名前空間で BackendServicePolicy リソースが適用されるバックエンド サービスを選択するラベル セレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

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

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

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

  7. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。ロードバランサに割り当てられた IP アドレスを取得するには、転送ルールを記述します。

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 構成された 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 または VM ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。

KRM API を使用してゾーン ELB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに 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 フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。

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

    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 ワークロード用に ELB を構成する場合は、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 ワークロードの ELB を構成する場合は、このフィールドを含めないでください。

  4. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、BackendServicePolicy リソースを作成します。このリソースは、セッション アフィニティ設定を定義し、BackendServicePolicy リソースを BackendService リソースに適用します。BackendServicePolicy リソースを作成して適用します。

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

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

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティが無効になっています。リクエストは、使用可能なバックエンドに転送されます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドに転送されます。

    • RESOURCE_LABEL: プロジェクト名前空間で BackendServicePolicy リソースが適用されるバックエンド サービスを選択するラベル セレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

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

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

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

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

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

      ports:
- port: 80
  protocol: TCP

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

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

      kubectl get forwardingruleexternal -n PROJECT_NAME

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

      NAME           BACKENDSERVICE                               CIDR              READY
elb-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 で ELB を作成するには、Kubernetes クラスタに LoadBalancer タイプの Kubernetes Service を作成します。

ELB サービスを作成するには、次の操作を行います。

  1. タイプ LoadBalancer の Service 定義の YAML ファイルを作成します。

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

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer

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

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

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

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

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

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

  3. Service 定義ファイルをバックエンド ワークロードと同じプロジェクトに保存します。

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

    kubectl apply -f ELB_FILE

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

    ELB を作成すると、サービスに 2 つの IP アドレスが割り当てられます。1 つは、同じクラスタ内からのみアクセスできる内部 IP アドレスです。もう 1 つは、組織内外からアクセス可能な外部 IP アドレスです。ELB サービスの IP アドレスは、サービス ステータスを表示することで取得できます。

    kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME

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

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

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

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h

    EXTERNAL-IP は、組織外からアクセスできるサービスの IP アドレスです。

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

グローバル ELB を作成する

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

gdcloud

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

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

gdcloud CLI を使用して ELB を作成する手順は次のとおりです。

  1. ELB のエンドポイントを定義する 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. この ELB が Pod ワークロード用である場合は、この手順をスキップします。VM ワークロード用に ELB を構成する場合は、ELB のヘルスチェックを定義します。

    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 ワークロードの ELB を構成する場合にのみ含めます。

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

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

  5. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、gdcloud compute load-balancer-policy create コマンドを使用してバックエンド サービス ポリシーを作成します。

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

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

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティが無効になっています。リクエストは、使用可能なバックエンドに転送されます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドに転送されます。

    • RESOURCE_LABEL: プロジェクト名前空間で BackendServicePolicy リソースが適用されるバックエンド サービスを選択するラベル セレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

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

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

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

  7. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。ロードバランサに割り当てられた IP アドレスを取得するには、転送ルールを記述します。

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

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

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

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_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 ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してゾーン ELB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに 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 フィールドが含まれていない場合、指定されたラベルはプロジェクト内のすべてのワークロードに適用されます。

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
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
EOF

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

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

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

  3. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。VM ワークロード用に ELB を構成する場合は、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 ワークロードの ELB を構成する場合は、このフィールドを含めないでください。

    • 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. 省略可: ELB にセッション アフィニティを使用して、同じクライアントからのリクエストが常に同じバックエンドにルーティングされるようにします。ロードバランサのセッション アフィニティを有効にするには、BackendServicePolicy リソースを作成します。このリソースは、セッション アフィニティ設定を定義し、BackendServicePolicy リソースを BackendService リソースに適用します。BackendServicePolicy リソースを作成して適用します。

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

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

    • POLICY_NAME: バックエンド サービス ポリシーに選択した名前。

    • MODE: セッション アフィニティ モード。次の 2 つのモードがサポートされています。

      • NONE: セッション アフィニティが無効になっています。リクエストは、使用可能なバックエンドに転送されます。これがデフォルトのモードです。
      • CLIENT_IP_DST_PORT_PROTO: 同じ 4 タプル（送信元 IP アドレス、宛先 IP アドレス、宛先ポート、プロトコル）からのリクエストは、同じバックエンドに転送されます。

    • RESOURCE_LABEL: プロジェクト名前空間で BackendServicePolicy リソースが適用されるバックエンド サービスを選択するラベル セレクタ。複数の BackendServicePolicy リソースが同じバックエンド サービスに一致し、これらのポリシーの少なくとも 1 つでセッション アフィニティが有効になっている場合、この BackendService リソースのセッション アフィニティが有効になります。

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

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  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: このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR がグローバル IP プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、カスタム リソースの例をご覧ください。
    • PORT: ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

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

      ports:
- port: 80
  protocol: TCP

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

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

      kubectl get forwardingruleexternal -n PROJECT_NAME

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

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

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

      curl http://FORWARDING_RULE_VIP:PORT

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