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-features
と service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type
です。
LoadBalancer
サービスで指定するポートとノードポートは、VPCロードバランサーが作成したものと一致する必要はありません。 VPC ロードバランサは、新しいクラスタ内のどの LoadBalancer
サービスに関連付けられているポート定義でも再設定します。
ロード・バランサーのヘルス・チェック
VPC ロードバランサは自動的にヘルスチェックが設定され、externalTrafficPolicy
アノテーションで設定します。 追加のアノテーションを使って、ロードバランサーのヘルスチェックをカスタマイズする ことができます。
externalTrafficPolicy
がCluster
に設定されている場合、TCP ヘルス・チェックが適用されます。 UDP ロード・バランサーを構成する場合は、追加のポートを指定する必要があります。externalTrafficPolicy
がLocal
に設定されている場合、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
も指定されている場合にのみ適用されます。- 指定されたTCPポートがKubernetesノードのポート範囲 (30,000-32,767) の外側にある場合、クラスタワーカーノードに適用されるVPCセキュリティグループを 変更して、そのポートのインバウンドトラフィックを許可する必要があります。
- このアノテーションが 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
です。
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 ヘルス・チェックを使用するには、externalTrafficPolicy
を Local
に設定します。
ロードバランサーのサブネットやゾーンを変更する
VPC NLBを作成した後、そのリスニングサブネットを再構成することはできません。 既存のVPC NLBのリスニングサブネットを変更したい場合は、対応するKubernetes LoadBalancer
サービスを削除、更新、再適用する必要があります。
-
アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
-
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
-
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 ロードバランサー名の KubernetesLoadBalancer
サービス 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
-
Kubernetes
LoadBalancer
サービス定義を取得し、my-lb.yaml
という名前の yaml ファイルとして出力を保存します。kubectl describe service my-load-balancer -o yaml
-
Kubernetes
LoadBalancer
サービスを削除します。 これにより、対応する VPC ロード・バランサーも削除されます。kubectl delete service my-load-balancer
-
実装するサブネットまたはゾーンの変更内容で Kubernetes
LoadBalancer
サービス定義ファイルを更新します。LoadBalancer
サービスの名前は変更しないでください。 ネットワーク・ロード・バランサーのサブネットまたはゾーンの指定について詳しくは、「Network Load Balancer for VPC のセットアップ (Setting up a Network Load Balancer for VPC)」を参照してください。 -
新しい
LoadBalancer
定義ファイルを適用します。kubectl apply -f my-lb.yaml
-
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.
-
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