Unified Load Balancer 構成およびアドミニストレーション ガイド、リリース 2026.02

PDF

Unified Load Balancer 構成およびアドミニストレーション ガイド、リリース 2026.02

ULB で SCTP ロードバランシングをサポートする

Want to summarize with AI?

Log in

ULB での SCTP ロードバランシングのサポートについて詳述し、主要なパラメータ、要件、および参照情報についてまとめます。SCTP サービス配布の管理について説明します。


ULB は、ダイレクトサービス経由で SCTP ロードバランシングを提供します。すべての SCTP LoadBalancer カスタムリソースは、プロトコル:SCTP および ulbDirectServiceEnabled:true に設定する必要があります。ULB は、SCTP INIT パケットを処理する際に、アソシエーションに適したバックエンド アプリケーション Pod を選択します。後続のパケットでは、同じバックエンドが使用されますが、記録されたアソシエーションの状態は有効なままです。マルチホーム アソシエーションの場合、別の学習済みピアアドレス経由で受信した通信も、同じバックエンドにリダイレクトされます。

SCTP ロード バランシング構成の要件

Table 1. SCTP ロード バランシング構成の要件

エリア

管理者の要件

ノードイングレスの可用性 ULB クラスターポリシーは、構成されたインターフェイスがないか、停止している場合でも有効です。ノードは、[状態:起動(state: up)] と報告している間にのみ、そのインターフェイス経由で ULB サービス通信を受信できます。ULB は、インターフェイスが動作可能になると、自動的にそのインターフェイスの使用を開始します。
バックエンドネットワーク接続 SCTP ダイレクト サービス 通信を受信するための各バックエンド Pod は、生成された NAD を参照する Pod テンプレートから作成する必要があります。これにより、Pod 内に ULB 管理対象インターフェイスとサービスアドレスが作成されます。
プロトコルと機能 LoadBalancer で、プロトコル:SCTP and ulbDirectServiceEnabled:true と設定します。
サービスアドレス LoadBalancer serviceIP と ULB ネットワークポリシーで設定されたものと同じアドレスを使用します。
ポートおよびアプリケーション servicePort と target.port を同じ値に設定します。バックエンド アプリケーションは、構成されたサービスアドレスとポートで SCTP 通信を受け入れる必要があります。
バックエンドの選択 LoadBalancer 名前空間で対象のバックエンド アプリケーション Pod と一致するように、target.selectors.matchLabels を構成します。
インターフェイス MTU 必要に応じて、1280 ~ 9000 の MTU を設定します。デフォルトは 1500 です。

SCTP ロードバランシングに向けた ULB 構成および生成リソース

Figure 1. SCTP ロードバランシングに向けた ULB 構成および生成リソース

SCTP デプロイメントの場合、それぞれのセクションの説明に従い、ULB クラスターポリシーを使用して目的のノードインターフェイスを構成し、ULBネットポリシーを使用してサービスアドレスを構成します。

ULB は、コミットされた構成を処理し、対応する Kubernetes リソースを自動的に作成または更新します。管理者は、これらのリソースを手動で作成しません。

ULB クラスターポリシーには、ULB が着信サービス通信を処理するノードインターフェイスが含まれます。ULB ネットワークポリシーには、ダイレクトサービス IP アドレスと、必要に応じてインターフェイス MTU が含まれています。ULB ネットワークポリシーの場合、ULB は、ポリシーと同じ名前空間にポリシーと同じ名前で Multus NetworkAttachmentDefinition も作成します。Backend application pod テンプレートは、k8s.v1.cni.cncf.io/networks Pod 注釈によってこの名前を参照します。Multus が Pod ネットワークを作成すると、構成された各サービスアドレスが Pod 内の個別の ULB 管理対象インターフェイスに割り当てられます。

生成されたリソースを確認するには、次を使用します。

kubectl get ulbclusterpolicy global-ulb-cluster-policy
kubectl get ulbnetworkpolicy -n <application-namespace> <network-policy-name>
kubectl get network-attachment-definitions -n <application-namespace> <network-policy-name>

SCTP ダイレクトサービスのロードバランサを構成する

次の例では、デュアルスタック SCTP LoadBalancer を作成します。ULB ネットワークポリシー、生成された NAD、バックエンド アプリケーション Pod の注釈、およびバックエンド アプリケーション Pod の準備ができた後に適用します。

手順

SCTP ダイレクトサービスのロードバランサを構成する
apiVersion: lbs.cisco.com/v1alpha1
kind: LoadBalancer
metadata:
  labels:
    app: <sample-application>
    component: <sample-component>
    release: <sample-release>
  name: <loadbalancer-name>
  namespace: <application-namespace>
spec:
  protocol: SCTP
  serviceIPs:
    - <ipv6-address>
    - <ipv6-address>
    - <ipv4-address>
    - <ipv4-address>
  servicePort: 9002
  target:
    port: 9002
    selectors:
      matchLabels:
        <label-Key1>: <label-Value1>
        <label-Key2>: <label-Value2>
        <label-Key3>: <label-Value3>

  ulbDirectServiceEnabled: true

SCTP サービス配布を管理する

ULB Ops Center service-distribution コマンドを使用して、SCTP アソシエーションを調査するか、意図的にリセットします。コマンドは、ダイレクトサービスが有効になっている SCTP LoadBalancer にのみ適用されます。

Figure 2. SCTP service-distribution 運用コマンドフロー
Table 2. SCTP service-distribution 運用コマンドフロー

動作

動作と使用

count 読み取り専用。SCTP アソシエーションの配置を報告し、アクティブな配信と不整合なアソシエーションを識別します。
rebalance 不整合な SCTP アソシエーションのみを切断します。クライアントは再接続し、現在の分散に従って配置されます。
flush LoadBalancer に対してE メール検出可能なすべての SCTP アソシエーションを解除します。計画中断を伴うサービス操作中にのみ使用します。

現在の SCTP アソシエーション分散をカウントします。

loadbalancer service distribution count lbName loadbalancer-name namespace application-namespace

不整合な SCTP アソシエーションのみを切断します。

loadbalancer service distribution rebalance lbName loadbalancer-name namespace application-namespace

検出可能なすべての SCTP アソシエーションを解除します。

loadbalancer service distribution flush lbName loadbalancer-name namespace application-namespace

Note

再調整とフラッシュはすぐに有効になります。最初に count を実行し、LoadBalancer の名前と名前空間を確認してから、中断を伴う操作としてフラッシュをスケジュールします。

lbs-operator Pod は、実行中の lbs-agent Pod からの結果を集約し、1 つの結合テーブルを ULB Ops Center CLI に返します。正常な ULB エージェント Pod の行は表示されたままになり、失敗したエージェント Pod のステータスは、顧客が判読できる理由とともに [エラー] の下に表示されます。