サービスのタイプを LoadBalancer に設定すると、Alibaba Cloud Container Service for Kubernetes (ACK) の Cloud Controller Manager (CCM) コンポーネントが、当該サービス向けにロードバランサーインスタンスを作成または構成します。このインスタンスは、クラシックロードバランサー (CLB) または Network Load Balancer (NLB) のいずれかになります。管理対象リソースには、インスタンス自体、リスナー、およびバックエンドサーバーグループが含まれます。
本トピックでは、LoadBalancer 型サービスの重要な制約事項について説明し、CCM がロードバランサーリソースをどのように管理するかを解説します。
注意事項
SLB インスタンスの再利用
Server Load Balancer (SLB) コンソールで作成されたインスタンスのみを再利用してください。CCM によって作成されたインスタンスや ACK が管理するインスタンス（例：API Server のロードバランサー）は再利用できません。
SLB インスタンスを再利用する場合、以下の制約が適用されます：
VPC 要件：プライベートネットワーク用 SLB インスタンスを再利用する場合は、そのインスタンスが ACK クラスターと同じ仮想プライベートクラウド (VPC) 内にある必要があります。クロス VPC の再利用は、NLB インスタンスのみでサポートされています。
アドレスタイプの一致：再利用するインスタンスのアドレスタイプは、サービスのアクセスタイプと一致している必要があります。
パブリックネットワークアクセス (
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet") の場合は、アドレスタイプ：パブリック を指定する必要があります。内部アクセス (
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet") の場合は、アドレスタイプ：プライベート を指定する必要があります。
リスナーポートの重複禁止：同一 SLB インスタンス上で、複数のサービスが同一リスナーポートを同時に共有することはできません。
クラスター間での再利用：SLB インスタンスを複数のクラスター間で再利用する場合、各クラスター内で名前空間とサービス名の組み合わせが一意である必要があります。
CCM が管理するロードバランサー
CCM は、タイプが LoadBalancer のサービスのみを構成します。他のタイプのサービスには影響しません。
サービスのタイプを Type=LoadBalancer から他のタイプに変更した場合、CCM はロードバランサー構成を削除します。これにより、当該サービスは SLB インスタンス経由でアクセスできなくなります。
CCM は宣言型 API を使用し、サービス仕様に基づいてロードバランサー構成を自動的にリフレッシュします。SLB コンソールで行った手動変更は、上書きされる可能性があります。
ACK が作成・管理するロードバランサーインスタンスを、SLB コンソールで直接変更しないでください。手動変更により構成が失われるほか、サービスへのアクセス不能を引き起こす可能性があります。
サービスの service.k8s.alibaba/resources または service.k8s.alibaba/nlb Finalizer を手動で削除または変更しないでください。これにより、CLB または NLB リソースが正しく解放されなくなる可能性があります。
Cloud Controller Manager v2.5.0 以降では、コンソールでサービスを作成する際の CLB インスタンス選択オプションはホワイトリスト機能です。有効化するには、Quota Centerコンソールにログインしてアプリケーションを送信 してください。
SLB インスタンスの置き換え
既存の LoadBalancer サービスに対して SLB インスタンスを置き換えることはサポートされていません。異なる SLB インスタンスを使用するには、サービスを削除して再作成してください。
クラスター内からの LoadBalancer サービスへのアクセス
ネットワークプラグイン、プラグインのバージョン、およびクラスターのバージョンに応じて、クラスター内から CLB の IP アドレスへ送信されるトラフィックがノードレベルでキャッチされ、外部の CLB インスタンスをバイパスしてバックエンドのサービスエンドポイントに直接転送される場合があります。このバイパスにより、以下のシナリオが失敗します：
`externalTrafficPolicy: Local`：トラフィックがバックエンド Pod を実行していないノードに到達し、アクセス失敗を引き起こす可能性があります。
Proxy Protocol が有効化されている場合：バックエンドが CLB によって追加された Proxy Protocol ヘッダーを受信できず、プロトコルハンドシェイクが失敗します。
HTTP/HTTPS リスナー：TLS 終端および
X-Forwarded-Forなどのヘッダーが有効になりません。
推奨される方法：サービスのクラスター内アドレスを使用してください。サービス間通信には、ClusterIP または DNS 名 (<service-name>.<namespace>.svc.cluster.local) を利用します。これは最も信頼性の高い方法です。
代替方法：CLB の IP アドレスを必ず使用する必要がある場合は、IP アドレスではなくホスト名でアクセスしてください。サービスに service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname アノテーションを追加し、設定済みのドメイン名を使用します。これにより、トラフィックが CLB 経由で正しく処理されます。
ホスト名方式を利用する場合、クライアント Pod とバックエンド Pod を同一ノード上にスケジュールしないでください。同一ノード配置により、非対称ルートの失敗が発生する可能性があります。
ホスト名アノテーションの詳細については、「サービスにホスト名を設定する」をご参照ください。
大規模クラスター
CCM のイベント処理能力には上限があります。ノード数または LoadBalancer サービス数が多い大規模クラスターでは、SLB インスタンスの作成・削除やバックエンドサーバーグループ内のエンドポイント更新に遅延が発生する可能性があります。遅延を引き起こしやすい操作には以下が該当します：
サービスの一括作成または一括削除
多数のサービスエンドポイントに対する同時変更
大規模なノード追加または削除
大規模な一括変更を実行する前に、CCM の処理遅延によるサービス障害を防ぐため、容量評価および負荷テストを実施してください。
使用制限
VPC
各クラスターノードは VPC ルートテーブルのエントリを 1 つ占有します。デフォルトの制限は VPC 当たり 200 エントリです。クラスターのノード数が 200 を超える場合は、Quota Centerコンソールにログインしてアプリケーションを送信 してください。
VPC の使用制限の詳細については、「使用制限とクォータ」をご参照ください。現在の VPC クォータ使用状況を確認するには、「VPC クォータ管理」をご参照ください。
SLB
以下の使用制限が、CCM が管理する SLB インスタンスおよびバックエンドリソースに適用されます。
| リソース | デフォルト制限 | 消費要因 | 制限超過時の挙動 |
|---|---|---|---|
| アカウントあたりの SLB インスタンス数 | 60 | Type=LoadBalancer サービスごとに 1 インスタンス | サービスの調整に失敗；Quota Centerコンソールにログインしてアプリケーションを送信 |
| ECS インスタンスまたは ENI あたりのバックエンドサーバーグループ数 | 50 | CCM は targetPort ごとに 1 つのサーバーグループを作成；targetPort 値が 3 つあるサービスは、ECS インスタンスまたは ENI あたり 3 スロットを消費 | バックエンド登録に失敗；Quota Centerコンソールにログインしてアプリケーションを送信 |
| SLB インスタンスあたりのバックエンドサーバー数 | 200 | バックエンドとして登録されたノードまたは Pod | バックエンド登録に失敗；Quota Centerコンソールにログインしてアプリケーションを送信 |
| SLB インスタンスあたりのリスナー数 | 50 | サービス仕様で定義されたポートごとに 1 リスナー | リスナー作成に失敗；Quota Centerコンソールにログインしてアプリケーションを送信 |
バックエンドサーバーグループのクォータは、見た目以上に速く消費されます。CCM は targetPort ごとに 1 つのサーバーグループを作成するため、targetPort 値が 3 つあるサービスは、ECS インスタンスまたは ENI あたり 3 スロットを消費します（1 スロットではありません）。マルチポートサービスを設計する際は、これを十分に考慮してください。Flannel クラスターモードでは、すべてのノードがすべてのサービスに対して登録されるため、このクォータは急速に枯渇します。消費量を抑えるには、Local モードをご利用ください。
完全な SLB の制限については、「CLB limits」および「NLB limits」をご参照ください。現在の SLB クォータ使用量を確認するには、「Server Load Balancer クォータ管理」をご参照ください。
負荷分散更新ポリシー
ACK では、SLB インスタンスをサービスに関連付けるために、2 つのアプローチがサポートされています：既存のインスタンスを指定する方法、または CCM が自動的に作成・管理する方法です。両者のリソースライフサイクルは異なります。
リソース |
既存の SLB インスタンスを指定 |
CCM が管理する SLB インスタンス |
Server Load Balancer |
CCM は指定されたインスタンスをロードバランサーとして使用し、他のアノテーションに基づいて構成します。また、vServer グループを自動的に作成します。 サービスが削除された場合、CCM は指定された SLB インスタンスを削除しません。 |
CCM はサービス仕様に基づき、SLB インスタンス、リスナー、および vServer グループを自動的に作成・構成します。 サービスが削除された場合、CCM は自動的に作成された SLB インスタンスを削除します。 |
リスナー |
|
CCM はサービス仕様に基づき、リスナーポリシーを自動的に作成・構成します。 |
バックエンドサーバーグループ |
サービスのエンドポイントまたはクラスターノードが変更された場合、CCM はバックエンドサーバーグループを自動的に更新します。 Terway ネットワークプラグイン：デフォルトでは ECS ノード IP ではなく、Pod IP をバックエンドとして登録します。 Flannel ネットワークプラグイン：バックエンド登録は
Flannel 固有のルール：
|
|
削除保護の有効化
重大なワークロードまたは機密データを処理するサービスについては、削除保護を有効化してください。有効化後は、関連する SLB リソースを削除するには、まず手動で削除保護を無効化する必要があります。これにより、誤った削除およびそれに伴うコスト発生を防止できます。
手順については、「サービスの削除保護を有効化する」をご参照ください。