VPC ネットワーク・ロード・バランサーのセットアップ

VPCクラスタの各ゾーンに、パブリックまたはプライベートの Kubernetes LoadBalancer サービスを設定することで、アプリをパブリックネットワークまたはプライベートネットワークに公開します。その後、オプションで、VPC NLB を DNS レコードおよび TLS 証明書に登録します。 VPC NLB は、「 TCP 」および「 UDP 」の両方のプロトコルタイプをサポートしています。

パブリックまたはプライベート VPC の NLB の設定

クラスタの各ゾーンに Kubernetes LoadBalancer サービスを設定し、アプリをネットワークトラフィックに公開します。 Kubernetes LoadBalancer サービスを作成すると、クラスタ外の VPC 内に、アプリへのリクエストをルーティングするパブリックまたはプライベートの Network Load Balancer for VPC (VPC NLB) が自動的に作成されます。

開始前に

VPC NLB用の Kubernetes LoadBalancer サービスをデプロイするネームスペースの作家または、 マネージャー IBM Cloud IAM サービスのアクセスロールを必ず用意してください。
Red Hat OpenShift クラスターにアクセスします。
VPC NLB を表示するには、infrastructure-service プラグインをインストールします。コマンドを実行するための接頭部は、ibmcloud is です。
```
ibmcloud plugin install infrastructure-service
```
プライベートVPC NLBの場合 ： VPC VPN接続などで VPCプライベートネットワークに接続します。
プライベート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からのトラフィックやクラシック・インフラストラクチャートラフィックについては、 Transit Gateway を選択します。同じVPC内の別のゾーンからのトラフィックについては、 VPCゾーンを選択します。詳細については、 VPC VPN接続の設定を参照してください。

`LoadBalancer` サービスの設定

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

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.

クラスターに Kubernetes LoadBalancer サービスを作成します。
```
oc apply -f <filename>.yaml -n <namespace>
```
クラスターに 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:                     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.
```

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

手順 4 でわかった Kubernetes LoadBalancer サービスの IP アドレスとアプリのポートに <external_IP>:<app_port> の形式でアクセスします。
オプション: これらのステップを繰り返して、アプリを公開する各ゾーンにパブリック 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 サービスを追加で作る必要があります。

以下の 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

サービスを作る。
```
oc apply -f loadbalancer.yaml
```

先に作成した 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

「 NodePort 」サービスを作成します。
```
oc apply -f nodeport.yaml
```
NLBが提供する範囲内のポートにアクセスする。
```
curl https://<public ip assigned to NLB>:30003
```
- 30003 = リクエストに応答する範囲内のノードポートである
- 範囲内の他のポートは、追加のノード・ポート・サービスが作成されない限り、応答しない。

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 の資料を参照してください。

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

以下の手順に従って、VPC NLB の IP アドレスを DNS サブドメインに登録してください。

ロード・バランサーの外部 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

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>
```
Web ブラウザーを開き、サブドメインを使用してアプリにアクセスするための URL を入力します。

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

注釈と仕様

必須およびオプションの VPC NLB 注釈と仕様を確認してください。

必要な注釈と仕様

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_ID --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セキュリティグループを変更し、そのポートでの受信トラフィックを許可する必要があります。このアノテーションを、VPC ALBに関連付けられた Kubernetes ロードバランサーサービスに適用する場合、VPC ALBに割り当てられたセキュリティグループのアウトバウンドルールを変更し、指定された TCP ポートへのアウトバウンドトラフィックを許可する必要があります。詳細については、「デフォルトでセキュアなクラスタVPCネットワークについて」および「 VPCセキュリティグループの作成と管理」を参照してください。
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 管理プロバイダ (IBM NS1) を使用するドメインが作成されます。新しいドメインを作成するには、その名前が（クラスタ上のドメインだけでなく）既存のすべてのドメインで一意である必要があります。ロードバランサーサービスを削除すると、ドメインから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-managedセキュリティ・グループを削除し、指定したセキュリティ・グループに置き換える。既存のロードバランサーからアノテーションを削除すると、追加したセキュリティグループが IBM-managedセキュリティグループに置き換わります。この注釈はいつでも追加・削除できる。あなたは、自分のセキュリティ・グループを管理し、最新の状態に保つ責任があります。
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に設定されている外部ポートとも異なる可能性があります。

VPC ネットワーク・ロード・バランサーのセットアップ

VPC ネットワーク・ロード・バランサーのセットアップ

パブリックまたはプライベート VPC の NLB の設定

開始前に

LoadBalancer サービスの設定

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

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

注釈と仕様

必要な注釈と仕様

オプションの注釈と仕様

`LoadBalancer` サービスの設定