IBM Cloud Docs
VPCロードバランサーの管理

VPCロードバランサーの管理

既存のVPCロードバランサーに変更を加えます。

VPC NLBまたはALBの名前は変更しないでください。 VPC ロードバランサーの名前を変更すると、Kubernetes LoadBalancer サービスでエラーが発生し、ワークロードが中断する可能性があります。

永続的なVPCロードバランサー

デフォルトでは、VPCロードバランサーは関連付けられているクラスタが削除されると削除されます。 しかし、LoadBalancer サービス定義を作成するときに、ロードバランサを永続化することができます。 永続的なVPCロードバランサーは、前のクラスタが削除された後でも別のクラスタに適用できます。

VPCロードバランサー名はデフォルトでは kube-<cluster_ID>-<kubernetes_lb_service_UID> のようにフォーマットされます。 クラスタが削除されると、この名前形式では関連するロードバランサも削除されます。 クラスタを削除したときにロードバランサが削除されないようにするには、 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name アノテーションを LoadBalancer サービス定義に含めてロードバランサに一意な名前をつけます。 ロードバランサ名は VPC 内で一意でなければならず、小文字の英数字とハイフン (-) しか使えません。このアノテーションは全ての VPC ロードバランサータイプに適用できます。

永続的なVPCロードバランサーは、不要になったら削除する責任があります。 永続的なVPCロードバランサーを削除するには、そのVPCロードバランサーが関連付けられているKubernetes LoadBalancer サービス定義を削除します。

VPCロードバランサーをクラスタ間で移動する

永続的VPCロードバランサー は、あるVPCクラスタから切り離し、別のVPCクラスタに接続することができます。 新しいクラスタは元のクラスタと同じVPC内になければならない。

クラスタからVPCロードバランサを切り離す

VPCロードバランサーは、Kubernetes LoadBalancer で作成されたサービス定義にリンクされています。 永続的なVPCロードバランサーをクラスタから切り離すには、LoadBalancer サービスとのリンクを切断する必要があります。 そうすることで、LoadBalancer サービスは使えなくなり、安全に削除することができます。 VPCロードバランサーは、別のクラスタ に接続することができます。

VPCロードバランサーと LoadBalancer サービス間のリンクを解除するには、VPCロードバランサーの名前を変更するか、元の LoadBalancer サービス定義から service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name アノテーションを削除します。 Note that this is the のみ circumstance in which you should rename a VPC load balancer, as doing so creates an error for the Kubernetes resource. しかし、最終的な目的が別のクラスタでVPCロードバランサーを使用することであれば、このエラーによってワークロードが中断されることはありません。 ロードバランサーを同じクラスタに維持したい場合は、VPCロードバランサーの名前を変更しないでください。

VPCロードバランサをクラスタにアタッチする

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

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

LoadBalancerサービスを作成する場合、VPCロードバランサータイプ(ALB, NLB)とIPタイプ(public, private)は、LoadBalancer サービスの仕様と一致している必要があります。 たとえば、NLBタイプを指定する新しいクラスタ上の既存の LoadBalancer サービスは、クラスタにVPC ALBをアタッチするために使用できません。 ロードバランサータイプとIPタイプを指定するアノテーションは service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-featuresservice.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type です。

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

ロード・バランサーのヘルス・チェック

VPC ロードバランサは自動的にヘルスチェックが設定され、externalTrafficPolicy アノテーションで設定します。 追加のアノテーションを使って、ロードバランサーのヘルスチェックをカスタマイズする ことができます。

  • externalTrafficPolicyCluster に設定されている場合、TCP ヘルス・チェックが適用されます。 UDP ロード・バランサーを構成する場合は、追加のポートを指定する必要があります
  • externalTrafficPolicyLocal に設定されている場合、HTTP ヘルス・チェックが適用されます。 着信トラフィックは、特定のノードに存在するアプリケーション・ポッドにのみ配信される。 特定のノードにアプリケーション・ポッドがない場合、受信トラフィックはドロップされる。

externalTrafficPolicy: Local の設定はロードバランサーのワーカーノードのヘルスチェックを失敗させるかもしれません。 通常、ロードバランサーがアプリケーションポッドを持たないノードに接続しようとした場合、トラフィックは意図的にドロップされるため、この結果は予期された動作であり、必ずしも問題を示すものではありません。 詳しくは、ワーカーノードでVPCロードバランサーのヘルスチェックが失敗するのはなぜですか をご覧ください。

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

