Network Load Balancer for VPC

VPC クラスターでは、クラスターの各ゾーンに layer-4 Network Load Balancer for VPC （VPC NLB）をクラスターの各ゾーンに設定し、アプリへの着信リクエストの外部エントリポイントとして機能させます。

VPC NLB にはいくつかの利点があります。例えば、直接サーバー・リターン (DSR) によってスループットが高くなり、パフォーマンスが向上します。 DSR を使用すると、ワーカー・ノードは NLB をスキップして、アプリケーション応答パケットをクライアント IP アドレスに直接送信できるので、NLB が処理するトラフィックの量が減ります。 また、VPC NLB を使用すると、デフォルトですべてのクライアント要求のソース IP アドレスが保存されます。

• 標準 VPC NLB 名の形式は kube-<cluster_ID>-<kubernetes_lb_service_UID> です。 クラスター ID を確認するには、ibmcloud oc cluster get --cluster <cluster_name> を実行します。 Kubernetes LoadBalancer サービスの UID を調べるには、oc get svc myloadbalancer -o yaml を実行して出力中の metadata.uid フィールドを確認します。 VPC NLB 名に含まれる「 Kubernetes 」 LoadBalancer サービスの UID から、ハイフン (-) が削除されます。

• 永続 VPC NLB 名の形式は kube-<cluster_ID>-<kubernetes_lb_service_UID> です。 クラスター ID を確認するには、ibmcloud oc cluster get --cluster <cluster_name> を実行します。 Kubernetes LoadBalancer サービスの UID を調べるには、oc get svc myloadbalancer -o yaml を実行して出力中の metadata.uid フィールドを確認します。 VPC NLB 名に含まれる「 Kubernetes 」 LoadBalancer サービスの UID から、ハイフン (-) が削除されます。

• クラスターでアプリの Kubernetes LoadBalancer サービスを作成し、service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb" アノテーションを指定すると、VPC NLB が VPC のクラスター外部に作成されます。 この VPC NLB は、ワーカー・ノードで自動的に開かれるプライベート NodePort を介して、アプリに対する要求を転送します。

• パブリックの Kubernetes LoadBalancer サービスを作成する場合は、VPC NLB によって Kubernetes LoadBalancer サービスに割り当てられる外部パブリック IP アドレスを使用して、インターネットからアプリにアクセスできます。 ワーカー・ノードがプライベート VPC サブネットにしか接続されていなくても、VPC NLB が、パブリック要求を受け取って、アプリを公開しているサービスに転送することができます。 VPC NLB へのパブリック要求を許可するために VPC サブネットにパブリック・ゲートウェイを置く必要はないことに注意してください。 一方、アプリからパブリック URL にアクセスする必要がある場合は、ワーカー・ノードが接続される VPC サブネットにパブリック・ゲートウェイを接続する必要があります。

• プライベートの Kubernetes LoadBalancer サービスを作成する場合は、同じリージョンおよび同じ VPC のプライベート・サブネットに接続されているシステムしかアプリにアクセスできません。 プライベート VPC ネットワークに接続されている場合、VPC NLB によって Kubernetes LoadBalancer サービスに割り当てられる外部プライベート IP アドレスを使用してアプリにアクセスできます。

以下の図は、ユーザーが VPC NLB を介してインターネットからアプリにアクセスする方法を示しています。

1. アプリへの要求には、VPC NLB によって Kubernetes LoadBalancer サービスに割り当てられた外部 IP アドレスを使用します。
2. 要求は自動的に VPC NLB によってワーカー・ノードのノード・ポートの 1 つに転送され、さらにアプリ・ポッドのプライベート IP アドレスに転送されます。
3. アプリのインスタンスがクラスター内の複数のワーカーノードにデプロイされている場合、VPC NLB は、クラスターのすべてのゾーンにまたがるさまざまなワーカーノード上のアプリポッド間でリクエストをルーティングします。

Application Load Balancer for VPC

レイヤー 7 のマルチゾーン対応の VPC 用アプリケーション・ロード・バランサー (VPC ALB) を、クラスター内のアプリに対する着信要求のための外部エントリー・ポイントとして動作するようにセットアップします。

VPC 用アプリケーション・ロード・バランサーを Red Hat OpenShift on IBM Cloud Ingress のアプリケーション・ロード・バランサーと混同しないでください。 VPC アプリケーション・ロード・バランサー (VPC ALB) は、VPC 内のクラスターの外で実行され、ユーザーが作成する Kubernetes LoadBalancer サービスによって構成されます。 Ingress アプリケーション・ロード・バランサー (ALB) は、クラスター内部のワーカー・ノードで実行される Ingress コントローラーです。

• VPC ALB の名前は、 kube-<cluster_ID>-<kubernetes_lb_service_UID> という形式になっています。 クラスター ID を確認するには、ibmcloud oc cluster get --cluster <cluster_name> を実行します。 Kubernetes LoadBalancer サービスの UID を調べるには、oc get svc myloadbalancer -o yaml を実行して出力中の metadata.uid フィールドを確認します。 VPC ALB 名に含まれる Kubernetes LoadBalancer サービスの UID から、ハイフン (-) が削除されます。

• デフォルトでは、クラスター内のアプリ用に Kubernetes の LoadBalancer サービスを作成すると、VPC 用アプリケーション・ロード・バランサーが VPC のクラスター外部に作成されます。 この VPC ALB が、ワーカー・ノードで自動的に開かれるプライベート NodePort を介して、アプリに要求を転送します。

• パブリック Kubernetes LoadBalancer サービスを作成する場合は、VPC ALB によって Kubernetes LoadBalancer サービスに割り当てられたホスト名 (1234abcd-<region>.lb.appdomain.cloud の形式) を使用して、インターネットからアプリにアクセスできます。 ワーカー・ノードがプライベート VPC サブネットにしか接続されていなくても、VPC ALB が、パブリック要求を受け取って、アプリを公開しているサービスに転送することができます。 VPC ALB へのパブリック要求を許可するために VPC サブネットにパブリック・ゲートウェイを置く必要はないことに注意してください。 一方、アプリからパブリック URL にアクセスする必要がある場合は、ワーカー・ノードが接続される VPC サブネットにパブリック・ゲートウェイを接続する必要があります。

