LoadBalancerサービスの設定に関する考慮事項と、CCMがSLBリソースを更新するために使用するポリシー - Container Service for Kubernetes

サービスにType=LoadBalancerを指定した場合、Container Service for Kubernetes (ACK) のクラウドコントローラマネージャー (CCM) は、SLBインスタンス、リスナー、バックエンドサーバーグループなど、サービス用のServer Load Balancer (SLB) リソースを作成および構成します。サポートされているSLBインスタンスのタイプは、Classic Load Balancer (CLB) とNetwork Load Balancer (NLB) です。このトピックでは、LoadBalancerサービスの設定に関する考慮事項と、CCMがSLBリソースを更新するために使用するポリシーについて説明します。

使用上の注意

SLBインスタンスの再利用

SLBコンソールを使用して作成されたSLBインスタンスのみを再利用できます。 CCMによって自動的に作成されたSLBインスタンスを再利用することはできません。
ACKクラスターで内部対応のSLBインスタンスを再利用する場合、インスタンスはACKクラスターと同じ仮想プライベートクラウド (VPC) にある必要があります。 VPC間シナリオで再利用できるのはNLBインスタンスのみです。
再利用するSLBインスタンスのネットワークタイプは、サービスのアクセスタイプと同じである必要があります。 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet" を指定してサービスのインターネットアクセスを有効にする場合、SLBインスタンスのネットワークタイプはインターネット接続である必要があります。 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" を指定してSLBインスタンスの内部アクセスを有効にする場合、SLBインスタンスのネットワークタイプは内部対応である必要があります。
SLBインスタンスのリスニングポートは、一度に複数のサービスで使用することはできません。
クラスター間で既存のSLBインスタンスを再利用するには、異なる名前空間にデプロイされていない限り、SLBインスタンスによって公開されるサービスの名前が異なることを確認する必要があります。

CCMによるロードバランシング管理

CCMは、Type=LoadBalancer設定のサービスのみのSLBリソースを作成および構成します。

重要

サービスの設定をType=LoadBalancerからType!=LoadBalancerに変更すると、CCMはサービス用に作成されたSLBインスタンスの設定を削除します。その結果、SLBインスタンスを使用してサービスにアクセスすることはできません。

CCMは宣言型APIを使用し、特定の条件が満たされたときに、公開されたサービスの設定と一致するようにSLBインスタンスの設定を自動的に更新します。 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: をtrueに設定した場合、SLBコンソールで変更したSLB設定がCCMによって上書きされる可能性があります。

重要

CCMによって作成および管理されるSLBインスタンスの場合、SLBコンソールでインスタンスの設定を変更しないことを推奨します。そうしないと、CCMは構成を上書きし、関連するサービスにアクセスできなくなる可能性があります。

CCMによる大規模SLBインスタンスの管理に関する考慮事項

CCMには、サービスイベントの処理に一定の制限があります。大規模なクラスター、特に多数のノードまたは多数のLoadBalancerサービスがあるクラスターでは、次のような状況により、SLBインスタンスに関連する操作が遅延し、CCMによって実行されるサーバーグループエンドポイントが変更される可能性があります。

多数のサービスの作成または削除。
多数のサービスエンドポイントへの同時変更。
多くのLoadBalancerサービスが存在する場合のノードの追加と削除。

ビジネス要件を満たすために一括変更を実行する場合は、事前に容量評価とストレステストを実施することが不可欠です。これにより、CCM処理の遅延から発生する可能性のあるビジネスの混乱を防ぐことができます。

サービスのSLBインスタンスを置き換える必要がある場合はどうすればよいですか?

LoadBalancerサービスの場合、サービスに対して指定または作成されたSLBインスタンスを変更することはできません。この場合、SLBインスタンスを置き換えるには、サービスを削除して再作成します。

Quotas

[VPC]

クラスタ内のノードは、ルートテーブル内のルートエントリにマッピングされる。デフォルトでは、VPCの各ルートテーブルに最大200のエントリを含めることができます。クラスター内のノード数が200を超える場合は、クォータの増加を申請します。Quota Centerコンソールにログインしてアプリケーションを送信。
VPCに関連する制限とクォータの詳細については、「制限とクォータ」をご参照ください。
VPCリソースクォータを照会するには、VPCコンソールのクォータ管理ページに移動します。

SLB

