Service ロードバランサーと CCM リソース更新ポリシーを設定する際の考慮事項 - Container Service for Kubernetes

Service のタイプをロードバランシング (Type=LoadBalancer) に設定すると、ACK の cloud-controller-manager (CCM) コンポーネントが Service 用の Server Load Balancer (SLB) インスタンスを作成または設定します。インスタンスは、Classic Load Balancer (CLB) または Network Load Balancer (NLB) のいずれかです。設定には、インスタンス、リスナー、バックエンドサーバーグループなどのリソースが含まれます。このトピックでは、Service ロードバランサーを設定する際の考慮事項と CCM のリソース更新ポリシーについて説明します。

考慮事項

再利用できる SLB インスタンス

SLB コンソールで作成された SLB インスタンスのみが再利用できます。cloud-controller-manager によって自動的に作成された SLB インスタンスは再利用できません。
ACK クラスターで非公開 SLB インスタンスを再利用する場合、インスタンスはクラスターと同じ Virtual Private Cloud (VPC) 内にある必要があります。VPC 間の再利用は NLB インスタンスでのみサポートされます。
再利用される SLB インスタンスのアドレスタイプは、Service のアクセスタイプと一致する必要があります。Service が [パブリックネットワークアクセス] (service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet") に設定されている場合、SLB インスタンスの [アドレスタイプ] は [パブリック] である必要があります。Service が [内部アクセス] (service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet") に設定されている場合、SLB インスタンスの [アドレスタイプ] は [プライベート] である必要があります。
複数の Service が同じ SLB インスタンスの同じリスナーポートを使用することはできません。
クラスター間で既存の SLB インスタンスを再利用する場合、名前空間と Service 名の組み合わせが各クラスターで一意であることを確認してください。

CCM で SLB インスタンスを管理する際の考慮事項

CCM は、Type=LoadBalancer の Service に対してのみ SLB インスタンスを設定します。CCM は、他のタイプの Service に対して SLB インスタンスを設定しません。

重要

Type=LoadBalancer の Service が Type!=LoadBalancer に変更されると、CCM はロードバランサー用に追加された設定を削除するため、ロードバランサー経由で Service にアクセスできなくなります。

CCM は宣言型 API を使用し、特定の条件下で Service の設定に基づいて SLB の設定を自動的にリフレッシュします。service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: を "true" に設定すると、SLB コンソールで変更した設定が上書きされる危険性があります。

重要

SLB コンソールで ACK によって作成および維持されている SLB インスタンスの設定を手動で変更しないでください。変更すると、設定が失われ、Service にアクセスできなくなる可能性があります。

Service の service.k8s.alibaba/resources または service.k8s.alibaba/nlb ファイナライザーを手動で削除または変更しないでください。ファイナライザーを手動で変更すると、CLB または NLB リソースが正しく取り消されなくなる可能性があります。
Cloud Controller Manager のバージョンが v2.5.0 以降の場合、コンソールで Service を作成する際に CLB インスタンスを使用するオプションはホワイトリスト機能です。この機能を使用するには、Quota Center プラットフォームでリクエストを送信してください。

単一クラスターで大規模な SLB インスタンスを CCM で管理する際の考慮事項

CCM には、Service イベントを処理する能力に制限があります。多くのノードまたは多くの LoadBalancer タイプの Service を持つ大規模なクラスターでは、CCM で遅延が発生する可能性があります。これは、多数の Service を作成または削除したり、多数の Service エンドポイントを同時に変更したり、ノードを追加または削除したりするときに発生する可能性があります。この遅延は、SLB インスタンスの作成と削除、サーバーグループ内のエンドポイントの更新などの操作に影響します。

ビジネスでバッチ変更を実行するには、事前にキャパシティを評価し、ストレステストを実行してください。これにより、CCM の処理遅延によるビジネスの中断を防ぐことができます。

Service の SLB インスタンスを置き換える方法

既存の LoadBalancer タイプの Service に SLB インスタンスを再割り当てすることはできません。SLB インスタンスを置き換えるには、Service を削除してから再作成してください。

クォータ制限

VPC

クラスター内の各ノードは 1 つのルートエントリに対応します。デフォルトでは、VPC は 200 個のルートエントリしかサポートしません。クラスターに 200 を超えるノードがある場合は、Quota Centerコンソールにログインしてアプリケーションを送信してください。
VPC の制限の詳細については、「制限とクォータ」をご参照ください。
VPC クォータをクエリするには、「VPC クォータ管理」をご参照ください。

Server Load Balancer