• プライベートの Kubernetes LoadBalancer サービスを作成する場合は、同じリージョンおよび同じ VPC のプライベート・サブネットに接続されているシステムしかアプリにアクセスできません。 プライベート VPC ネットワークに接続している場合は、VPC ALB によって Kubernetes LoadBalancer サービスに割り当てられたホスト名 (1234abcd-<region>.lb.appdomain.cloud の形式) を使用してアプリにアクセスできます。

以下の図は、ユーザーが VPC ALB を介してインターネットからアプリにアクセスする方法を示しています。

1. アプリへの要求には、VPC ALB によって Kubernetes LoadBalancer サービスに割り当てられたホスト名 (1234abcd-<region>.lb.appdomain.cloud など) を使用します。
2. 要求は自動的に VPC ALB によってワーカー・ノードのノード・ポートの 1 つに転送され、さらにアプリ・ポッドのプライベート IP アドレスに転送されます。
3. 複数のアプリ・インスタンスがクラスター内の複数のワーカー・ノードにデプロイされている場合、ロード・バランサーはさまざまなワーカー・ノード上のアプリ・ポッド間で要求を転送します。 また、マルチゾーン・クラスターの場合は、VPC ALB は、クラスター内のすべてのサブネットおよびゾーンのワーカー・ノードに要求を転送します。

ポート範囲を使用した NLB のセットアップ

複数のバックエンド・アプリケーションがあり、それぞれが別個のポート番号で listen する単一のホスト名からサービスをホストする必要がある場合、パブリック NLB でポート範囲を使用できます。 Kubernetes クラスターでポート範囲を使用するには、いくつかの手動構成を行う必要があります。 最初に、 ibm-load-balancer-cloud-provider-vpc-port-range オプションを設定する必要があります。 それぞれをコンマで区切って、1 つまたは複数の範囲を含めることができます。 spec.ports.port 値も、ポート範囲内の最小値に設定する必要があります。

以下の例では、ポート範囲 30000-30010 が使用されています。

NLB サービスが要求を転送するデプロイメントごとに、ノード・ポート・サービスを手動で作成する必要があります。 これらの各 Nodeport サービスのポート番号は、NLB サービスで構成されているポート範囲内でなければなりません。

以下の図の例では、ポート 30000 を持つ Nodeport サービスがデプロイメント 1 用に作成され、ポート 30001 を持つ Nodeport サービスがデプロイメント 2 用に作成されます。

ユーザーは、ポート範囲を含む NLB のポート 30001 に対して要求を行います。 この要求は VPC NLB サービスに送信されます。VPC NLB サービスは、同じくポート 30001 で listen しているクラスター内の Nodeport サービス (この場合はデプロイメント 2 用) に要求を送信します。 その後、Nodeport サービスは、デプロイメント 2 の選択されたポッドのターゲット・ポートに要求を送信します。

以下の例を使用して、ポート範囲を使用する NLB を作成します。 ヘルス・チェックが成功を返し、ポート範囲内のポートにデータが配信されるように、セレクター・ポッドとバックエンド・ポッドをポート範囲ロード・バランサー・サービスに関連付ける必要があります。 ポート範囲を使用するには、ロード・バランサー・サービスによって定義された範囲内のポート値を持つ追加の NodePort サービスを作成する必要があります。

1. 以下の LoadBalancer 構成の例を、 loadbalancer.yaml という名前のファイルとして保存します。

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. サービスを作成します。

   oc apply -f loadbalancer.yaml
   

3. 先ほど作成した LoadBalancer で指定したポート範囲内のポート値を使用して、 NodePort サービスを作成します。

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. NodePort サービスを作成します。

   oc apply -f nodeport.yaml
   

5. NLB によって提供される範囲内のポートにアクセスします。

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = 要求に応答する範囲内のノード・ポートです。
   • 範囲内の他のポートは、追加のノード・ポート・サービスが作成されない限り、応答しません。

プライベート VPC NLB のセットアップ

クラスターの各ゾーンで Kubernetes LoadBalancer サービスをセットアップして、アプリをプライベート・ネットワーク・トラフィックに公開します。 Kubernetes LoadBalancer サービスを作成すると、要求をアプリに転送するプライベート VPC ネットワーク・ロード・バランサー (VPC NLB) が VPC 内のクラスターの外に自動的に作成されます。

開始前に

• VPC NLB用の Kubernetes LoadBalancer サービスをデプロイする名前空間に対して、 作家 または、 マネージャー IBM Cloud IAM サービスのアクセスロール が割り当てられていることを確認してください。
• VPC VPN 接続などを使用して、VPC プライベート・ネットワークに接続します。
• Red Hat OpenShift クラスターにアクセスします。
• VPC NLB を表示するには、infrastructure-service プラグインをインストールします。 コマンドを実行するための接頭部は、ibmcloud is です。

  ibmcloud plugin install infrastructure-service
  

アプリがプライベート要求を受信できるようにするには、以下のようにします。

1. VPC NLB 専用の VPC サブネットを作成します。 このサブネットはクラスターと同じ VPC の同じロケーションに存在する必要がありますが、このサブネットをクラスターやワーカー・ノードに接続することはできません。

   1. VPC サブネット ダッシュボード から、「 新しいサブネット 」をクリックしてください。
   2. サブネットの名前を入力します。
   3. クラスターが存在するロケーションおよび VPC NLB を作成するゾーンを選択します。
   4. クラスターが存在する VPC の名前を選択します。
   5. 作成する IP アドレスの数を指定します。 このサブネットは VPC NLB 専用であるため、16 などの小さいサイズを選択できます。 後で VPC サブネットの IP の数を変更することはできません。 具体的な IP 範囲を入力する場合は、予約済みの範囲で 172.16.0.0/16、172.18.0.0/16、172.19.0.0/16、172.20.0.0/16 は使用しないでください。
   6. **「サブネットの作成 (Create subnet)」**をクリックします。 サブネットがプロビジョンされたら、その ID をメモします。

2. VPC NLB 経由でアプリに接続する必要があるクライアントが、この専用 VPC サブネットを作成した VPC とゾーンの外部に存在する場合は、カスタム Ingress ルーティング・テーブルを作成する必要があります。 そのカスタム・ルーティング・テーブルには、一部の障害状況の発生時にサービスの可用性を確保するために、プライベート VPC NLB がルールを追加する場合があります。 詳しくは、既知の制限の表および ルーティング・テーブルおよびルートについてを参照してください。

   1. VPC ルーティングテーブルのダッシュボードで、[ 作成 ] をクリックします。
   2. ルーティング・テーブルの名前を入力します。
   3. 専用サブネットを作成したロケーションおよびゾーンを選択します。
   4. サブネットが存在する VPC の名前を選択します。
   5. **「トラフィック・タイプ」で、「Ingress」**を選択します。
   6. クライアントがどこからアプリにアクセスするかに応じて、**「トラフィック・ソース (Traffic source)」**を選択します。 VPC プライベート・ネットワークへの接続のセットアップ方法については、VPC 接続に IBM Cloud VPC VPN、Transit Gateway、または Direct Link を選択する方法について記載した資料を参照してください。
      • オンプレミス・ネットワーク: Direct Link
      • 別の VPC またはクラシック・インフラストラクチャー: Transit Gateway
      • 同じ VPC 内の別のゾーン: VPC ゾーン

