すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:既存のロードバランサーを再利用したクラスター間のサービスデプロイ

    ドキュメントセンター

    Container Service for Kubernetes:既存のロードバランサーを再利用したクラスター間のサービスデプロイ

    最終更新日:Mar 27, 2026

    Cloud Controller Manager (CCM) を使用すると、既存の Server Load Balancer (SLB) インスタンスを、1 つ以上の Container Service for Kubernetes (ACK) クラスター内のサービスや、それらのクラスター外のエンドポイントにアタッチできます。単一の SLB インスタンスを統一されたイングレスとして機能させることで、クラスターごとに個別のロードバランサーをプロビジョニングする必要がなくなり、クラスター間のディザスタリカバリ、高可用性、またはセキュリティ隔離が必要な場合に役立ちます。

    ここでは、2 つのシナリオについて説明します。

    • シナリオ 1：クラスター内のサービスと外部エンドポイント (例：Elastic Compute Service (ECS) インスタンス) との間でトラフィックを分散します。

    • シナリオ 2：異なる ACK クラスターのサービス間でトラフィックを分散します。

    前提条件

    開始する前に、以下をご確認ください。

    シナリオ 1：クラスターサービスと外部エンドポイントへのトラフィック分散

    クラスター内のサービスと外部エンドポイントを同じ SLB インスタンスにアタッチします。SLB インスタンスは両方にトラフィックをルーティングします。Pod がスケールすると、外部エンドポイントに影響を与えることなく、vServer グループに自動的に追加または削除されます。

    image

    ステップ 1：SLB インスタンス ID の取得

    CLB コンソールまたはNLB コンソールにログインし、既存の SLB インスタンスの ID を書き留めます。

    ステップ 2：既存の SLB インスタンスを使用したサービスの作成

    ACK コンソールの使用

    ACK コンソールで、以下の設定でサービスを作成します。

    • [サービスタイプ] を [SLB] に設定します。

    • [既存リソースの使用] を選択し、ドロップダウンリストから SLB インスタンスを選択します。

    • [既存リスナーの上書き] を選択します。

    kubectl の使用

    サービスのマニフェストに、次のアノテーションを追加します。

    apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "<YOUR_LB_ID>"            # 共有 SLB インスタンスの ID。
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vgroup-port: "<YOUR_VGROUP_ID>:<PORT>"  # vServer グループ ID とサービスのポート（コロンで区切る）。
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "100"                # （オプション）このサービスのバックエンド Pod のトラフィックの重み。有効な値：1～1000。デフォルト値：100。
  labels:
    #...
  name: #...
spec:
  #...
    重要

    サービスが作成されると、CCM は SLB インスタンスに対して、サービスポートでリッスンするリスナーと vServer グループを作成します。

    ステップ 3：vServer グループへの外部エンドポイントの追加

    CLB コンソールまたはNLB コンソールにログインし、ご利用の外部エンドポイント (例：ECS インスタンス) を CCM が作成した vServer グループに追加します。手順については、「CLB vServer グループの作成と管理」および「vServer グループの作成と管理」をご参照ください。

    外部エンドポイントを追加すると、クラスターの Pod と外部エンドポイントの両方が vServer グループに表示され、それぞれの相対的な重みを設定できます。

    シナリオ 2：異なる ACK クラスターのサービス間でのトラフィック分散

    異なる ACK クラスターのサービスを同じ SLB インスタンスにアタッチします。各クラスターの CCM は、他のクラスターによって登録されたバックエンドサーバーに影響を与えることなく、Pod のスケールに応じて vServer グループを同期させます。

    image

    制限事項

    開始する前に、以下の制約をご確認ください。

    • SLB インスタンスを共有するすべてのサービスは、同じポートを使用する必要があります。

    • クラスター間で同じ名前空間にデプロイされるサービスは、異なる名前を持つ必要があります。

    • alibaba-cloud-loadbalancer-weight アノテーションを使用してトラフィックの重みを設定する場合、重みの管理はアノテーションのみで行ってください。コンソールでの変更はサービスに同期されないため、SLB コンソールで重みを変更しないでください。

    ステップ 1：リスナーと vServer グループの手動作成

    CLB コンソールまたはNLB コンソールにログインし、SLB インスタンスのリスナーと vServer グループを手動で作成します。手順については、「CLB リスナー」、「CLB vServer グループの作成と管理」、「NLB リスナー」、および「サーバーグループの作成と管理」をご参照ください。

    すべてのクラスターが同じグループを共有できるように、リスナーと vServer グループを手動で作成する必要があります。各クラスターの CCM は、自身の Pod をこの共有グループに登録します。

    ステップ 2：共有 vServer グループのアノテーションを使用したサービスの作成

    各クラスターで、以下のアノテーションを使用してサービスを作成します。すべてのサービスは、同じ SLB インスタンスと vServer グループを参照する必要があります。

    apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "<YOUR_LB_ID>"            # 共有 SLB インスタンスの ID。
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vgroup-port: "<YOUR_VGROUP_ID>:<PORT>"  # vServer グループ ID とサービスポートをコロンで区切ります。
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-weight: "100"                # (オプション) このサービスのバックエンド Pod のトラフィックの重み。有効値：1～1000。デフォルト値：100。
  labels:
    #...
  name: #...
spec:
  #...

    アノテーションリファレンス

    アノテーション タイプ デフォルト値 説明
    alibaba-cloud-loadbalancer-id 文字列 — 既存の SLB インスタンスの ID。CCM は新しいインスタンスを作成する代わりに、このインスタンスにサービスをアタッチします。
    alibaba-cloud-loadbalancer-vgroup-port 文字列 — サービスポートを vServer グループにマッピングします：<vgroup-id>:<port>。複数のポートと vServer グループのマッピングを行う場合は、カンマで区切ります。例："<VGROUP_ID_1>:80, <VGROUP_ID_2>:443"。
    alibaba-cloud-loadbalancer-weight integer 100 このサービスのすべてのバックエンド Pod のトラフィックの重み。有効値：1～1000。設定すると、CCM はこの値を使用して vServer グループに Pod の重みを登録します。重みの管理は SLB コンソールではなく、このアノテーションのみで行ってください。

    サービスマニフェストを適用すると、各クラスターの Pod がSLB コンソールの共有 vServer グループに表示されます。アプリケーションがスケールすると、その Pod は他のサービスに属する Pod に影響を与えることなく、グループに自動的に追加または削除されます。

    次のステップ

    参考資料