CCMは、Type=LoadBalancer設定でサービスのSLBインスタンスを作成します。デフォルトでは、Alibaba Cloudアカウント内に最大60個のSLBインスタンスを持つことができます。より多くのSLBインスタンスを作成するには、Quota Centerコンソールにログインしてアプリケーションを送信でクォータの増加を申請します。
CCMは、サービス設定に基づいて、ECS (Elastic Compute Service) インスタンスをSLBインスタンスのバックエンドサーバーグループに自動的に追加します。
- デフォルトでは、1つのECSインスタンスを最大50のバックエンドサーバーグループに追加できます。 ECSインスタンスをより多くのバックエンドサーバーグループに追加するには、Quota Centerコンソールにログインしてアプリケーションを送信でクォータの増加を申請します。
- デフォルトでは、最大200台のバックエンドサーバーをSLBインスタンスに追加できます。 SLBインスタンスにバックエンドサーバーを追加するには、Quota Centerコンソールにログインしてアプリケーションを送信でクォータの増加を申請します。
CCMは、SLBインスタンスのサービスポートを使用するリスナーを自動的に作成します。デフォルトでは、各SLBインスタンスは最大50個のリスナーをサポートします。各SLBインスタンスでサポートされるリスナーの数を増やすには、Quota Centerコンソールにログインしてアプリケーションを送信でクォータの増加を申請します。
SLBの制限の詳細については、「CLBの制限」および「NLBの制限」をご参照ください。
SLBリソースクォータを照会するには、SLBコンソールのクォータセンターページに移動します。

SLBリソースの更新に使用するポリシー

ACKを使用すると、サービスの既存のSLBインスタンスを指定できます。 CCMを使用して、サービスのSLBインスタンスを自動的に作成することもできます。次の表に示すように、2つの方法では異なるポリシーを使用してSLBリソースを更新します。

リソースオブジェクト	既存のSLBインスタンス	CCMによって作成および管理されるSLBインスタンス
SLBインスタンス	サービスの既存のSLBインスタンスを指定するには、`Service. beta.kubernetes.io/alibaba-cloud-loadbalancer-id`という注釈を使用します。 CCMは、指定されたSLBインスタンスを使用して負荷分散を有効にし、インスタンスのvServerグループを自動的に作成します。他のアノテーションを使用して、SLBインスタンスを設定できます。サービスが削除された場合、CCMは上記のアノテーションで指定されたSLBインスタンスを削除しません。	CCMは、SLBインスタンス、リスナー、vServerグループなど、サービス設定に基づいてSLBリソースを自動的に作成、設定、管理します。サービスが削除された場合、CCMは作成されたSLBインスタンスを削除します。
リスナー	リスナーを設定するには、`service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners`を使用します。アノテーションを`false`に設定した場合、CCMはSLBインスタンスのリスナーを設定または管理しません。アノテーションを`true`に設定すると、CCMはサービス設定に基づいてSLBインスタンスのリスナーを設定および管理します。 SLBインスタンスに既存のリスナーがある場合、CCMは既存のリスナーを置き換える新しいリスナーを作成します。	CCMは、サービス設定に基づいてSLBインスタンスのリスナーを設定します。
バックエンドサーバーグループ	サービスのエンドポイントが変更されるか、クラスターノードが変更されると、CCMはサービス用に作成されたSLBインスタンスのvServerグループを自動的に更新します。クラスターがTerwayネットワークプラグインを使用している場合、CCMはデフォルトでECSノードの代わりにポッドIPアドレスをバックエンドサーバーとしてSLBインスタンスに追加します。クラスターがFlannelネットワークプラグインを使用している場合、バックエンドサーバーグループを更新するためのポリシーは、サービスのモードによって異なります。サービスに`spec.externalTrafficPolicy = Cluster`が指定されている場合、CCMはデフォルトですべてのクラスターノードをバックエンドサーバーとしてSLBインスタンスに追加します。サービス設定でノードラベルが指定されている場合、CCMは指定されたラベルを持つクラスターノードのみをSLBインスタンスに追加します。重要 ECSインスタンスを追加できるSLBインスタンスの数には制限があります。サービスがクラスターモードの場合、クォータは高いレートで消費されます。クォータが使い果たされると、サービス調整は失敗します。この問題を解決するには、サービスのローカルモードを設定します。サービスに`spec.externalTrafficPolicy = Local`が指定されている場合、CCMは、サービスのバックエンドポッドがデプロイされているノードのみをバックエンドサーバーとしてSLBインスタンスに追加します。これにより、SLBクォータの消費率を下げることができます。さらに、ソースIPアドレスは、レイヤ4ロードバランシングでも保持できます。クラスターがFlannelネットワークプラグインを使用している場合、CCMはクラスターで使用されているSLBインスタンスにマスターノードを追加しません。クラスターがFlannelネットワークプラグインを使用している場合、ノードで`kubectl drain`コマンドを実行した後、CCMはノードを削除しません。さらに、`kubectl cordon`コマンドを実行してノードをスケジュール不可としてマークした後、CCMはノードを削除しません。このようなノードを削除するには、`service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend`アノテーションを`on`に設定します。

サービスの削除保護の有効化

重要なビジネスまたは機密データを含むサービスの削除保護を有効にして、誤った削除に関連するメンテナンスコストを回避できます。この機能を有効にすると、この機能を手動で無効にした後にのみリソースを削除できます。 サービス削除保護を有効にする方法の詳細については、「サービスの削除保護の有効化」をご参照ください。