IBM Cloud Docs
VPC アプリケーション・ロード・バランサーのセットアップ

VPC アプリケーション・ロード・バランサーのセットアップ

クラスターで Kubernetes LoadBalancer サービスをセットアップして、アプリをパブリック・ネットワークまたはプライベート・ネットワークに公開します。 アプリを公開すると、要求をアプリに転送する VPC アプリケーション・ロード・バランサー (VPC ALB) が VPC 内のクラスターの外に自動的に作成されます。 その後、オプションで VPC ALBをDNSレコードとTLS証明書で登録 できます。 VPC ALBはTCPプロトコルのみをサポートします。

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

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

開始前に

アプリが公開または非公開のリクエストを受信できるようにします：

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

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

    VPC ALBを簡単に識別できるようにするには、<app_name>-vpc-alb-<VPC_zone> という形式でサービス名を付けることを検討してください。

    apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "`<app_name>-vpc-alb-<VPC_zone>`"
    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>"
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 サービスを作成します。

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

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

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

    kubectl describe svc myloadbalancer -n <namespace>

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

    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であることを確認します。

    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 Infrastructure セクションを使用して直接更新できます。 たとえば、フロントエンド・リスナーのポートやヘルスチェックのタイムアウト値を変更する。 しかし、 Kubernetes または OpenShift クラスターに結びついたVPCロードバランサーについては、Ingressコンフィギュレーションのアノテーションによって更新を行う必要がある。 IBM Cloud Providerは関連する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などです。

    kubectl 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をCNAME (Canonical Name record)として 1234abcd-us-south.lb.appdomain.cloud の形式で指定してエイリアスを与えます。

      1. ドメイン・ネーム・サービス (DNS) プロバイダーを利用するか、または IBM Cloud DNS を使用して、カスタム・ドメインを登録します。
      2. ロードバランサの外部IPをCanonical Nameレコード(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 CloudDNSを使用する場合は、必ず末尾にピリオドを入力することに注意してください。

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

      1. DNS サブドメインと TLS 証明書を作成します。
        ibmcloud ks nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
      2. サブドメインが作成されたことを確認します。 詳しくは、サブドメインのフォーマットについてを参照してください。
        ibmcloud ks 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 用にサブドメインを作成した場合は、ウェブブラウザを開き、 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レコードの登録

バージョン 1.28 以降では、以下のオプションアノテーションを使用して、カスタム DNS zone を提供する独自 DNS instance をプライベート VPC ALB に関連付けることができます。 そのためには、両方のオプションの注釈を設定しなければならない。 もし未指定の場合は、このロードバランサの hostname プロパティに対する DNS A レコードがパブリック 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 ≤ length ≤ 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 ALBの注釈と仕様を確認する。

必要な注釈と仕様

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "alb"
VPC ALBを作成するためのアノテーション。 service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features を含めない場合、デフォルトでVPC ALBがプロビジョニングされます。
service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
(プライベートVPC ALBでは必須）パブリックまたはプライベートのリクエストを受け付けるサービスを指定するためのアノテーション。 このアノテーションが含まれていない場合、パブリックVPC ALBが作成される。
externalTrafficPolicy
app pod を含むワーカーノードにリクエストを転送するには Cluster を指定します。 このワーカーノードは別のゾーンにあるかもしれない。 デフォルトでは、この注釈は Cluster に設定されている。
Local を指定すると、受信トラフィックが別のノードに転送されるのを防ぐことができます。 このオプションは、HTTP ヘルス・チェックも構成します。
VPC ALBで元のクライアントのソースIPを使用するには、service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol" アノテーションでPROXYプロトコルを有効にする必要があることに注意してください。

オプションの注釈と仕様

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name
VPCロードバランサーを永続化するために一意な名前を付けましょう。 永続的なVPCロードバランサーは、所属するクラスタが削除されても削除されません。 詳細については、永続的VPCロードバランサー を参照してください。 このアノテーションはロードバランサーの作成時にのみ設定できます。 更新作業では使用できない。
service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
PROXY プロトコルを有効にします。 ロード・バランサーは、クライアントの IP アドレス、プロキシー・サーバーの IP アドレス、両方のポート番号などのクライアント接続情報を要求ヘッダーに入れてバックエンド・アプリに渡します。 PROXY プロトコルを受け入れるようにバックエンド・アプリを構成しておく必要があります。 たとえば、 以下の手順で PROXYプロトコルを受け入れるようにNGINXアプリを設定できます。
service.kubernetes.io/ibm-load-balancer-cloud-provider-zone
クラスターが接続されている VPC ゾーンを指定するアノテーション。 このアノテーションでゾーンを指定すると、2つの処理が発生します：(1) VPC ALB は、ワーカーノードが接続されているゾーン内の同じサブネットにデプロイされ、(2) このゾーン内のクラスタ内のワーカーノードのみが VPC ALB からのトラフィックを受信するように設定されます。 ロード・バランサーを特定のゾーンに配置するには、ロード・バランサーを作成する際にこのアノテーションを指定する必要があります。 後でこのアノテーションを別のゾーンに変更すると、リスニングノードとバックエンドワーカーノードは新しいゾーンに合わせて自動的に更新されます。 ワーカーノードに dedicated: edge ラベルが設定されていて、このアノテーションを指定すると、指定されたゾーン内のエッジノードだけがトラフィックを受信するように設定されます。 他のゾーンのエッジ・ノードや、指定したゾーンの非エッジ・ノードは、ロード・バランサーからトラフィックを受信しません。 ゾーンを見るには、 ibmcloud ks zone ls --provider vpc-gen2 を実行する。
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets
VPC ALB サービスがデプロイされる 1 つ以上のサブネットを指定するためのアノテーション。 指定した場合、このアノテーションは service.kubernetes.io/ibm-load-balancer-cloud-provider-zone アノテーションよりも優先されます。 このアノテーションがないと、クラスタがシングルゾーンからマルチゾーンに更新された場合、またはその逆の場合、VPC ALBが展開するサブネットはクラスタのゾーンに合わせて自動的に更新されます。 同じ VPC にあるサブネットで、クラスターが接続されているものとは別のサブネットを指定できることに留意してください。 その場合、VPC ALB は同じ VPC 内の別のサブネットにデプロイされますが、それでもクラスター・サブネット上のワーカー・ノードにトラフィックを転送できます。 すべてのリソース・グループのサブネットを確認するには、ibmcloud ks subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone> を実行します。 この注釈は、既存のVPC ALBに追加または変更することができる。
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 ラベルは無視されます。 特定のゾーンへのトラフィックを制限するには、このアノテーションを使用して、そのゾーン内のワーカーノードを指定します。 クラスタ ワーカー ノードに新しいラベルを設定しても、ワーカー ノードが自動的にトラフィックを受信するように構成されるわけではないことに注意してください。新たにラベルを設定したワーカー ノードがトラフィックを受信できるようにするには、VPC ALB を再作成または更新する必要があります。
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 も指定されている場合にのみ適用されます。
クラスタが Secure by Default を実行していない場合、適用されるVPCセキュリティ・グループに対して以下の修正が必要になる可能性があります。 クラスタがSecure by Defaultを実行している場合、これらの変更は自動的に適用されます。
  • 指定された 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-vpc-idle-connection-timeout
リスナーのアイドル接続タイムアウト（秒） 。 デフォルトのアイドルタイムアウトは、アカウント設定によって異なります。 通常、この値は 50 です。 ただし、許可リストに登録されたアカウントの中には、より大きなタイムアウト設定を持つものもある。 アノテーションを設定しないと、ロードバランサーはアカウントのタイムアウト設定を使用します。 このアノテーションを設定することで、タイムアウトを明示的に指定できます。 最小は 50 です。 最大値は 7200。
service.kubernetes.io/ibm-load-balancer-cloud-provider-dns-name: "example-ingress-domain.<region>.containers.appdomain.cloud"
バージョン 1.30 またはそれ以降。
ロードバランサーの IP アドレスを、指定した Ingress ドメイン に登録します。 指定されたドメインが存在しない場合、内部のIBM マネージド・プロバイダ (akamai) を使用するドメインが作成されます。新しいドメインを作成するには、既存のすべてのドメイン(クラスタ上のドメインだけではありません)で一意な名前にする必要があります。 ロードバランサーサービスを削除すると、ドメインからIPアドレスが削除されます。 しかし、注釈を削除しても、ドメインからIPアドレスは削除されない。
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"
バージョン 1.28 またはそれ以降。
このロードバランサーに関連付ける DNS instance を指定します。 詳細については、プライベートDNSレコードの登録 を参照してください。
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"
バージョン 1.28 またはそれ以降。
このロードバランサーに関連付ける DNS zone を指定します。 詳細については、プライベートDNSレコードの登録 を参照してください。
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 アドレスにセキュリティグループを作成します。 これらのルールはクラスタセキュリティグループに作成され、VPC 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に設定されている外部ポートとも異なる可能性があります。

  1. a-z0-9- ↩︎