開始前に

1. VPC NLB の Kubernetes LoadBalancer サービスをデプロイするネームスペースの Writer または Manager IBM Cloud IAM サービスアクセスロールが あることを確認します。
2. Red Hat OpenShift クラスターにアクセスします。
3. VPC NLB を表示するには、infrastructure-service プラグインをインストールします。 コマンドを実行するための接頭部は、ibmcloud is です。

   ibmcloud plugin install infrastructure-service
   

4. プライベートVPC NLBの場合：VPCのVPN接続 など、VPCのプライベートネットワークに接続します。
5. プライベート VPC NLB の場合: アプリがプライベート ネットワーク リクエストを受信できるようにします。
   1. VPC NLB専用の VPCサブネットを作成します。 このサブネットはクラスターと同じ VPC の同じロケーションに存在する必要がありますが、このサブネットをクラスターやワーカー・ノードに接続することはできません。 特定の IP 範囲を入力する場合は、172.16.0.0/16、172.18.0.0/16、172.19.0.0/16、および 172.20.0.0/16 の予約済み範囲を使用しないでください。 サブネットをプロビジョニングしたら、その ID に注意してください。
   2. VPC NLBを経由してアプリに接続するクライアントがVPCと専用VPCサブネットのゾーン外に存在する場合、 カスタムイングレスルーティングテーブルを作成する必要があります。 詳しくは、既知の制限の表および ルーティング・テーブルおよびルートについてを参照してください。 カスタム・イングレス・ルーティング・テーブルの トラフィック・ソースとして、以下のいずれかを選択します：オンプレミスネットワークからのトラフィックには、 ダイレクトリンクを選択します。 別のVPCまたは古典的なインフラストラクチャからのトラフィックについては、トランジットゲートウェイを選択します。 同じVPC内の別のゾーンからのトラフィックについては、VPCゾーンを選択します。 詳細については、VPCのVPN接続の設定 を参照してください。

LoadBalancer サービスの設定

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

2. Kubernetes LoadBalancer サービスの構成 YAML ファイルを作成します。 YAMLファイルでは、service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type アノテーションを "public" または "private" として指定します。 サンプルファイルの annotations セクションには、使用可能な注釈がいくつかだけ含まれています。 必須およびオプションの VPC NLB 注釈の完全なリストについては、注釈と仕様 を参照してください。

   VPC NLBを簡単に識別できるようにするには、<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: "public"
       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>"
   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.
   

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

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

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

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

   oc describe svc myloadbalancer -n <namespace>
   

   パブリックの LoadBalancer サービスの CLI 出力例:

   NAME:                     myapp-vpc-nlb-us-east
   Namespace:                default
   Labels:                   <none>
   Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
   Selector:                 app=echo-server
   Type:                     LoadBalancer
   IP:                       172.21.204.12
   LoadBalancer Ingress:     169.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.
   

5. 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       yes         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.241.0.7               active             169.63.99.184                 c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

6. 手順 4 でわかった Kubernetes LoadBalancer サービスの IP アドレスとアプリのポートに <external_IP>:<app_port> の形式でアクセスします。

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

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

ポートレンジを使用したパブリックNLBの設定

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

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

Nodeportサービスは、NLBサービスがリクエストを転送する各展開ごとに手動で作成する必要があります。 これらの各Nodeportサービスのポート番号は、NLBサービスに設定されているポート範囲内でなければならない。

次の図の例では、ポート 30000 の Nodeport サービスが配置 1 用に作成され、ポート 30001 の Nodeport サービスが配置 2 用に作成されています。

ユーザーは、ポート範囲を含むNLBのポート30001にリクエストを行う。 このリクエストはVPCのNLBサービスに送られ、クラスタ内のNodeportサービスにリクエストを送ります。Nodeportサービスもポート30001でリッスンしています。 そして、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 = リクエストに応答する範囲内のノードポートである
   • 範囲内の他のポートは、追加のノード・ポート・サービスが作成されない限り、応答しない。

必要な注釈と仕様

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

VPC NLBを作成するためのアノテーション。 このアノテーションを含めずに nlb を指定すると、デフォルトでVPC ALBが作成されます。

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

