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

PDF

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

ULB をデプロイする

Updated: October 28, 2026

Want to summarize with AI?

Log in

必要な手順や検証アクションなど、ULB のデプロイ手順を示します。

この手順を使用して、準備、デプロイメント、および構成手順を含む、オンプレミス環境で ULB をデプロイします。

この手順では、イメージの処理、Helm チャートの設定、およびオペレータとエージェントの両方のコンポーネントのログ管理を含む、ULB のエンドツーエンドのデプロイメントについて説明します。

Before you begin

オンプレミス環境で ULB のデプロイメントを開始する前に、次の前提条件が満たされていることを確認します。

  • Kubernetes クラスターがインストールされ、構成されていることを確認します。

  • Linux カーネルバージョンは、5.4.x 以降である必要があります。ULB eBPF ベースの高速パスをサポートするには、すべての参加ノードがLinux カーネルバージョン 6.8.x 以降で実行されていることを確認します。

  • カーネルでパケット転送を有効にします。

    Note

    ULB は、デフォルトで有効になっている eBPF データパスを使用してデプロイされ、lbs-agent Pod が実行されている各ノードで ULB CNI プラグインを自動的にインストールおよび管理するため、個別のインストールや構成は必要ありません。バックエンド アプリケーション Pod が ULB で生成された NAD を参照すると、Multus はプラグインを呼び出して ULB 管理対象 Pod インターフェイスを作成し、構成された設定を適用します。

    Note

    ULB はアクティブ/スタンバイ冗長性モデルを使用しません。対応するスタンバイ ULB ピアを持つ専用のアクティブな ULB インスタンスがありません。

    ULB は、Cilium や Multus に似た、クラスターレベルのネットワーキング製品としてデプロイされます。各 Kubernetes クラスターには、1 つの ULBデプロイメントが必要です。

  • リバースパスフィルタリングを無効にします（つまり、「rp_filter = 0」）。

  • iptables：ユーザースペース ユーティリティ プログラムをインストールする必要があります。

  • Cilium は、SMI/CNDP を使用してインストールされます。

手順

  1. 専用ソース（https://software.cisco.com/）から ULB image tar ファイルをダウンロードします。

    tar ファイルを抽出して、Docker イメージを解凍します。

  2. ULB イメージをの導入準備をして、デプロイします。

    1. Docker イメージをロードし、必要に応じてタグ付けします。
    2. Docker Hub にログインし、イメージをプッシュします。
    3. ULB オペレータとエージェントの Helm チャートがあることを確認します。Docker イメージを使用して、Helm チャートの「values.yaml」ファイルを更新します。
    4. Cluster Deployer から ULB Ops-center を使用して ULB（ULB オペレータとエージェント）をデプロイします。
    5. 要件に従って ULB を構成します。
    6. パケット転送が有効になっていて、リバースパスフィルタリングが無効になっていることを確認します。
    7. ULB オペレータとエージェントのログタグ構成を更新します。

      オペレータに次の構成コマンドを使用します。

      
                                                                                                                                                                                                                
            config
            logging name lbs_operator.app.app level { debug | error | info | off | trace | warn }
            logging name lbs_operator.app.empcrd level { debug | error | info | off | trace | warn }
            logging name lbs_operator.app.lbcrd level { debug | error | info | off | trace | warn }
            logging name lbs_operator.app.service level { debug | error | info | off | trace | warn }
            end

      エージェントに対して次の構成コマンドを使用します。

      
            config
            logging name lbs-agent.egress-mgr.app level { debug | error | info | off | trace | warn }
            logging name lbs-agent.egress-mgr.iptables level { debug | error | info | off | trace | warn }
            logging name lbs-agent.egress-mgr.iptables-oper level { debug | error | info | off | trace | warn }
            logging name lbs-agent.egress-mgr.lbs-iptables level { debug | error | info | off | trace | warn }
            logging name lbs-agent.egress-mgr.egressmgr level { debug | error | info | off | trace | warn }
            logging name lbs-agent.egress-mgr.listener level { debug | error | info | off | trace | warn }
            end

      このログタグ構成により、ログ出力を正確に制御でき、効果的なモニタリング、障害対応、パフォーマンス分析、セキュリティ監査、および運用状況の把握が可能になります。管理者は、さまざまなコンポーネントに対して異なるログレベルを指定することで、具体的なニーズに合わせてロギングを調整し、ロードバランシングサービスのスムーズな動作を保証できます。

  3. 必要に応じて、LoadBalancer とエグレス管理ポリシー CR を定義して適用します。

    Kubernetes のカスタムリソースを含む YAML ファイルのサンプルについては、付録「ロードバランサとエグレス管理ポリシーのカスタムリソース定義の例」を参照してください。