CCM は、Type=LoadBalancer の各 Service に対して SLB インスタンスを作成します。デフォルトでは、ユーザーは最大 60 個のインスタンスを持つことができます。60 個を超えるインスタンスが必要な場合は、Quota Centerコンソールにログインしてアプリケーションを送信してください。
CCM は、Service の設定に基づいて、Elastic Compute Service (ECS) インスタンスを SLB インスタンスのバックエンドサーバーグループにアタッチします。
- デフォルトでは、ECS インスタンスは 50 個のバックエンドサーバーグループにアタッチできます。ECS インスタンスをより多くのバックエンドサーバーグループにアタッチする必要がある場合は、Quota Centerコンソールにログインしてアプリケーションを送信してください。
- デフォルトでは、SLB インスタンスは 200 個のバックエンドサーバーを持つことができます。バックエンドサーバーを追加するには、Quota Centerコンソールにログインしてアプリケーションを送信してください。
CCM は、Service で定義されたポートに基づいてリスナーを作成します。デフォルトでは、SLB インスタンスは 50 個のリスナーを持つことができます。リスナーを追加するには、Quota Centerコンソールにログインしてアプリケーションを送信してください。
SLB の制限の詳細については、「CLB の制限」および「NLB の制限」をご参照ください。
SLB クォータをクエリするには、「Server Load Balancer クォータ管理」をご参照ください。

SLB インスタンスの更新ポリシー

ACK では、Service に既存の SLB インスタンスを指定するか、CCM に新しいインスタンスを自動的に作成させることができます。これら 2 つのメソッドのリソース更新ポリシーは、次の表に示すように異なります。

リソースオブジェクト	既存の SLB インスタンスを指定する	CCM に SLB インスタンスを管理させる
Server Load Balancer	アノテーションを設定します: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id`。 CCM はこのインスタンスを Service のロードバランサーとして使用します。他のアノテーションに基づいて SLB インスタンスを設定し、複数の vServer グループを自動的に作成します。 Service が削除されても、CCM は ID で指定した既存の SLB インスタンスを削除しません。	CCM は、Service の設定に基づいて、SLB インスタンス、リスナー、vServer グループなどのリソースを自動的に作成および設定します。これらのリソースはすべて CCM によって管理されます。 Service が削除されると、CCM は自動的に作成された SLB インスタンスを削除します。
リスナー	アノテーションを設定します: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners`: `"false"` に設定した場合、CCM は SLB インスタンスのリスナー設定を管理しません。 `"true"` に設定した場合、CCM は Service の設定に基づいてリスナーを管理します。リスナーが既に存在する場合、CCM はそれを上書きします。	CCM は、Service の設定に基づいてリスナーポリシーを自動的に作成および設定します。
バックエンドサーバーグループ	Service のバックエンドエンドポイントまたはクラスターノードが変更されると、CCM は SLB インスタンスのバックエンド vServer グループを自動的に更新します。 Terway ネットワークプラグインの場合、CCM はデフォルトで ECS ノードをアタッチする代わりに、Pod IP を SLB インスタンスのバックエンドにアタッチします。 Flannel ネットワークプラグインの場合、バックエンドサーバーグループの更新ポリシーは Service モードによって異なります。クラスターモード (`spec.externalTrafficPolicy = Cluster`): CCM は、デフォルトで (BackendLabel タグを使用してバックエンドを設定しない限り) すべてのノードを SLB インスタンスのバックエンドにアタッチします。重要 SLB には、ECS インスタンスを追加できる SLB インスタンスの数にクォータ制限があります。このメソッドはクォータを急速に消費します。クォータが使い果たされると、Service の調整は失敗します。この問題を解決するには、Service にローカルモードを使用します。ローカルモード (`spec.externalTrafficPolicy = Local`): CCM は、デフォルトで Service の Pod を実行するノードのみを SLB インスタンスのバックエンドに追加します。これにより、SLB クォータの消費が遅くなり、レイヤー 4 のソース IP 保持がサポートされます。 Flannel ネットワークプラグインの場合、CCM はマスターノードを SLB インスタンスのバックエンドに追加しません。 Flannel ネットワークプラグインの場合、CCM はデフォルトで、ドレインされた (`kubectl drain`) またはスケジュール不可 (`kubectl cordon`) のノードを SLB インスタンスのバックエンドから削除しません。これらのノードを削除するには、`service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend` を `on` に設定します。

Service の削除保護を有効にする

重要なビジネスや機密データを含む Service に対して削除保護を有効にすることで、誤って削除されるのを防ぐことができます。この機能を有効にすると、対応するリソースは、手動で削除保護を無効にした後にのみ削除できます。Service の削除保護を有効にする方法の詳細については、「Service の削除保護を有効にする」をご参照ください。