3. アプリをクラスターにデプロイします。 デプロイメント構成ファイルの metadata セクションに、ラベルを追加しておく必要があります。 このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。

4. Kubernetes LoadBalancer サービスの構成 YAML ファイルを作成します。 サービス名を <app_name>-vpc-nlb-<VPC_zone> の形式にすることを検討してください。

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   オプション。 VPC ロード・バランサーを永続的にするには、固有の名前を指定します。 永続 VPC ロード・バランサーは、属しているクラスターが削除されても削除されません。 詳しくは、 永続 VPC ロード・バランサー を参照してください。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

   必須: VPC NLB を作成するためのアノテーション。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

   必須: プライベート要求を受け入れるサービスを指定するためのアノテーション。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   必須: VPC NLB のデプロイ先の専用サブネットを指定するためのアノテーション。 値には、VPC サブネット ID、VPC サブネット名、または VPC サブネット CIDR を指定できます。 サブネットは 1 つだけ指定してください。 このサブネットは、クラスターと同じ VPC 内になければならず、クラスターのワーカー・ノードが配置されたゾーンに存在する必要があります。ただし、このサブネットにワーカー・ノードを接続することはできません。 このサブネットと同じゾーンに存在するワーカー・ノードは、VPC NLB からトラフィックを受信するように構成されます。 すべてのリソース・グループのサブネットを確認するには、ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone> を実行します。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   オプション: ワーカー・ノードのラベル・セレクターを指定するためのアノテーション。 サポートされるラベル・セレクターのキーのいずれかを選択することで、VPC NLB の専用サブネットと同じゾーン内に存在する特定のワーカー・ノードを、トラフィックを受信するように構成できます。 このアノテーションにはラベル・セレクターを 1 つだけ指定できること、また、セレクターは "key=value" という形式で指定する必要があることに注意してください。 このアノテーションを指定しない場合は、service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets アノテーションで指定した VPC サブネットと同じゾーンに存在するすべてのワーカー・ノードが、VPC NLB からトラフィックを受信するように構成されます。 指定すると、ワーカー・ノードの dedicated: edge ラベルは無視されます。

   以下のキーを使用できます。 - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp

   オプション: UDP ロード・バランサーでの TCP ヘルス・チェックに使用する TCP ノード・ポートを指定します。 externalTrafficPolicy が Cluster に設定されている UDP ロード・バランサーの場合は必須。 ポート値を設定する前のその他の考慮事項については、UDP ロード・バランサーの TCP ヘルス・チェックの構成を参照してください。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   オプション: このアノテーションは、 Kubernetes ロード・バランサー・サービスに関連付けられた VPC ロード・バランサー・リソースのヘルス・チェック・プロトコルを設定します。 通常、VPC LB ヘルス・チェック・プロトコルは、 Kubernetes ロード・バランサー・サービス仕様の externalTrafficPolicy 設定の値によって決定されます。 このアノテーションは、そのロジックをオーバーライドします。 このアノテーションは、 Kubernetes、特に kube-proxy が externalTrafficPolicy のさまざまな設定に関してどのように動作するかを変更するものでは ありません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   オプション。 ヘルスチェックに使用される TCP ポート。 このアノテーションは、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol も指定されている場合にのみ適用されます。

   • 指定された TCP ポートが、 Kubernetes ノードのポート範囲（30,000～32,767）外にある場合、クラスタのワーカーノードに適用されているVPCセキュリティグループ を変更し、そのポートでの着信トラフィックを許可する必要があります。
   • このアノテーションを、VPC ALBに関連付けられた Kubernetes ロードバランサーサービスに適用する場合、指定された TCP ポートへのアウトバウンドトラフィックを許可するように、そのVPC ALBに割り当てられているセキュリティグループのアウトバウンドルールを 変更 する必要があります。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   オプション。 HTTP およびHTTPSヘルスチェックのヘルスチェックパス（ URL ）。 このアノテーションは、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol が http または https に設定されている場合にのみ適用されます。

   • URL のパスは、 origin-form リクエストターゲットの形式で指定する必要があります。
   • このアノテーションが指定されず、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol アノテーションが http または https に設定されている場合、デフォルト値 / が適用されます。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   オプション。 ヘルス・チェックの試行と試行の間に待機する秒数。 デフォルトでは、この値は 5 に設定されており、最小値は 2 、最大値は 60 です。 この値は、デフォルトで 2 に設定されている ibm-load-balancer-cloud-provider-vpc-health-check-timeout 値より大きくなければなりません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   オプション。 ヘルス・チェックへの応答を待機する時間 (秒数)。 デフォルトでは、この値は 2 に設定されており、最小値は 1 、最大値は 59 です。 この値は、デフォルトで 5 に設定されている ibm-load-balancer-cloud-provider-vpc-health-check-delay より小さくなければなりません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   VPC ロード・バランサーのヘルス・チェック再試行の最大回数。 デフォルトでは、この値は 2 に設定され、最小は 1 、最大は 10 です。

   selector

   アプリ・デプロイメント YAML の <selector_key> セクションで使用したラベル・キー (<selector_value>) と値 (spec.template.metadata.labels)。 このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。

   port

   サービスが listen するポート。

   targetPort

   オプション: サービスがトラフィックを転送する宛先ポート。 ポッド内で実行されているアプリケーションは、このターゲットポートで TCP からのトラフィックをリッスンしている必要があります。 多くの場合、ターゲット・ポートは、アプリケーション・ポッドで実行されているイメージで静的に定義されます。 ポッドで構成されているターゲット・ポートは、サービスのノード・ポートとは異なり、VPC LB で構成されている外部ポートとも異なる場合があります。

   externalTrafficPolicy

   必須。 特定 Local または Cluster。

   アプリへのクライアントリクエストの送信元IPアドレスを保持するには、 Local に設定してください。 この設定により、着信トラフィックが別のノードに転送されなくなります。 このオプションは、HTTP ヘルス・チェックも構成します。

   Cluster が設定されている場合、DSRは、VPC NLBが着信リクエストを最初に転送したワーカーノードからのみ実装されます。 着信要求が到着すると、その要求は、別のゾーンにある可能性があるアプリ・ポッドを含むワーカー・ノードに転送されます。 アプリ・ポッドからの応答が元のワーカー・ノードに送信されると、そのワーカー・ノードが DSR を使用し、VPC NLB をバイパスして応答を直接クライアントに送信します。 このオプションは、TCP ヘルス・チェックも構成します。 UDP ロードバランサーの場合、「 Cluster 」オプションを選択するには、「 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp 」が必要です。 詳細については、「 UDP ロードバランサー向けの TCP ヘルスチェックの設定 」を参照してください。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   オプション。 ロード バランサーがルーティングするゾーンごとのワーカー ノードの数。 デフォルト値は 8 です。 3 つのゾーンにワーカー ノードがあるクラスターの場合、ロード バランサーは合計 24 個のワーカー ノードにルーティングされます。 ロード バランサーがルーティングするすべてのゾーンのワーカー ノードの合計数は 50 を超えることはできません。 クラスターのすべてのゾーンにわたるワーカー ノードが 50 未満の場合、ゾーン内のすべてのワーカー ノードにルーティングするには 0 を指定します。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   オプション。 VPC ロードバランサーに追加する顧客管理のセキュリティ グループ。 使用したくない場合は IBM-管理されたセキュリティグループ 所有および管理するセキュリティ グループを指定します。 このオプションは、IBM管理対象のセキュリティ グループを削除し、指定したセキュリティ グループに置き換えます。 既存のロードバランサーから注釈を削除すると、追加したセキュリティグループがIBM管理されたセキュリティ グループ。 この注釈はいつでも追加または削除できます。 セキュリティ グループを管理し、最新の状態に保つ責任はあなたにあります。