VPCロードバランサーのヘルスチェックをよりコントロールするために、オプションのアノテーションを使って、テスト間隔、タイムアウト、リトライの高度な設定でヘルスチェックをカスタマイズすることができます。 これらのカスタマイズはいつでも変更または削除できます。

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol
Optional: このアノテーションは、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 も指定されている場合にのみ適用されます。
service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path
オプション。 HTTP とHTTPsのヘルスチェック用の URL パス。 この注釈は、ibm-load-balancer-cloud-provider-vpc-health-check-protocolhttp または 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 です。

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

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

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

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

UDPロードバランサーでヘルスチェックのために追加のTCPポートを指定する複雑さを避けたいですか? 追加のポート指定を必要としない HTTP ヘルス・チェックを使用するには、externalTrafficPolicyLocal に設定します。

ロードバランサーのサブネットやゾーンを変更する

VPC NLBを作成した後、そのリスニングサブネットを再構成することはできません。 既存のVPC NLBのリスニングサブネットを変更したい場合は、対応するKubernetes LoadBalancer サービスを削除、更新、再適用する必要があります。

  1. アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

  2. Kubernetes サービスをリストし、変更する LoadBalancer サービスの名前を見つけます。

    kubectl get services
    

    出力例。

    NAME                     TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)                        AGE
    my-load-balancer         LoadBalancer   172.21.77.198   52.118.150.107   8080:32767/TCP,443:30943/TCP   5d
    
  3. Kubernetes LoadBalancer サービスに対応する VPC ロード・バランサーを見つけます。

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

    ibmcloud is load-balancers
    

    出力例。

    ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group      
    r000-5aaaa11f6-c111-111f-b2e0-1c11aaaaf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf11111111fe4ca3f11111cb   Network       subnet-1                                  true        active             online             default                                                    Application      
    
  4. Kubernetes LoadBalancer サービス定義を取得し、my-lb.yaml という名前の yaml ファイルとして出力を保存します。

    kubectl describe service my-load-balancer -o yaml
    
  5. Kubernetes LoadBalancer サービスを削除します。 これにより、対応する VPC ロード・バランサーも削除されます。

    kubectl delete service my-load-balancer
    
  6. 実装するサブネットまたはゾーンの変更内容で Kubernetes LoadBalancer サービス定義ファイルを更新します。 LoadBalancer サービスの名前は変更しないでください。 ネットワーク・ロード・バランサーのサブネットまたはゾーンの指定について詳しくは、「Network Load Balancer for VPC のセットアップ (Setting up a Network Load Balancer for VPC)」を参照してください。

  7. 新しい LoadBalancer 定義ファイルを適用します。

    kubectl apply -f my-lb.yaml
    
  8. Kubernetes LoadBalancer サービスがクラスター内で正常に再作成されたことを確認します。 サービスが作成されると、 LoadBalancer Ingress フィールドにNLBの外部IPアドレスが入力される。

    kubectl describe service my-load-balancer
    

    出力例。

    NAME:                     my-load-balancer
    Namespace:                default
    Labels:                   <none>
    Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
    Selector:                 app=echo-server
    Type:                     LoadBalancer
    IP:                       172.X.XXX.XX
    LoadBalancer Ingress:     169.XXX.XXX.XXX
    Port:                     tcp-80  80/TCP
    TargetPort:               8080/TCP
    NodePort:                 tcp-80  32022/TCP
    Endpoints:                172.XX.XX.XXX:8080,172.XX.XX.XX:8080,172.XX.XX.XX:8080 + 3 more...
    Session Affinity:         None
    External Traffic Policy:  Local
    HealthCheck NodePort:     30882
    Events:
        Type     Reason                           Age                  From                Message
    ----     ------                           ----                 ----                -------
    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/my-load-balancer with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
    
  9. VPC ロード・バランサーが再作成され、サブネットまたはゾーンが更新されたことを確認します。 VPC ロードバランサーのプロビジョニングには数分かかり、完全にプロビジョニングされるまで create_pending のステータスが表示されるかもしれないことに注意してください。

    ibmcloud is load-balancers
    

    出力例。

    ID                                          Name                                                         Family        Subnets                                       Is public   Provision status   Operating status   Resource group     
    r006-5ecc68f6-c751-409f-b2e0-1c69babf0dc0   kube-c441c43d02mb8mg00r70-3e25d0b5bf03445796fe4ca3f73885cb   Network       subnet-2                                  true        active             online             default