(プライベートNLBでは必須）プライベートリクエストを受け付けるサービスを指定するためのアノテーション。 このアノテーションが含まれていない場合、パブリックVPC NLBが作成される。

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

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

externalTrafficPolicy

Local または Cluster を指定します。

Local に設定すると、クライアント要求のソース IP アドレスがアプリに保存されます。 この設定により、受信トラフィックが別のノードに転送されるのを防ぐことができる。 このオプションは、HTTP ヘルス・チェックも構成します。

Cluster に設定すると、VPC NLB が最初に着信要求を転送するワーカー・ノードからのみ DSR が実装されます。 着信リクエストが到着すると、リクエストはアプリポッドを含むワーカーノードに転送される。 アプリ・ポッドからの応答が元のワーカー・ノードに送信されると、そのワーカー・ノードが 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-lb-name

VPCロードバランサーを永続化するために一意な名前を付けましょう。 永続的なVPCロードバランサーは、所属するクラスタが削除されても削除されません。 詳細については、永続的VPCロードバランサー を参照してください。 このアノテーションはロードバランサーの作成時にのみ設定できます。 更新作業では使用できない。

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

クラスターが接続されている VPC ゾーンを指定するアノテーション。 VPC NLB が、そのゾーンのワーカー・ノードが接続されているのと同じサブネットにデプロイされます。 後でこのアノテーションを別のゾーンに変更しても、VPC NLB は新しいゾーンに移動しません。 このアノテーションまたは service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets annotation を指定しない場合、VPC NLBは最適なゾーン（Ready 状態のワーカーノードがあるゾーンなど）にデプロイされます。 ワーカーノードに dedicated: edge ラベルが設定されていて、このアノテーションを指定すると、指定されたゾーン内のエッジノードだけがトラフィックを受信するように設定されます。 他のゾーンのエッジ・ノードや、指定したゾーンの非エッジ・ノードは、ロード・バランサーからトラフィックを受信しません。 ゾーンを見るには、 ibmcloud ks zone ls --provider vpc-gen2 を実行する。

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

ワーカーノードラベルセレクタを指定するアノテーション。 ラベルセレクタキーを指定することで、クラスタ内の特定のワーカーノードがトラフィックを受信するように設定できます。 注釈に含めることができるラベルセレクタは1つだけで、セレクタは "key=value" 形式で指定する必要があります。 このアノテーションが指定されていない場合、クラスタ内のすべてのワーカーノードが VPC NLB からのトラフィックを受信するように設定されます。 このアノテーションは service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションより優先され、ワーカーノードの dedicated: edge ラベルは無視されます。 特定のゾーンへのトラフィックを制限するには、このアノテーションを使用して、そのゾーン内のワーカーノードを指定します。 クラスタ ワーカー ノードに新しいラベルを設定しても、ワーカー ノードが自動的にトラフィックを受信するように構成されるわけではないことに注意してください。新しくラベルを設定したワーカー ノードがトラフィックを受信できるようにするには、VPC NLB を再作成または更新する必要があります。

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 ロードバランサーリソースのヘルスチェックプロトコルを設定します。 利用可能なオプションは、http、https、または tcp です。 通常、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 セキュリティグループを modify して、そのポートでのインバウンドトラフィックを許可する必要があります。 このアノテーションが VPC ALB に関連付けられた Kubernetes ロードバランサーサービスに適用される場合、VPC ALB に割り当てられたセキュリティグループの送信ルールは、指定された TCP ポートへの送信トラフィックを許可するように 変更 する必要があります。

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 パスは、 オリジンフォームリクエストターゲットの形式でなければならない。 このアノテーションが指定されず、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 です。 この値は ibm-load-balancer-cloud-provider-vpc-health-check-timeout の値より大きくなければならず、デフォルトでは 2 に設定されています。

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

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

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

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

service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"

バージョン 4.16 またはそれ以降。

ロードバランサーの IP アドレスを、指定した Ingress ドメイン に登録します。 指定されたドメインが存在しない場合、内部のIBM マネージド・プロバイダ (akamai) を使用するドメインが作成されます。新しいドメインを作成するには、既存のすべてのドメイン(クラスタ上のドメインだけではありません)で一意な名前にする必要があります。 ロードバランサーサービスを削除すると、ドメインからIPアドレスが削除されます。 しかし、注釈を削除しても、ドメインからIPアドレスは削除されない。

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

バージョン 1.30 以降。

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

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-allow-outbound-traffic

Secure by Default を実行しているクラスタで使用できます。 アノテーションを使用して、指定した外部ポートに関連付けられた ALB の各 IP アドレスにセキュリティグループを作成します。 これらのルールはクラスタセキュリティグループに作成されます。 80,443 のように、有効な外部ポートをカンマ区切りで指定します。 この例では、各外部ポート値に関連付けられた各パブリックALBに2つのIPアドレスがある場合、IPアドレスごとに1つのアウトバウンドルールが作成され、合計4つの新しいルールが作成される。 この注釈はいつでも追加・削除できる。

selector

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

port

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

targetPort

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