Type=LoadBalancer を指定して Service タイプを LoadBalancer に設定すると、Container Service for Kubernetes (ACK) の Cloud Controller Manager (CCM) コンポーネントが、その Service 用に Server Load Balancer (SLB) インスタンスを作成または設定します。このインスタンスには、クラシックロードバランサー (CLB) または Network Load Balancer (NLB) を使用できます。設定には、インスタンス、リスナー、バックエンドサーバーグループなどのリソースが含まれます。このトピックでは、Service の負荷分散設定に関する考慮事項と、CCM のリソース更新ポリシーについて説明します。
考慮事項
再利用可能な SLB インスタンス
再利用できるのは、Server Load Balancer コンソールで作成されたインスタンスのみです。cloud-controller-manager によって自動的に作成された SLB インスタンスや、API サーバーで使用されるインスタンスなど、ACK が管理する他の SLB インスタンスは再利用できません。
ACK クラスターで非公開 SLB インスタンスを再利用するには、そのインスタンスが ACK クラスターと同じ VPC 内にある必要があります。VPC をまたいだ再利用は、NLB インスタンスにのみ適用されます。
再利用する SLB インスタンスのアドレスタイプは、Service のアクセスタイプと一致している必要があります。Service が パブリックアクセス (アノテーション
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"を使用) に設定されている場合、SLB インスタンスの IP バージョン は インターネット である必要があります。Service が内部アクセス (アノテーションservice.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"を使用) に設定されている場合、SLB インスタンスの IP バージョン は プライベートネットワーク である必要があります。複数の Service で、同じ SLB インスタンスの同じリスナーポートを使用することはできません。
クラスター間で既存の SLB インスタンスを再利用する場合、各クラスターで名前空間と Service 名の組み合わせが一意であることを確認してください。
CCM が管理する SLB インスタンスに関する考慮事項
CCM は、
Type=LoadBalancerの Service に対してのみ負荷分散を設定します。他のタイプの Service に対しては負荷分散を設定しません。CCM は宣言的な API を使用し、特定の条件下で Service の設定に基づいて SLB の設定を自動的に更新します。Server Load Balancer コンソールで変更した設定は、上書きされるリスクがあります。
Service の
service.k8s.alibaba/resourcesまたはservice.k8s.alibaba/nlbファイナライザーを手動で削除または変更しないでください。ファイナライザーを手動で変更すると、CLB または NLB のリソースが正しく回収されなくなる可能性があります。Cloud Controller Manager のバージョンが v2.5.0 以降の場合、コンソールで Service を作成する際に CLB インスタンスを指定するオプションはホワイトリスト機能です。この機能を使用するには、クォータセンタープラットフォームでリクエストを送信する必要があります。
Type=LoadBalancer の Service が LoadBalancer 以外のタイプに変更された場合、CCM は SLB インスタンスに追加された設定を削除します。その結果、Service は SLB インスタンス経由でアクセスできなくなります。
Server Load Balancer コンソールで、ACK によって作成およびメンテナンスされる SLB インスタンスの設定を手動で変更しないでください。変更した場合、設定が失われ、Service にアクセスできなくなる可能性があります。
クラスター内から LoadBalancer Service の外部 IP にアクセスする場合の考慮事項
ネットワークプラグインのタイプ、ネットワークプラグインのバージョン、およびクラスターのバージョンによっては、クラスター内から LoadBalancer Service に関連付けられた SLB の IP アドレスにアクセスすると、クラスターネットワークがノード上のトラフィックをインターセプトし、バックエンドのサービスエンドポイントに直接転送する場合があります。
このプロセスは、外部の SLB インスタンスをバイパスします。これにより、SLB インスタンスに依存する特定の設定が失敗し、アクセスに関する問題が発生する可能性があります。影響を受ける主なシナリオは次のとおりです。
externalTrafficPolicyがLocalに設定されている場合：トラフィックがバックエンド Pod のないノードに転送されるため、アクセスに失敗する可能性があります。Proxy Protocol が有効になっている場合：バックエンドサービスは SLB インスタンスによって追加された Proxy Protocol ヘッダーを取得できず、プロトコルのハンドシェイクに失敗します。
HTTP/HTTPS リスナーを使用している場合：TLS 終端や
X-Forwarded-Forなどの特定のヘッダーの追加など、SLB インスタンスに依存する操作は効果がありません。
したがって、クラスター内から LoadBalancer Service にアクセスするには、次の方法があります。
Service のクラスター内アドレスを使用します。これは、より標準的で安定した方法です。クラスター内のサービス間通信には、Service の ClusterIP またはその DNS 名 (例：
<service-name>.<namespace>.svc.cluster.local) を使用します。SLB のエントリーポイントを使用するには、ホスト名経由でアクセスします。Service に
service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostnameアノテーションを追加し、IP アドレスの代わりに設定されたドメイン名を使用してアクセスします。これにより、トラフィックが正しく処理されるようになります。アノテーションの詳細については、「Service のホスト名を設定する」をご参照ください。重要この機能を使用して SLB インスタンスをバイパスしてアクセスする場合、クライアント Pod とサーバー側の Pod を同じノードにスケジュールしないでください。そうしないと、非対称ルーティングの問題によりアクセスに失敗する可能性があります。
単一クラスター内で CCM を使用した大規模な負荷分散を管理する場合の考慮事項
クラスターが大規模な場合、CCM が Service イベントを処理する能力には制限があります。次のシナリオでは、SLB インスタンスの作成や削除、サーバーグループ内のエンドポイントの更新などの操作が遅延する可能性があります。
多数の LoadBalancer Service が同時に作成または削除される場合。
多くのサービスエンドポイントが同時に更新されます。
多数の LoadBalancer Service が存在する状態で、ノードがバッチで追加または削除される場合。
次の点にご注意ください。
容量評価の実施：大規模な変更を行う前に、容量評価とストレステストを実施してください。遅延によるビジネスの中断を防ぐために、十分な処理マージンを確保してください。
変更中のトラフィックの安定性の確保：
readinessGatesやpreStopフックなどの設定を使用して、ビジネスの変更中にトラフィックが中断されないようにします。詳細については、「ゼロダウンタイムのローリングデプロイを実装する」をご参照ください。クォータ制限の遵守：多数の LoadBalancer Service を使用する場合は、CLB または NLB のクォータ制限に特に注意してください。詳細については、「クォータ制限」をご参照ください。
コンポーネントの最新化：クラスターと 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 個の CLB インスタンスと 60 個の NLB インスタンスを持つことができます。このクォータを増やすには、Quota Centerコンソールにログインしてアプリケーションを送信。CCM は、Service の設定に基づいて、ECS インスタンスまたは Elastic Network Interface (ENI) を SLB インスタンスのバックエンドサーバーグループにアタッチします。また、Service 内の異なる targetPort ごとに個別のサーバーグループを作成します。次のクォータ制限にご注意ください。
バックエンドサーバーの数：デフォルトでは、CLB インスタンスには最大 200 台のバックエンドサーバーを、NLB インスタンスには最大 400 台の ECS、ENI、または IP ベースのバックエンドサーバーをアタッチできます。必要なクォータは次のように計算されます：バックエンドサーバーの数 × targetPort の数。クォータを増やすには、事前にQuota Centerコンソールにログインしてアプリケーションを送信。
インスタンスがサーバーグループにアタッチできる回数：デフォルトでは、同じ ECS インスタンスまたは ENI は、CLB インスタンスの最大 50 の異なるバックエンドサーバーグループ、および NLB インスタンスの最大 200 の異なるバックエンドサーバーグループにアタッチできます。より多くのサーバーグループにアタッチするには、Quota Centerコンソールにログインしてアプリケーションを送信。
ローリングアップデート中の追加クォータ使用量：ローリングアップデート中、古い Pod が削除される前に新しい Pod が作成されます。これにより、追加のクォータが消費されます。実際の消費量は予想を超える可能性があります。事前に十分なクォータを確保してください。
CCM は、Service で定義されたポートに基づいてリスナーを作成します。デフォルトでは、CLB または NLB インスタンスに最大 50 個のリスナーを追加できます。リスナーをさらに追加するには、Quota Centerコンソールにログインしてアプリケーションを送信。
SLB の制限の詳細については、「CLB の制限」および「NLB の制限」をご参照ください。
SLB のクォータをクエリするには、「Server Load Balancer クォータ管理」をご参照ください。
SLB インスタンスの更新ポリシー
ACK では、Service に既存の SLB インスタンスを指定するか、CCM に新しいインスタンスを自動的に作成させることができます。これら 2 つの方法のリソース更新ポリシーは、次の表に示すように異なります。
リソースオブジェクト | 既存の SLB インスタンスを指定 | CCM が管理する SLB インスタンス |
Server Load Balancer | アノテーションを設定：
|
|
リスナー | アノテーションを設定：
| CCM は、Service の設定に基づいてリスナーポリシーを自動的に作成および設定します。 |
バックエンドサーバーグループ | Service に対応するバックエンドのエンドポイントまたはクラスターノードが変更されると、CCM は SLB インスタンスのバックエンド vServer グループを自動的に更新します。
| |
Service の削除保護の有効化
重大なビジネス運用や機密データに関わる Service に対して削除保護を有効にすることで、誤った削除やそれに伴うメンテナンスコストを防ぐことができます。この機能を有効にすると、対応するリソースは、手動で削除保護を無効にした後にのみ削除できます。Service の削除保護を有効にする方法の詳細については、「Service の削除保護の有効化」をご参照ください。