5. クラスターに Kubernetes LoadBalancer サービスを作成します。

   oc apply -f <filename>.yaml -n <namespace>
   

6. クラスターに Kubernetes LoadBalancer サービスが正常に作成されたことを確認します。 サービスが作成されると、VPC NLB によって割り当てられた外部 IP アドレスが **「LoadBalancer Ingress」**フィールドに取り込まれます。

VPC NLB が VPC にプロビジョンされるまでに数分かかります。 VPC NLB のプロビジョンが完了するまで、Kubernetes LoadBalancer サービスの外部 IP アドレスが pending になることがあります。

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
プライベートの `LoadBalancer` サービスの CLI 出力例:
```sh {: screen}
NAME:                     myvpcnlb
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     10.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

7. VPC NLB が VPC に正常に作成されたことを確認します。 出力で、VPC NLB の**「Operating Status」がonline、「Provision Status」**がactiveであることを確認します。

   ibmcloud is load-balancers
   

   以下の CLI 出力例では、kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e という名前の VPC NLB が Kubernetes LoadBalancer サービス用に作成されています。

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       no         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.XXX.XXX.XXX           active             -               c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

8. VPC プライベート・ネットワークへの接続から、手順 6 で確認した Kubernetes LoadBalancer サービスの IP アドレスとアプリ・ポート (<external_IP>:<app_port> の形式) にアクセスします。

9. オプション: これらのステップを繰り返して、アプリを公開する各ゾーンにプライベート VPC NLB をデプロイします。 その後、各ゾーン内の VPC NLB の外部 IP アドレスを 1 つの DNS サブドメインに登録できます。

DNS レコードおよび TLS 証明書の登録

VPC NLB は、アプリへのアクセスに使用できる静的外部 IP アドレスを提供します。 HTTPS に対応するためにアプリ・ドメインの SSL 証明書を登録するには、IBM 提供のサブドメインを作成するか、カスタム・ドメインを持ち込みます。

例えば、マルチゾーン・クラスターがあり、そのクラスターの各ゾーンでワーカー・ノード上のアプリのレプリカを実行するとします。 ゾーンごとに 1 つの VPC NLB を作成して、アプリのレプリカを公開します。 その後、各 VPC NLB によって提供される外部 IP アドレスを 1 つの DNS エントリーに登録できます。

VPC NLB の DNS サブドメインを作成した後に、nlb-dns health-monitor コマンドでカスタム・ヘルス・チェックを作成することはできません。 代わりに、デフォルトの VPC ヘルス・チェックが使用されます。 詳しくは、VPC の資料を参照してください。

• アプリのゾーンごとに VPC NLB を 1 つ作成します。 VPC NLB を構成する Kubernetes LoadBalancer サービスに HTTPS ポートを定義するようにしてください。
• HTTPS 経由でアプリケーションにアクセスするために SSL 証明書を使用するには、アプリケーションが TLS 接続を終了できる必要があります。

VPC NLB の IP アドレスを DNS サブドメインに登録するには、次のようにします。

1. ロード・バランサーの外部 IP アドレスを取得します。

   oc get svc -o wide
   

   出力例

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)            AGE      SELECTOR
   ...
   myapp-vpc-nlb-jp-tok-3    LoadBalancer   172.21.xxx.xxx   169.xx.xxx.xx     8080:30532/TCP     1d       run=webserver
   

2. IP アドレスの、カスタム DNS サブドメインまたは IBM 提供の DNS サブドメインを作成します。

   • カスタム・ドメイン:

     1. ドメイン・ネーム・サービス (DNS) プロバイダーを利用するか、または IBM Cloud DNS を使用して、カスタム・ドメインを登録します。
     2. ロード・バランサーの IP アドレスを A レコードとして指定して、カスタム・ドメインの別名を定義します。

   • IBM 提供のサブドメイン: nlb-dns コマンドを使用して、IP アドレスのサブドメインおよび SSL 証明書を生成します。IBM Cloud によって、サブドメインのワイルドカード SSL 証明書の生成と保守が行われます。

     1. DNS サブドメインと SSL 証明書を作成します。

        ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
        

     2. サブドメインが作成されたことを確認します。 詳しくは、サブドメインのフォーマットについてを参照してください。

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        出力例

        Subdomain                                                                               IP(s)                                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     169.46.xx.x,169.48.xxx.xx,169.48.xxx.xx      None             created                   <certificate>
        

3. Web ブラウザーを開き、サブドメインを使用してアプリにアクセスするための URL を入力します。

HTTPS 経由でアプリケーションにアクセスするために SSL 証明書を使用するには、HTTPS ポートが Kubernetes LoadBalancer サービスで定義されていることを確認してください。 curl -v --insecure https://<domain> を実行すると、要求が HTTPS ポートで正しく転送されているか確認できます。 接続エラーが発生する場合、サービスで HTTPS ポートが開いていないことを示します。 また、ご使用のアプリで TLS 接続を終了できることを確認してください。 curl -v https://<domain> を実行すると、アプリが TLS を適切に終端するか確認できます。 証明書エラーは、アプリが TLS 接続を適切に終了していないことを示します。

パブリック VPC ALB またはプライベート VPC ALB のセットアップ

開始前に

• VPC NLB用の Kubernetes LoadBalancer サービスをデプロイする名前空間に対して、 作家 または、 マネージャー IBM Cloud IAM サービスのアクセスロール が割り当てられていることを確認してください。
• Red Hat OpenShift クラスターにアクセスします。
• VPC ALB を表示するには、infrastructure-service プラグインをインストールします。 コマンドを実行するための接頭部は、ibmcloud is です。

  ibmcloud plugin install infrastructure-service
  

アプリがパブリック要求またはプライベート要求を受信できるようにするには、以下のようにします。

1. アプリをクラスターにデプロイします。 デプロイメント構成ファイルの metadata セクションに、ラベルを追加しておく必要があります。 このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。

2. Kubernetes LoadBalancer サービスの構成 YAML ファイルを作成し、ファイルに myloadbalancer.yaml という名前を付けます。

   apiVersion: v1
   kind: Service
   metadata:
     name: myloadbalancer
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
    type: LoadBalancer
    selector:
       <selector_key>: <selector_value>
    ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   オプション。 VPC ロード・バランサーを永続的にするには、固有の名前を指定します。 永続 VPC ロード・バランサーは、属しているクラスターが削除されても削除されません。 詳しくは、 永続 VPC ロード・バランサー を参照してください。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"

   オプション ：PROXYプロトコルを有効にします。 ロード・バランサーは、クライアントの IP アドレス、プロキシー・サーバーの IP アドレス、両方のポート番号などのクライアント接続情報を要求ヘッダーに入れてバックエンド・アプリに渡します。 PROXY プロトコルを受け入れるようにバックエンド・アプリを構成しておく必要があります。 たとえば、 以下の手順に従って、 NGINX アプリがPROXYプロトコルを受け入れるように設定できます。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type

   パブリック要求またはプライベート要求を受け入れるサービスを指定する注釈。 このアノテーションを含めない場合は、パブリックの LoadBalancer が作成されます。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   ワーカーノードのラベルセレクタを指定するための注釈。 トラフィックを受信するワーカー・ノードを指定するために、サポートされているラベル・セレクター・キーのいずれかを選択できます。 このアノテーションにはラベル・セレクターを 1 つだけ指定できること、また、セレクターは "key=value" という形式で指定する必要があることに注意してください。 このアノテーションを指定しない場合は、クラスター内のすべてのワーカー・ノードが、VPC ALB からのトラフィックを受信するように構成されます。 指定した場合は、このアノテーションが、service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションよりも優先されるので、ワーカー・ノードの dedicated: edge ラベルは無視されます。

   次のキーを使用できます。 - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   VPC ALB サービスがデプロイを行う 1 つ以上のサブネットを指定するための注釈。 指定した場合、このアノテーションは service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションよりも優先されます。 同じ VPC にあるサブネットで、クラスターが接続されているものとは別のサブネットを指定できることに留意してください。 その場合、VPC ALB は同じ VPC 内の別のサブネットにデプロイされますが、それでもクラスター・サブネット上のワーカー・ノードにトラフィックを転送できます。 すべてのリソース・グループのサブネットを確認するには、ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone> を実行します。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

   クラスターが接続されている VPC ゾーンを指定するアノテーション。 このアノテーションでゾーンを指定すると、次の 2 つの処理が行われます。

   1. VPC ALB が、そのゾーンのワーカー・ノードが接続されているのと同じサブネットにデプロイされます。
   2. そのゾーンのクラスターのワーカー・ノードのみが、VPC ALB からのトラフィックを受信するように構成されます。

   ゾーンを表示するには、ibmcloud oc zone ls --provider vpc-gen2 を実行します。

   ロード・バランサーを特定のゾーンに配置するには、ロード・バランサーを作成する際にこのアノテーションを指定する必要があります。 後でこのアノテーションを別のゾーンに変更しても、ロード・バランサー自体は新規ゾーンに移動されません。 ただし、ロード・バランサーは、新規ゾーン内のワーカー・ノードのみにトラフィックを送信するように再構成されます。

   ワーカー・ノードに dedicated: edge ラベルを設定し、このアノテーションを指定すると、指定したゾーン内のエッジ・ノードのみがトラフィックを受信するように構成されます。 他のゾーンのエッジ・ノードや、指定したゾーンの非エッジ・ノードは、ロード・バランサーからトラフィックを受信しません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   オプション: このアノテーションは、 Kubernetes ロード・バランサー・サービスに関連付けられた VPC ロード・バランサー・リソースのヘルス・チェック・プロトコルを設定します。 通常、VPC LB ヘルス・チェック・プロトコルは、 Kubernetes ロード・バランサー・サービス仕様の externalTrafficPolicy 設定の値によって決定されます。 このアノテーションは、そのロジックをオーバーライドします。 このアノテーションは、 Kubernetes、特に kube-proxy が externalTrafficPolicy のさまざまな設定に関してどのように動作するかを変更するものでは ありません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   オプション。 ヘルスチェックに使用される TCP ポート。 このアノテーションは、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol も指定されている場合にのみ適用されます。

   • 指定された TCP ポートが、 Kubernetes ノードのポート範囲（30,000～32,767）外にある場合、クラスタのワーカーノードに適用されているVPCセキュリティグループ を変更し、そのポートでの着信トラフィックを許可する必要があります。
   • このアノテーションを、VPC ALBに関連付けられた Kubernetes ロードバランサーサービスに適用する場合、指定された TCP ポートへのアウトバウンドトラフィックを許可するように、そのVPC ALBに割り当てられているセキュリティグループのアウトバウンドルールを 変更 する必要があります。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   オプション。 HTTP およびHTTPSヘルスチェックのヘルスチェックパス（ URL ）。 このアノテーションは、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol が http または https に設定されている場合にのみ適用されます。

   • URL のパスは、 origin-form リクエストターゲットの形式で指定する必要があります。
   • このアノテーションが指定されず、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol アノテーションが http または https に設定されている場合、デフォルト値 / が適用されます。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   オプション。 ヘルス・チェックの試行と試行の間に待機する秒数。 デフォルトでは、この値は 5 に設定されており、最小値は 2 、最大値は 60 です。 この値は、デフォルトで 2 に設定されている ibm-load-balancer-cloud-provider-vpc-health-check-timeout 値より大きくなければなりません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   オプション。 ヘルス・チェックへの応答を待機する時間 (秒数)。 デフォルトでは、この値は 2 に設定されており、最小値は 1 、最大値は 59 です。 この値は、デフォルトで 5 に設定されている ibm-load-balancer-cloud-provider-vpc-health-check-delay より小さくなければなりません。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   VPC ロード・バランサーのヘルス・チェック再試行の最大回数。 デフォルトでは、この値は 2 に設定され、最小は 1 、最大は 10 です。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

   オプション。 リスナーのアイドル接続タイムアウト（秒） 。 デフォルトのアイドル・タイムアウトは、アカウント設定によって異なります。 通常、この値は 50 です。 ただし、許可リストに登録されている一部のアカウントでは、タイムアウト設定が大きくなっています。 アノテーションを設定しない場合、ロード・バランサーはアカウントのタイムアウト設定を使用します。 このアノテーションを設定することにより、タイムアウトを明示的に指定できます。 最小は 50 です。 最大値は 7200 です。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

   オプション。 バージョンではプライベートVPC ALBにのみ適用できます4.15またはそれ以降。 このロードバランサーに関連付けるDNS instance。 詳細については、プライベートDNSレコードの登録。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

   オプション。 バージョンではプライベートVPC ALBにのみ適用できます4.15またはそれ以降。 このロードバランサーに関連付けるDNS zone。 詳細については、プライベートDNSレコードの登録。

   selector

   アプリ・デプロイメント YAML の <selector_key> セクションで使用したラベル・キー (<selector_value>) と値 (spec.template.metadata.labels)。 このカスタム・ラベルにより、アプリが実行されるすべてのポッドが識別されてロード・バランシングに含められます。

   port

   サービスが listen するポート。

   targetPort

   オプション: サービスがトラフィックを転送する宛先ポート。 ポッド内で実行されているアプリケーションは、このターゲットポートで TCP からのトラフィックをリッスンしている必要があります。 多くの場合、ターゲット・ポートは、アプリケーション・ポッドで実行されているイメージで静的に定義されます。 ポッドで構成されているターゲット・ポートは、サービスのノード・ポートとは異なり、VPC LB で構成されている外部ポートとも異なる場合があります。

   externalTrafficPolicy

   必須。 特定 Local または Cluster。

   アプリへのクライアントリクエストの送信元IPアドレスを保持するには、 Local に設定してください。 この設定により、着信トラフィックが別のノードに転送されなくなります。 このオプションは、HTTP ヘルス・チェックも構成します。 UDP ロードバランサーの場合、「 Cluster 」オプションを選択するには、「 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp 」が必要です。 詳細については、「 UDP ロードバランサー向けの TCP ヘルスチェックの設定 」を参照してください。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   オプション。 ロード バランサーがルーティングするゾーンごとのワーカー ノードの数。 デフォルト値は 8 です。 3 つのゾーンにワーカー ノードがあるクラスターの場合、ロード バランサーは合計 24 個のワーカー ノードにルーティングされます。 ロード バランサーがルーティングするすべてのゾーンのワーカー ノードの合計数は 50 を超えることはできません。 クラスターのすべてのゾーンにわたるワーカー ノードが 50 未満の場合、ゾーン内のすべてのワーカー ノードにルーティングするには 0 を指定します。

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   オプション。 VPC ロードバランサーに追加する顧客管理のセキュリティ グループ。 使用したくない場合は IBM-管理されたセキュリティグループ 所有および管理するセキュリティ グループを指定します。 このオプションは、IBM管理対象のセキュリティ グループを削除し、指定したセキュリティ グループに置き換えます。 既存のロードバランサーから注釈を削除すると、追加したセキュリティグループがIBM管理されたセキュリティ グループ。 この注釈はいつでも追加または削除できます。 セキュリティ グループを管理し、最新の状態に保つ責任はあなたにあります。

3. クラスターに Kubernetes LoadBalancer サービスを作成します。

   oc apply -f myloadbalancer.yaml -n <namespace>
   

4. クラスターに Kubernetes LoadBalancer サービスが正常に作成されたことを確認します。 サービスが作成されると、**「LoadBalancer Ingress」**フィールドに VPC ALB によって割り当てられたホスト名が取り込まれます。

VPC ALB が VPC にプロビジョンされるまでに数分かかります。 VPC ALB のプロビジョンが完了するまで、Kubernetes LoadBalancer サービスのホスト名を使用してアプリにアクセスすることはできません。

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
パブリックの `LoadBalancer` サービスの CLI 出力例:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. VPC ALB が VPC に正常に作成されたことを確認します。 出力で、VPC ALB の**「Operating Status」がonline、「Provision Status」**がactiveであることを確認します。

   LoadBalancer サービス用に自動的に作成される VPC ALB の名前は変更しないでください。 VPC ALB の名前を変更すると、Red Hat OpenShift on IBM Cloud は LoadBalancer サービス用の別の VPC ALB を自動的に作成します。

   ibmcloud is load-balancers
   

   以下の CLI 出力例では、kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306 という名前の VPC ALB が Kubernetes LoadBalancer サービス用に作成されています。

   ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
   r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default
   

6. パブリックの LoadBalancer サービスを作成した場合は、手順 4 で確認した VPC ALB から割り当てられた Kubernetes LoadBalancer サービスのホスト名を curl します。 次に例を示します。

   curl 06496f64-us-south.lb.appdomain.cloud:8080
   

   出力例

   Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
   

   プライベートの LoadBalancer サービスを作成した場合は、プライベート VPC ネットワークに接続しないとホスト名を curl できません。

クラスターを作成するときやワーカー・ノードをゾーンに追加するときに、クラスターに接続しているサブネットを削除しないでください。 クラスターで使用されている VPC サブネットを削除すると、そのサブネットの IP アドレスを使用しているロード・バランサーで問題が発生するだけでなく、ロード・バランサーの新規作成もできなくなる可能性があります。

Kubernetes または OpenShift クラスターに関連付けられていない VPC ALB および NLB は、「ibmcloud is」コマンド、またはコンソールの「 VPC インフラストラクチャ 」セクションを使用して、直接更新できます。 例えば、フロントエンド・リスナーのポートまたはヘルス・チェックのタイムアウト値を変更します。 ただし、 Kubernetes やOpenShiftクラスターに関連付けられているVPCロードバランサーについては、それらの更新はIngress設定の注釈を通じて行う必要があります。 IBM Cloud プロバイダーは、関連付けられたVPC ALBおよびNLBと定期的に再同期を行い、稼働中のロードバランサーがIngressの想定される構成に準拠していることを確認します。 そのため、そのようなロード・バランサーに対して、Ingress アノテーションを使用する代わりに VPC を介して直接変更を行った場合、それらの変更は元に戻されます。

DNS レコードおよび TLS 証明書の登録

VPC アプリケーション・ロード・バランサー (VPC ALB) は、アプリへのアクセスに使用できる 1234abcd-<region>.lb.appdomain.cloud という形式のデフォルトの HTTP ホスト名を提供します。 しかし、HTTPS に対応するためにアプリのドメインに TLS 証明書が必要な場合は、パブリックとプライベートのどちらの VPC ALB についても、IBM 提供のサブドメインを作成したり、カスタム・ドメインを持ち込んだりできます。

VPC ALB のホスト名の DNS サブドメインを作成した後に、nlb-dns health-monitor コマンドでカスタム・ヘルス・チェックを作成することはできません。 代わりに、デフォルトの VPC ALB のホスト名用に提供されるデフォルトの VPC ロード・バランサー・ヘルス・チェックが使用されます。 詳しくは、VPC の資料を参照してください。

開始前に

• VPC ALB をセットアップします。 VPC ALB を構成する Kubernetes LoadBalancer サービスに HTTPS ポートを定義するようにしてください。
• TLS 証明書を使用して HTTPS でアプリにアクセスするには、アプリが TLS 接続を終端できる必要があります。

DNS サブドメインを使用して VPC ALB のホスト名を登録するには、次のようにします。

1. get svc コマンドを実行して、VPC ALB のホスト名を取得します。 出力の EXTERNAL-IP 列でホスト名を探します。 例えば、1234abcd-us-south.lb.appdomain.cloudなどです。

   oc get svc -o wide
   

   出力例

   NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
   ...
   webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver
   

2. ロード・バランサーのホスト名の、カスタム DNS サブドメインまたは IBM 提供の DNS サブドメインを作成します。

   • カスタムドメイン ：独自のカスタムドメインを用意し、ロードバランサーの外部IPを「 1234abcd-us-south.lb.appdomain.cloud 」という形式で指定して、CNAMEレコードとしてエイリアスを設定してください。

     1. ドメイン・ネーム・サービス (DNS) プロバイダーを利用するか、または IBM Cloud DNS を使用して、カスタム・ドメインを登録します。
     2. ロードバランサーの外部IPアドレスを正規名レコード（CNAME）として指定し、カスタムドメインのエイリアスを定義します。 以下の例では、 1234abcd-us-south.lb.appdomain.cloud という外部 IP を持つロード・バランサーに www.your-custom-domain.com で到達できます。

     ホスト/サービス

     アプリにアクセスするための接頭部 ( www など)。

     リソース・タイプ

     CNAME を選択します。

     TTL

     存続時間を選択してください。

     値/ターゲット

     前に取得した LoadBalancer 外部 IP。 例えば、 1234abcd-us-south.lb.appdomain.cloud. などです。 IBM Cloud DNS を使用する場合は、必ず末尾にピリオドを入力してください。

   • IBM 提供のサブドメイン: nlb-dns コマンドを使用して、VPC ALB のホスト名用のサブドメインと TLS 証明書を生成します。IBM Cloud によって、サブドメインのワイルドカード TLS 証明書の生成と保守が行われます。

     1. DNS サブドメインと TLS 証明書を作成します。

        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
        

     2. サブドメインが作成されたことを確認します。 詳しくは、サブドメインのフォーマットについてを参照してください。

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        出力例

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
        

3. パブリック VPC ALB のサブドメインを作成した場合は、Web ブラウザを開き、 URL を入力して、 www.your-custom-domain.com のようなサブドメイン経由でアプリにアクセスしてください。 プライベート VPC ALB のサブドメインを作成した場合は、プライベート VPC ネットワークに接続した状態で、サブドメインへのアクセスをテストする必要があります。

TLS 証明書を使用して HTTPS でアプリにアクセスするために、Kubernetes の LoadBalancer サービスに HTTPS ポートを定義したことを確認してください。 curl -v --insecure https://<domain> を実行すると、要求が HTTPS ポートで正しく転送されているか確認できます。 接続エラーが発生する場合、サービスで HTTPS ポートが開いていないことを示します。 また、ご使用のアプリで TLS 接続を終了できることを確認してください。 curl -v https://<domain> を実行すると、アプリが TLS を適切に終端するか確認できます。 証明書エラーは、アプリが TLS 接続を適切に終了していないことを示します。

プライベート VPC ALB のプライベート DNS レコードの登録

バージョン4.15または、後で次のオプションの注釈を使用して独自のDNSを関連付けることができます instance カスタムDNSを提供する zone プライベート VPC ALB を使用します。 このため、オプションの注釈を両方とも設定する必要があります。 指定されていない場合はDNS A このロードバランサーの記録 hostname プロパティはパブリックDNSゾーンに追加されます lb.appdomain.cloud。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

このロードバランサーに関連付けるDNS instance。 指定されたインスタンスは、IAM ポリシーに従って、別のリージョンまたはアカウントに存在する場合があります。 可能な値: 9 ≤ 長さ ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

このロードバランサーに関連付けるDNS zone。 指定されたゾーンは、IAM ポリシーに従って、別のリージョンまたはアカウントに存在する場合があります。 許容される値：1 ≤ 長さ ≤ 128。値は正規表現 ^[1]*[a-z0-9]$ に一致する必要があります

この機能を使用する前に、前提条件として次の操作を実行する必要があります。

• ロードバランサーにバインドできるDNSゾーンを作成する
• VPC LB間のサービス間認証を有効にし、DNS Services
• クラスターのVPCをゾーンの許可されたネットワークに追加する

詳細については、「 アプリケーション・ロードバランサーを IBM Cloud DNS Services と統合する 」および「 DNSゾーンに許可されたネットワークとしてVPCを追加する 」の各ドキュメントを参照してください。

次に例を示します。

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

クラスターからの VPC ロード・バランサーの切り離し

VPCロードバランサーは、その作成時に指定された Kubernetes （ LoadBalancer ）のサービス定義に関連付けられています。 永続 VPC ロード・バランサーをクラスターから切り離すには、 VPC ロード・バランサーの名前を変更 するか、元の LoadBalancer サービス定義から service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name アノテーションを削除して、 LoadBalancer サービスとのリンクを切断する必要があります。 クラスターを削除 して、永続 VPC ロード・バランサーをクラスターから切り離すこともできます。

アノテーションを削除すると、元の LoadBalancer サービスが元に戻り、元のクラスターに非永続 VPC ロード・バランサーが作成されます。 この非永続 VPC ロード・バランサーは、 kube-<cluster_ID>-<kubernetes_lb_service_UID> 命名規則に従います。

クラスターへの VPC ロード・バランサーの接続

永続的なVPCロードバランサーがクラスターから切り離された後、そのVPCロードバランサーを参照する新しい Kubernetes LoadBalancer サービス定義を作成することで、別のクラスターにアタッチすることができます。

新しいクラスター上に新しい LoadBalancer サービスを作成するときに、 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name アノテーションを使用して、接続する VPC ロード・バランサーの名前を指定できます。

LoadBalancer サービスを作成する場合は、VPC ロード・バランサー・タイプ (ALB、NLB) と IP タイプ (パブリック、プライベート) が LoadBalancer サービスの仕様と一致している必要があります。 例えば、NLB タイプを指定する新規クラスター上の既存の LoadBalancer サービスを使用して VPC ALB をクラスターに接続することはできません。 ロード・バランサー・タイプと IP タイプを指定するアノテーションは、それぞれ service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features と service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type です。

LoadBalancer サービスで指定するポートとノード・ポートは、VPC ロード・バランサーの作成に使用したポートと一致している必要はありません。 VPC ロード・バランサーは、新規クラスター内で関連付けられている LoadBalancer サービスのポート定義を使用して再構成します。

VPC ロード・バランサーのヘルス・チェックのカスタマイズ

VPC ロード・バランサーのヘルス・チェックをより詳細に制御するために、オプションのアノテーションを使用して、テスト間隔、タイムアウト、および再試行の拡張構成でヘルス・チェックをカスタマイズできます。 これらのカスタマイズはいつでも変更または削除できます。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

オプション: このアノテーションは、 Kubernetes ロード・バランサー・サービスに関連付けられた VPC ロード・バランサー・リソースのヘルス・チェック・プロトコルを設定します。 通常、VPC LB ヘルス・チェック・プロトコルは、 Kubernetes ロード・バランサー・サービス仕様の externalTrafficPolicy 設定の値によって決定されます。 このアノテーションは、そのロジックをオーバーライドします。 このアノテーションは、 Kubernetes、特に kube-proxy が externalTrafficPolicy のさまざまな設定に関してどのように動作するかを変更するものでは ありません。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

オプション。 ヘルスチェックに使用される TCP ポート。 このアノテーションは、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol も指定されている場合にのみ適用されます。

• 指定された TCP ポートが、 Kubernetes ノードのポート範囲（30,000～32,767）外にある場合、クラスタのワーカーノードに適用されているVPCセキュリティグループ を変更し、そのポートでの着信トラフィックを許可する必要があります。
• このアノテーションを、VPC ALBに関連付けられた Kubernetes ロードバランサーサービスに適用する場合、指定された TCP ポートへのアウトバウンドトラフィックを許可するように、そのVPC ALBに割り当てられているセキュリティグループのアウトバウンドルールを 変更 する必要があります。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

オプション。 HTTP およびHTTPSヘルスチェックのヘルスチェックパス（ URL ）。 このアノテーションは、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol が http または https に設定されている場合にのみ適用されます。

• URL のパスは、 origin-form リクエストターゲットの形式で指定する必要があります。
• このアノテーションが指定されず、 ibm-load-balancer-cloud-provider-vpc-health-check-protocol アノテーションが http または https に設定されている場合、デフォルト値 / が適用されます。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

オプション。 ヘルス・チェックの試行と試行の間に待機する秒数。 デフォルトでは、この値は 5 に設定されており、最小値は 2 、最大値は 60 です。 この値は、デフォルトで 2 に設定されている ibm-load-balancer-cloud-provider-vpc-health-check-timeout 値より大きくなければなりません。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

オプション。 ヘルス・チェックへの応答を待機する時間 (秒数)。 デフォルトでは、この値は 2 に設定されており、最小値は 1 、最大値は 59 です。 この値は、デフォルトで 5 に設定されている ibm-load-balancer-cloud-provider-vpc-health-check-delay 値より小さくなければなりません。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

VPC ロード・バランサーのヘルス・チェック再試行の最大回数。 デフォルトでは、この値は 2 に設定され、最小は 1 、最大は 10 です。

UDP ロード・バランサーの TCP ヘルス・チェックの有効化

UDP ヘルス・チェックはないため、TCP ヘルス・チェックを使用する UDP ロード・バランサーには、service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp アノテーションを使用して追加の TCP ポートを指定する必要があります。

クラスター内で実行されている別のロード・バランサーまたは NodePort の TCP ノード・ポートを指定できます。 ただし、ノード・ポートが 30000-32767 範囲外にある場合は、指定されたポートへの着信トラフィックを許可するように VPC クラスター・セキュリティー・グループ kube-<cluster-ID> を変更する必要があります。

なお、指定したポート値が、予期せず停止したサービス、またはポート値が再設定されたサービスのものである場合、そのサービスが復旧するか、 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp アノテーションを新しい TCP ポート値で再設定するまで、 TCP のヘルスチェックは機能しなくなります。 これを回避するには、kubelet ポート 10250 を指定します。これは、サービスの中断が発生しない静的ポート値です。 ただし、kubelet ポートからの着信トラフィックを受け入れるには、VPC クラスター・セキュリティー・グループを変更kube-<cluster-ID>する必要があります。

UDP のロードバランサーで、ヘルスチェック用に TCP のポートを追加で指定する手間を省きたいですか？ 追加のポート指定を必要としない HTTP ヘルス・チェックを使用するには、externalTrafficPolicy を Local に設定します。