サービスロードバランシング設定と CCM リソース更新ポリシーに関する注意事項 - Container Service for Kubernetes

サービスタイプをロードバランシング、つまり Type=LoadBalancer に設定すると、Alibaba Cloud Container Service for Kubernetes (ACK) の Cloud Controller Manager (CCM) コンポーネントが、そのサービス用のロードバランサーインスタンスを作成または設定します。このインスタンスは、Classic Load Balancer (CLB) または Network Load Balancer (NLB) のいずれかです。設定には、インスタンス、リスナー、バックエンドサーバーグループなどのリソースが含まれます。この Topic では、サービスロードバランシングを設定する際の重要な注意事項と、CCM のリソース更新ポリシーについて説明します。

注意事項

どのロードバランサーを再利用できますか？

再利用できるのは、Server Load Balancer (SLB) コンソールで作成されたインスタンスのみです。cloud-controller-manager によって自動的に作成された SLB インスタンスや、API サーバーが使用するロードバランサーなど、ACK が管理する他の 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 インスタンスをクラスター間で再利用する場合、各クラスターで名前空間とサービス名の組み合わせが一意であることを確認してください。

CCM が管理するロードバランサーに関する注意事項

CCM は Type=LoadBalancer タイプのサービスのロードバランシングを設定しますが、他のタイプのサービスについては設定しません。

重要

サービスを Type=LoadBalancer から別のタイプ (Type!=LoadBalancer) に変更すると、CCM はロードバランサーの設定を削除します。これにより、SLB インスタンス経由でサービスにアクセスできなくなります。

CCM は宣言型 API を使用します。特定の条件下で、サービス設定に基づいてロードバランサーの設定を自動的にリフレッシュします。SLB コンソールで変更した設定は、上書きされるリスクがあります。

重要

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

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

クラスター内から LoadBalancer サービスの外部 IP にアクセスする際の注意事項

ネットワークプラグインのタイプ、プラグインのバージョン、およびクラスターのバージョンによっては、クラスター内から LoadBalancer サービスの CLB IP にアクセスすると、クラスターネットワークがノード上でトラフィックをインターセプトします。その後、トラフィックはバックエンドのサービスエンドポイントに直接転送されます。

このプロセスは外部の CLB インスタンスをバイパスします。これにより、CLB インスタンスに依存する特定の設定が失敗したり、アクセスに問題が発生したりする可能性があります。影響を受ける主なシナリオは次のとおりです。

externalTrafficPolicy が Local に設定されている場合：トラフィックがバックエンド Pod のないノードに転送され、アクセスが失敗する可能性があります。
Proxy Protocol が有効になっている場合：バックエンドサービスは CLB インスタンスによって追加された Proxy Protocol ヘッダーを取得できず、プロトコルのハンドシェイクが失敗します。
HTTP/HTTPS リスナーが使用されている場合：TLS 終端や X-Forwarded-For などの特定のヘッダーの追加など、CLB インスタンスに依存する操作は効果がありません。

したがって、クラスター内から LoadBalancer サービスにアクセスするには、次の方法があります。

サービスのクラスター内アドレスを使用します。この方法は標準的で、より安定しています。クラスター内のサービス間通信には、サービスの ClusterIP または <service-name>.<namespace>.svc.cluster.local のような DNS 名を使用してください。
CLB アドレスを使用する必要がある場合は、ホスト名経由でアクセスします。サービスに service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname アノテーションを追加します。その後、IP アドレスの代わりに設定したドメイン名を使用してサービスにアクセスします。これにより、トラフィックが正しく処理されるようになります。アノテーションの詳細については、「サービスのホスト名設定」をご参照ください。
重要
この機能を使用して CLB インスタンスをバイパスする場合、クライアント Pod とバックエンド Pod を同じノードにスケジュールしないようにしてください。そうしないと、非対称ルーティングの問題によりアクセスが失敗する可能性があります。

CCM を使用した単一クラスターでの大規模ロードバランシング管理に関する注意事項

CCM が処理できるサービスイベントの数には限りがあります。多数のノードや `LoadBalancer` サービスを持つ大規模なクラスターでは、CCM に遅延が発生する可能性があります。これらの遅延は、SLB インスタンスの作成や削除、サーバーグループ内のエンドポイントの更新などの操作中に発生する可能性があります。これは、サービスのバッチ作成または削除、多数のサービスエンドポイントの同時変更、またはノードの追加・削除時に一般的です。

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

サービスの SLB インスタンスを置き換える方法

既存の LoadBalancer サービスの SLB インスタンスを再利用または置き換えることはできません。SLB インスタンスを置き換えるには、サービスを削除してから再作成する必要があります。

クォータ制限

VPC

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

Server Load Balancer

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

ロードバランシングの更新ポリシー

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

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

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

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