Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.4. MetalLB Operator

5.4.1. MetalLB および MetalLB Operator について
リンクのコピー

クラスター管理者は、MetalLB Operator をクラスターに追加し、タイプ LoadBalancer のサービスがクラスターに追加されると、MetalLB はサービスの外部 IP アドレスを追加できます。外部 IP アドレスがクラスターのホストネットワークに追加されます。

5.4.1.1. MetalLB を使用するタイミング
リンクのコピー

MetalLB の使用は、ベアメタルクラスター、またはベアメタルのようなインフラストラクチャーがある場合や、外部 IP アドレスを使用したアプリケーションへのフォールトトレラントがあるアクセスが必要な場合に役立ちます。

ネットワークインフラストラクチャーを設定し、外部 IP アドレスのネットワークトラフィックがクライアントからクラスターのホストネットワークにルーティングされるようにする必要があります。

MetalLB Operator を使用して MetalLB をデプロイした後、タイプ LoadBalancer のサービスを追加すると、MetalLB はプラットフォームネイティブなロードバランサーを提供します。

外部トラフィックが MetalLB LoadBalancer サービスを通じて OpenShift Container Platform クラスターに入ると、クライアントへの戻りトラフィックに、ロードバランサーの外部 IP アドレスがソース IP として含まれます。

レイヤ 2 モードで動作する MetalLB は、IP フェイルオーバーと同様のメカニズムを利用してフェイルオーバーをサポートします。ただし、仮想ルーター冗長プロトコル (VRRP) とキープアライブに依存する代わりに、MetalLB はゴシップベースのプロトコルを利用してノード障害のインスタンスを識別します。フェイルオーバーが検出されると、別のノードがリーダーノードのロールを引き継ぎ、Gratuitous ARP メッセージがディスパッチされて、この変更がブロードキャストされます。

レイヤ 3 またはボーダーゲートウェイプロトコル (BGP) モードで動作する MetalLB は、障害検出をネットワークに委任します。OpenShift Container Platform ノードが接続を確立した BGP ルーターは、ノードの障害を識別し、そのノードへのルートを終了します。

Pod とサービスの高可用性を確保するには、IP フェイルオーバーの代わりに MetalLB を使用することを推奨します。

5.4.1.2. MetalLB Operator カスタムリソース
リンクのコピー

MetalLB Operator は、次のカスタムリソースについて独自の namespace を監視します。

MetalLB
MetalLB カスタムリソースをクラスターに追加する際に、MetalLB Operator は MetalLB をクラスターにデプロイします。Operator はカスタムリソースの単一インスタンスのみをサポートします。インスタンスが削除されると、Operator はクラスターから MetalLB を削除します。
IPAddressPool

MetalLB には、タイプ LoadBalancer のサービスを追加する際にサービスに割り当てることができる IP アドレスの 1 つ以上のプールが必要です。IPAddressPool には、IP アドレスのリストが含まれています。リストは、1.1.1.1-1.1.1.1 などの範囲を使用して設定された単一の IP アドレス、CIDR 表記で指定された範囲、ハイフンで区切られた開始アドレスと終了アドレスとして指定された範囲、またはこの 3 つの組み合わせにすることができます。IPAddressPool には名前が必要です。ドキュメントは、doc-example、doc-example-reserved、doc-example-ipv6 などの名前を使用します。MetalLB controller は、IPAddressPool 内のアドレスのプールから IP アドレスを割り当てます。L2Advertisement および BGPAdvertisement カスタムリソースは、指定されたプールからの指定された IP のアドバタイズメントを有効にします。IPAddressPool カスタムリソースの IPAddressPool 仕様を使用して、spec.serviceAllocation からサービスと namespace に IP アドレスを割り当てることができます。

注記

単一の IPAddressPool は、L2 アドバタイズメントと BGP アドバタイズメントによって参照できます。

BGPPeer
BGP ピアカスタムリソースは、通信する MetalLB の BGP ルーター、ルーターの AS 番号、MetalLB の AS 番号、およびルートアドバタイズメントのカスタマイズを識別します。MetalLB は、サービスロードバランサーの IP アドレスのルートを 1 つ以上の BGP ピアにアドバタイズします。
BFDProfile
BFD プロファイルカスタムリソースは、BGP ピアの双方向フォワーディング検出 (BFD) を設定します。BFD は、BGP のみよりも、パスの障害検出が高速になります。
L2Advertisement
L2Advertisement カスタムリソースは、L2 プロトコルを使用して IPAddressPool からの IP をアドバタイズします。
BGPAdvertisement
BGPAdvertisement カスタムリソースは、BGP プロトコルを使用して IPAddressPool からの IP をアドバタイズします。

MetalLB カスタムリソースをクラスターに追加し、Operator が MetalLB をデプロイすると、controller および speaker MetalLB ソフトウェアコンポーネントは実行を開始します。

MetalLB は、関連するすべてのカスタムリソースを検証します。

5.4.1.3. MetalLB ソフトウェアコンポーネント
リンクのコピー

MetalLB Operator のインストール時に、metallb-operator-controller-manager デプロイメントは Pod を起動します。Pod は Operator の実装です。Pod は、関連するすべてのリソースへの変更を監視します。

Operator が MetalLB のインスタンスを起動すると、controller デプロイメントと speaker のデーモンセットが開始します。

注記

MetalLB カスタムリソースでデプロイメント仕様を設定して、controller および speaker Pod がクラスターへのデプロイおよび実行方法を管理できます。これらの展開仕様の詳細は、関連情報 セクションを参照してください。

controller

Operator はデプロイメントおよび単一の Pod を起動します。LoadBalancer タイプのサービスを追加する場合、Kubernetes は controller を使用してアドレスプールから IP アドレスを割り当てます。サービスに障害が発生した場合は、controller Pod のログに次のエントリーがあることを確認します。

出力例

"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
Copy to Clipboard Toggle word wrap

speaker

Operator は、speaker Pod 用に設定されたデーモンを起動します。デフォルトでは、Pod はクラスター内の各ノードで起動されます。MetalLB の起動時に MetalLB カスタムリソースでノードセレクターを指定して、Pod を特定のノードに制限できます。controller がサービスに IP アドレスを割り当てても、サービスがまだ利用できない場合は、speaker Pod のログを確認してください。スピーカー Pod が使用できない場合は、oc describe pod -n コマンドを実行します。

レイヤー 2 モードの場合には、controller がサービスに IP アドレスを割り当てた後に、speaker Pod はアルゴリズムを使用して、どのノードの、どの speaker Pod がロードバランサーの IP アドレスをアナウンスするかを決定します。このアルゴリズムには、ノード名とロードバランサーの IP アドレスのハッシュが含まれます。詳細は、「MetalLB と外部トラフィックポリシー」を参照してください。speaker は、Address Resolution Protocol (ARP) を使用して IPv4 アドレスと Neighbor Discovery Protocol (NDP) を公開して、IPv6 アドレスにアナウンスします。

Border Gateway Protocol (BGP) モードの場合、コントローラー がサービスに IP アドレスを割り当てた後に、各 speaker Pod はロードバランサーの IP アドレスを BGP ピアにアドバタイズします。どのノードが BGP ピアとの BGP セッションを開始するかを設定できます。

ロードバランサーの IP アドレスの要求は、IP アドレスを通知する speaker でノードにルーティングされます。ノードがパケットを受信した後に、サービスプロキシーはパケットをサービスのエンドポイントにルーティングします。エンドポイントは、最適なケースでは同じノードに配置することも、別のノードに配置することもできます。サービスプロキシーは、接続が確立されるたびにエンドポイントを選択します。

5.4.1.4. MetalLB と外部トラフィックポリシー
リンクのコピー

レイヤー 2 モードでは、クラスター内のノードはサービス IP アドレスのすべてのトラフィックを受信します。BGP モードでは、ホストネットワーク上のルーターが、新しいクライアントが接続を確立できるように、クラスター内のノードの 1 つに接続を開きます。クラスターがノードに入った後にトラフィックを処理する方法は、外部トラフィックポリシーの影響を受けます。

cluster

これは spec.externalTrafficPolicy のデフォルト値です。

cluster トラフィックポリシーでは、ノードがトラフィックを受信した後に、サービスプロキシーはトラフィックをサービスのすべての Pod に分散します。このポリシーは、Pod 全体に均一なトラフィック分散を提供しますが、クライアントの IP アドレスを覆い隠し、トラフィックがクライアントではなくノードから発信されているように Pod 内のアプリケーションに表示される可能性があります。

local

local トラフィックポリシーでは、ノードがトラフィックを受信した後に、サービスプロキシーはトラフィックを同じノードの Pod にのみ送信します。たとえば、ノード A の speaker Pod が外部サービス IP をアナウンスすると、すべてのトラフィックがノード A に送信されます。トラフィックがノード A に入った後、サービスプロキシーはノード A にあるサービスの Pod にのみトラフィックを送信します。追加のノードにあるサービスの Pod は、ノード A からトラフィックを受信しません。追加のノードにあるサービスの Pod は、フェイルオーバーが必要な場合にレプリカとして機能します。

このポリシーは、クライアントの IP アドレスには影響しません。アプリケーション Pod は、受信接続からクライアント IP アドレスを判別できます。

注記

次の情報は、BGP モードで外部トラフィックポリシーを設定する場合に重要です。

MetalLB は、適格なすべてのノードからロードバランサーの IP アドレスをアドバタイズしますが、サービスのロードバランシングを行うノードの数は、等コストマルチパス (ECMP) ルートを確立するルーターの容量によって制限される場合があります。IP をアドバタイズするノードの数がルーターの ECMP グループ制限よりも多い場合、ルーターは IP をアドバタイズするノードよりも少ないノードを使用します。

たとえば、外部トラフィックポリシーが local に設定され、ルーターの ECMP グループ制限が 16 に設定され、LoadBalancer サービスを実装する Pod が 30 ノードにデプロイされている場合、14 ノードにデプロイされた Pod はトラフィックを受信しません。この状況では、サービスの外部トラフィックポリシーを cluster に設定することを推奨します。

5.4.1.5. レイヤー 2 モードの MetalLB の概念
リンクのコピー

レイヤー 2 モードでは、1 つのノードの speaker Pod が、サービスの外部 IP アドレスをホストネットワークに公開します。ネットワークの観点からは、ノードで複数の IP アドレスがネットワークインターフェイスに割り当てられるように見えます。

注記

レイヤ 2 モードでは、MetalLB は ARP と NDP に依存します。これらのプロトコルは、特定のサブネット内でローカルアドレス解決を実装します。このコンテキストでは、MetalLB が機能するために、クライアントは、サービスをアナウンスするノードと同じサブネット上に存在する MetalLB によって割り当てられた VIP に到達できなければなりません。

speaker Pod は、IPv4 サービスの ARP 要求と IPv6 の NDP 要求に応答します。

レイヤー 2 モードでは、サービス IP アドレスのすべてのトラフィックは 1 つのノードを介してルーティングされます。トラフィックがノードに入ると、CNI ネットワークプロバイダーのサービスプロキシーはトラフィックをサービスのすべての Pod に配信します。

サービスのすべてのトラフィックがレイヤー 2 モードで単一のノードを通過するので、より厳密な意味で、MetalLB はレイヤー 2 のロードバランサーを実装しません。むしろ、MetalLB はレイヤー 2 のフェイルオーバーメカニズムを実装しているため、speaker Pod が利用できなくなったときに、別のノードの speaker Pod がサービス IP アドレスをアナウンスできます。

ノードが使用できなくなると、フェイルオーバーが自動的に行われます。他のノードの speaker Pod は、ノードが使用できないことを検出し、障害が発生したノードから、新しい speaker Pod とノードがサービス IP アドレスの所有権を取得します。

MetalLB およびレイヤー 2 モードの概念図
View larger image
MetalLB およびレイヤー 2 モードの概念図

前述のグラフは、MetalLB に関する以下の概念を示しています。

  • アプリケーションは、172.130.0.0/16 サブネットのクラスター IP を持つサービスで利用できます。その IP アドレスはクラスター内からアクセスできます。サービスには、MetalLB がサービス 192.168.100.200 に割り当てられている外部 IP アドレスもあります。
  • ノード 1 および 3 には、アプリケーションの Pod があります。
  • speaker デーモンセットは、各ノードで Pod を実行します。MetalLB Operator はこれらの Pod を起動します。
  • 各 speaker Pod はホストネットワーク化された Pod です。Pod の IP アドレスは、ホストネットワーク上のノードの IP アドレスと同じです。
  • ノード 1 の speaker Pod は ARP を使用して、サービスの外部 IP アドレスに 192.168.100.200 を認識します。外部 IP アドレスをアナウンスする speaker Pod は、サービスのエンドポイントと同じノード上にあり、エンドポイントは Ready 状態である必要があります。

  • クライアントトラフィックはホストネットワークにルーティングされ、192.168.100.200 の IP アドレスに接続します。トラフィックがノードに入ると、サービスプロキシーは、サービスに設定した外部トラフィックポリシーに従って、同じノードまたは別のノードのアプリケーション Pod にトラフィックを送信します。

    • サービスの外部トラフィックポリシーが cluster に設定されている場合、speaker Pod が実行されているノードから 192.168.100.200 ロードバランサーの IP アドレスをアドバタイズするノードが選択されます。そのノードのみがサービスのトラフィックを受信できます。
    • サービスの外部トラフィックポリシーが local に設定されている場合、speaker Pod が実行されているノードと少なくとも 1 つのサービスエンドポイントから 192.168.100.200 ロードバランサーの IP アドレスをアドバタイズするノードが選択されます。そのノードのみがサービスのトラフィックを受信できます。前の図では、ノード 1 または 3 のいずれかが 192.168.100.200 をアドバタイズします。
  • ノード 1 が利用できない場合、外部 IP アドレスは別のノードにフェイルオーバーします。アプリケーション Pod およびサービスエンドポイントのインスタンスを持つ別のノードでは、speaker Pod は外部 IP アドレス 192.168.100.200 になり、新規ノードがクライアントトラフィックを受信します。図では、唯一の候補はノード 3 です。

5.4.1.6. BGP モードの MetalLB の概念
リンクのコピー

BGP モードでは、デフォルトで各 speaker Pod がサービスのロードバランサー IP アドレスを各 BGP ピアにアドバタイズします。オプションの BGP ピアのリストを追加すると、指定されたプールからの IP を指定されたピアセットにアドバタイズすることもできます。BGP ピアは通常、BGP プロトコルを使用するように設定されたネットワークルーターです。ルーターがロードバランサーの IP アドレスのトラフィックを受信すると、ルーターは IP アドレスをアドバタイズした speaker Pod が含まれるノードの 1 つを選択します。ルーターはトラフィックをそのノードに送信します。トラフィックがノードに入ると、CNI ネットワークプラグインのサービスプロキシーはトラフィックをサービスのすべての Pod に配信します。

クラスターノードと同じレイヤー 2 のネットワークセグメントに直接接続されたルーターは、BGP ピアとして設定できます。直接接続されたルーターが BGP ピアとして設定されていない場合は、ロードバランサーの IP アドレスのパケットが BGP ピアと speaker Pod を実行するクラスターノードの間でルーティングされるようにネットワークを設定する必要があります。

ルーターは、ロードバランサーの IP アドレスの新しいトラフィックを受信するたびに、ノードへの新しい接続を作成します。各ルーターのメーカーには、接続開始ノードを選択する実装固有のアルゴリズムがあります。ただし、アルゴリズムは通常、ネットワーク負荷のバランスをとるために、使用可能なノード間でトラフィックを分散するように設計されています。

ノードが使用できなくなった場合に、ルーターは、ロードバランサーの IP アドレスをアドバタイズする speaker Pod が含まれる別のノードとの新しい接続を開始します。

図5.1 BGP モードの MetalLB トポロジーの図

ホストネットワーク 10.0.1.0/24 の speaker Pod は、BGP を使用して、ロードバランサーの IP アドレス 203.0.113.200 をルーターにアドバタイズします。
View larger image
ホストネットワーク 10.0.1.0/24 の speaker Pod は、BGP を使用して、ロードバランサーの IP アドレス 203.0.113.200 をルーターにアドバタイズします。

前述のグラフは、MetalLB に関する以下の概念を示しています。

  • アプリケーションは、172.130.0.0/16 サブネットの IPv4 クラスター IP を持つサービスで利用できます。その IP アドレスはクラスター内からアクセスできます。サービスには、MetalLB がサービス 203.0.113.200 に割り当てられている外部 IP アドレスもあります。
  • ノード 2 および 3 には、アプリケーションの Pod があります。
  • speaker デーモンセットは、各ノードで Pod を実行します。MetalLB Operator はこれらの Pod を起動します。MetalLB を設定して、speaker Pod を実行するノードを指定できます。
  • 各 speaker Pod はホストネットワーク化された Pod です。Pod の IP アドレスは、ホストネットワーク上のノードの IP アドレスと同じです。
  • 各 speaker Pod は、すべての BGP ピアとの BGP セッションを開始し、ロードバランサーの IP アドレスまたは集約されたルートを BGP ピアにアドバタイズします。speaker Pod は、Autonomous System 65010 の一部であることをアドバタイズします。この図ではルーター R1 を示しており、これは同じ Autonomous System 内の BGP ピアです。ただし、他の Autonomous System に属するピアとの BGP セッションを開始するように MetalLB を設定できます。

  • ノードに、ロードバランサーの IP アドレスをアドバタイズする speaker Pod がある場合にはすべて、サービスのトラフィックを受信できます。

    • サービスの外部トラフィックポリシーが cluster に設定されている場合、スピーカー Pod が実行されているすべてのノードが 203.0.113.200 ロードバランサーの IP アドレスをアドバタイズし、speaker Pod を持つすべてのノードがサービスのトラフィックを受信できます。ホストの接頭辞は、外部トラフィックポリシーが cluster に設定されている場合にのみ、ルーターピアにアドバタイズされます。
    • サービスの外部トラフィックポリシーが local に設定されている場合、speaker Pod が実行されているノードとサービスが実行されている少なくとも 1 つのエンドポイントが、203.0.113.200 ロードバランサーの IP アドレスをアドバタイズできます。これらのノードのみがサービスのトラフィックを受信できます。前の図では、ノード 2 と 3 は 203.0.113.200 をアドバタイズします。
  • BGP ピアカスタムリソースの追加時にノードセレクターを指定して、特定の BGP ピアとの BGP セッションを開始する speaker Pod を制御するように MetalLB を設定できます。
  • BGP を使用するように設定されている R1 などのルーターは、BGP ピアとして設定できます。
  • クライアントトラフィックは、ホストネットワーク上のノードの 1 つにルーティングされます。トラフィックがノードに入ると、サービスプロキシーは、サービスに設定した外部トラフィックポリシーに従って、同じノードまたは別のノードのアプリケーション Pod にトラフィックを送信します。
  • ノードが使用できなくなった場合に、ルーターは障害を検出し、別のノードとの新しい接続を開始します。BGP ピアに双方向フォワーディング検出 (BFD) プロファイルを使用するように MetalLB を設定できます。BFD は、リンク障害検出がより高速であるため、ルーターは BFD がない場合よりも早く新しい接続を開始できます。

5.4.1.7. 制限および制限
リンクのコピー

5.4.1.7.1. MetalLB のインフラストラクチャーに関する考慮事項
リンクのコピー

MetalLB は、ネイティブのロードバランサー機能が含まれていないため、主にオンプレミスのベアメタルインストールに役立ちます。ベアメタルのインストールに加え、一部のインフラストラクチャーに OpenShift Container Platform をインストールする場合は、ネイティブのロードバランサー機能が含まれていない場合があります。たとえば、以下のインフラストラクチャーは MetalLB Operator を追加するのに役立ちます。

  • ベアメタル
  • VMware vSphere
  • IBM Z® および IBM® LinuxONE
  • IBM Z® および IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM
  • IBM Power®

MetalLB Operator および MetalLB は、OpenShift SDN および OVN-Kubernetes ネットワークプロバイダーでサポートされます。

5.4.1.7.2. レイヤー 2 モードの制限
リンクのコピー
5.4.1.7.2.1. 単一ノードのボトルネック
リンクのコピー

MetalLB は、1 つのノードを介してサービス内のすべてのトラフィックをルーティングします。この際、ノードはボトルネックとなり、パフォーマンスを制限する可能性があります。

レイヤー 2 モードは、サービスの Ingress 帯域幅を単一ノードの帯域幅に制限します。これは、ARP および NDP を使用してトラフィックを転送するための基本的な制限です。

5.4.1.7.2.2. フェイルオーバーのパフォーマンスの低下
リンクのコピー

ノード間のフェイルオーバーは、クライアントからの操作によって異なります。フェイルオーバーが発生すると、MetalLB は Gratuitous ARP パケットを送信して、サービス IP に関連付けられた MAC アドレスが変更されたことをクライアントに通知します。

ほとんどのクライアントオペレーティングシステムは、Gratuitous ARP パケットを正しく処理し、隣接キャッシュを迅速に更新します。クライアントがキャッシュを迅速に更新すると、フェイルオーバーは数秒以内に完了します。通常、クライアントは新しいノードに 10 秒以内にフェイルオーバーします。しかし、一部のクライアントオペレーティングシステムは Gratuitous ARP パケットをまったく処理しないか、キャッシュの更新を遅延させる古い実装があります。

Windows、macOS、Linux などの一般的なオペレーティングシステムの新しいバージョンは、レイヤー 2 フェイルオーバーを正しく実装します。フェイルオーバーが遅いという問題は、古くてあまり一般的ではないクライアントオペレーティングシステムを除いて、予期されていません。

古いクライアントで予定されているフェイルオーバーの影響を最小限にするには、リーダーシップをフラップした後に、古いノードを数分にわたって実行したままにします。古いノードは、キャッシュが更新されるまで、古いクライアントのトラフィックを転送することができます。

予定外のフェイルオーバー時に、古いクライアントがキャッシュエントリーを更新するまでサービス IP に到達できません。

5.4.1.7.2.3. 追加ネットワークと MetalLB は同じネットワークを使用できない
リンクのコピー

MetalLB とソース Pod 上に設定された追加のネットワークインターフェイスの両方に同じ VLAN を使用すると、接続エラーが発生する可能性があります。これは、MetalLB IP とソース Pod が同じノード上に存在する場合に発生します。

接続エラーを回避するには、ソース Pod が存在するサブネットとは異なるサブネットに MetalLB IP を配置します。この設定により、ソース Pod からのトラフィックがデフォルトゲートウェイを経由するようになります。その結果、トラフィックは OVN オーバーレイネットワークを使用して宛先に到達でき、接続が確実に意図したとおりに機能するようになります。

5.4.1.7.3. BGP モードの制限
リンクのコピー

MetalLB には、BGP ベースのロードバランシングに共通する制限があります。ノードに障害が発生した場合や speaker Pod が再起動した場合など、BGP セッションが中断されると、すべてのアクティブな接続がリセットされる可能性があります。エンドユーザーに、Connection reset by peer のメッセージが表示される可能性があります。

BGP セッションが中断された場合にどうなるかは、各ルーターの製造元の実装によります。ただし、speaker Pod の数を変更すると、BGP セッションの数に影響し、BGP ピアとのアクティブな接続が切断されることが予想されます。

サービスの中断の可能性を回避または低減するために、BGP ピアの追加時にノードセレクターを指定できます。BGP セッションを開始するノードの数を制限すると、BGP セッションのないノードでの障害が発生しても、サービスへの接続に影響はありません。

5.4.1.7.3.2. 単一の ASN とルーター ID のみのサポート
リンクのコピー

BGP ピアカスタムリソースを追加するときは、spec.myASN フィールドを指定して、MetalLB が属する AS 番号 (ASN) を特定します。OpenShift Container Platform は、MetalLB を使用した BGP の実装を使用しますが、この実装は MetalLB が単一の ASN に所属する必要があります。BGP ピアを追加し、spec.myASN に既存の BGP ピアカスタムリソースとは異なる値を指定しようとするとエラーが発生します。

同様に、BGP ピアカスタムリソースを追加する場合には、spec.routerID フィールドはオプションです。このフィールドに値を指定する場合は、追加する他の BGP ピアカスタムリソースすべてに、同じ値を指定する必要があります。

単一の ASN と単一のルーター ID のサポートに制限がある点が、コミュニティーがサポートする MetalLB の実装との違いです。

5.4.2. MetalLB Operator のインストール
リンクのコピー

クラスター管理者は、MetalLB Operator を追加して、クラスター上の MetalLB インスタンスのライフサイクルを Operator によって管理できます。

MetalLB および IP フェイルオーバーは互換性がありません。クラスターの IP フェイルオーバーを設定している場合、Operator をインストールする前に IP フェイルオーバーを削除する 手順を実行します。

5.4.2.1. Web コンソールを使用した OperatorHub からの MetalLB Operator のインストール
リンクのコピー

クラスター管理者は、OpenShift Container Platform Web コンソールを使用して MetalLB Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、Operators OperatorHub ページに移動します。

  2. キーワードを Filter by keyword ボックスに入力するか、目的の Operator までスクロールします。たとえば、metallb と入力して MetalLB Operator を見つけます。

    また、インフラストラクチャー機能 でオプションをフィルターすることもできます。たとえば、非接続環境 (ネットワークが制限された環境ともしても知られる) で機能する Operator を表示するには、Disconnected を選択します。

  3. Install Operator ページで、デフォルトを受け入れて Install をクリックします。

検証

  1. インストールが正常に行われたことを確認するには、以下を実行します。

    1. Operators Installed Operators ページに移動します。
    2. Operator が openshift-operators の namespace 内に設置されていることと、その状態が Succeeded となっていることを確認してください。

  2. Operator が正常にインストールされない場合は、Operator のステータスを確認し、ログを確認してください。

    1. Operators Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
    2. Workloads Pods ページにナビゲートし、問題を報告している openshift-operators プロジェクトの Pod のログを確認します。

5.4.2.2. CLI を使用した OperatorHub からのインストール
リンクのコピー

OpenShift Container Platform Web コンソールを使用する代わりに、CLI を使用して OperatorHub から Operator をインストールできます。OpenShift CLI (oc) を使用して、MetalLB Operator をインストールできます。

CLI を使用する場合は、metallb-system namespace に Operator をインストールすることを推奨します。

前提条件

  • ベアメタルハードウェアにインストールされたクラスター。
  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. 次のコマンドを入力して、MetalLB Operator の namespace を作成します。 

    $ cat << EOF | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-system
EOF
    Copy to Clipboard Toggle word wrap

  2. namespace に Operator グループのカスタムリソースを作成します。 

    $ cat << EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system
EOF
    Copy to Clipboard Toggle word wrap

  3. Operator グループが namespace にインストールされていることを確認します。 

    $ oc get operatorgroup -n metallb-system
    Copy to Clipboard Toggle word wrap

    出力例

    NAME               AGE
metallb-operator   14m
    Copy to Clipboard Toggle word wrap

  4. Subscription CR を作成します。

    1. Subscription CR を定義し、YAML ファイルを保存します (例: metallb-sub.yaml)。 

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator-sub
  namespace: metallb-system
spec:
  channel: stable
  name: metallb-operator
  source: redhat-operators
      1 
      
  sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
      1
      redhat-operators 値を指定する必要があります。

    2. Subscription CR を作成するには、次のコマンドを実行します。 

      $ oc create -f metallb-sub.yaml
      Copy to Clipboard Toggle word wrap

  5. オプション: BGP および BFD メトリックが Prometheus に表示されるようにするには、次のコマンドのように namespace にラベルを付けることができます。 

    $ oc label ns metallb-system "openshift.io/cluster-monitoring=true"
    Copy to Clipboard Toggle word wrap

検証

検証手順は、MetallB Operator が metallb-system namespace にインストールされていることを前提としています。

  1. インストール計画が namespace にあることを確認します。 

    $ oc get installplan -n metallb-system
    Copy to Clipboard Toggle word wrap

    出力例

    NAME            CSV                                   APPROVAL    APPROVED
install-wzg94   metallb-operator.4.16.0-nnnnnnnnnnnn   Automatic   true
    Copy to Clipboard Toggle word wrap

    注記

    Operator のインストールには数秒かかる場合があります。

  2. Operator がインストールされていることを確認するには、以下のコマンドを入力します。 

    $ oc get clusterserviceversion -n metallb-system \
  -o custom-columns=Name:.metadata.name,Phase:.status.phase
    Copy to Clipboard Toggle word wrap

    出力例

    Name                                  Phase
metallb-operator.4.16.0-nnnnnnnnnnnn   Succeeded
    Copy to Clipboard Toggle word wrap

5.4.2.3. クラスターでの MetalLB の起動
リンクのコピー

Operator のインストール後に、MetalLB カスタムリソースの単一のインスタンスを設定する必要があります。カスタムリソースの設定後、Operator はクラスターで MetalLB を起動します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • MetalLB Operator がインストールされている。

手順

この手順は、MetallB Operator が metallb-system namespace にインストールされていることを前提としています。Web コンソールを使用してインストールした場合は、namespace の代わりに openshift-operators を使用してください。

  1. MetalLB カスタムリソースの単一のインスタンスを作成します。 

    $ cat << EOF | oc apply -f -
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
EOF
    Copy to Clipboard Toggle word wrap

検証

MetalLB コントローラーのデプロイメントと、MetalLB スピーカーのデーモンセットが実行していることを確認します。

  1. コントローラーのデプロイメントが稼働していることを検証します。 

    $ oc get deployment -n metallb-system controller
    Copy to Clipboard Toggle word wrap

    出力例

    NAME         READY   UP-TO-DATE   AVAILABLE   AGE
controller   1/1     1            1           11m
    Copy to Clipboard Toggle word wrap

  2. スピーカーに設定されているデーモンが実行されていることを検証します。 

    $ oc get daemonset -n metallb-system speaker
    Copy to Clipboard Toggle word wrap

    出力例

    NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
speaker   6         6         6       6            6           kubernetes.io/os=linux   18m
    Copy to Clipboard Toggle word wrap

    この出力例は、6 つの speaker Pod を示しています。クラスターの speaker Pod の数は出力例とは異なる場合があります。出力で各ノードの 1 つの Pod が表示されることを確認します。

5.4.2.4. MetalLB のデプロイメント仕様
リンクのコピー

MetalLB カスタムリソースを使用して MetalLB のインスタンスを起動すると、MetalLB カスタムリソースでデプロイメント仕様を設定して、controller または speaker Pod がクラスターにデプロイし、実行する方法を管理できます。これらのデプロイメント仕様を使用して、以下のタスクを管理します。

  • MetalLB Pod デプロイメントのノードの選択
  • Pod の優先順位および Pod のアフィニティーを使用したケジューリングの管理
  • MetalLB Pod の CPU 制限の割り当て
  • MetalLB Pod のコンテナー RuntimeClass の割り当て
  • MetalLB Pod のメタデータの割り当て
5.4.2.4.1. speaker Pod の特定のノードへの限定
リンクのコピー

デフォルトでは、MetalLB Operator を使用して MetalLB を開始すると、Operator はクラスター内の各ノードで speaker Pod のインスタンスを開始します。ロードバランサーの IP アドレスをアドバタイズできるのは、speaker Pod を備えたノードのみです。ノードセレクターを使用して MetalLB カスタムリソースを設定し、speaker Pod を実行するノードを指定できます。

speaker Pod を特定のノードに制限する最も一般的な理由として、特定のネットワークにネットワークインターフェイスがあるノードのみがロードバランサーの IP アドレスをアドバタイズするようにすることが挙げられます。ロードバランサーの IP アドレスの宛先として、speaker Pod が実行されているノードのみがアドバタイズされます。

speaker Pod を特定のノードに制限し、サービスの外部トラフィックポリシーに local を指定する場合は、サービスのアプリケーション Pod が同じノードにデプロイされていることを確認する必要があります。

speaker Pod をワーカーノードに制限する設定例

apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:
1 

    node-role.kubernetes.io/worker: ""
  speakerTolerations:
2 

  - key: "Example"
    operator: "Exists"
    effect: "NoExecute"
Copy to Clipboard Toggle word wrap

1
この設定例では、speaker Pod をワーカーノードに割り当てるように指定していますが、ノードまたは任意の有効なノードセレクターに割り当てたラベルを指定できます。
2
この設定例では、operator を使用して toleration が割り当てらた Pod で key と effect の値と合致する taint が許容されます。

spec.nodeSelector フィールドを使用してマニフェストを適用した後に、oc get daemonset -n metallb-systemspeaker コマンドを使用して Operator がデプロイした Pod の数を確認できます。同様に、oc get nodes -l node-role.kubernetes.io/worker= のようなコマンドを使用して、ラベルに一致するノードを表示できます。

オプションで、アフィニティールールを使用して、ノードがどの speaker Pod をスケジュールするか、スケジュールしないかを制御することができます。また、toleration の一覧を適用してこれらの Pod を制限することもできます。アフィニティールール、テイント、および容認の詳細は、追加のリソースを参照してください。

5.4.2.4.2. MetalLB デプロイメントでの Pod の優先順位および Pod アフィニティーの設定
リンクのコピー

オプションで、MetalLB カスタムリソースを設定して、Pod の優先順位と Pod のアフィニティールールを controller Pod および speaker Pod に割り当てることができます。Pod の優先順位は、ノード上の Pod の相対的な重要度を示し、この優先順位に基づいて Pod をスケジュールします。controller または speaker Pod に高い優先順位を設定して、ノード上の他の Pod よりも優先的にスケジューリングされるようにします。

Pod のアフィニティーは Pod 間の関係を管理します。Pod のアフィニティーを controller または speaker Pod に割り当て、スケジューラーが Pod 関係のコンテキストで Pod を配置するノードを制御します。たとえば、Pod アフィニティールールを使用して、複数の特定 Pod を同じノードまたは別のノードに配置するようにできます。これにより、ネットワーク通信が改善され、これらのコンポーネント間の遅延が縮小されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • MetalLB Operator がインストールされている。
  • クラスター上で MetalLB Operator を開始している。

手順

  1. myPriorityClass.yaml などの PriorityClass カスタムリソースを作成して、優先度レベルを設定します。この例では、high-priority という名前の PriorityClass を、値 1000000 で定義します。この優先クラスが割り当てられた Pod は、スケジューリングにおいて、それより低い優先クラスの Pod より優先順位が高いとみなされます。 

    apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
    Copy to Clipboard Toggle word wrap

  2. PriorityClass カスタムリソース設定を適用します。 

    $ oc apply -f myPriorityClass.yaml
    Copy to Clipboard Toggle word wrap

  3. MetalLBPodConfig.yaml などの MetalLB カスタムリソースを作成して、priorityClassName と podAffinity の値を指定します。 

    apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  controllerConfig:
    priorityClassName: high-priority
    1 
    
    affinity:
      podAffinity:
    2 
    
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
             app: metallb
          topologyKey: kubernetes.io/hostname
  speakerConfig:
    priorityClassName: high-priority
    affinity:
      podAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
             app: metallb
          topologyKey: kubernetes.io/hostname
    Copy to Clipboard Toggle word wrap
    1
    MetalLB コントローラー Pod の優先クラスを指定します。この場合、high-priority に設定されます。
    2
    Pod アフィニティールールを設定していることを指定します。これらのルールは、他の Pod またはノードに関連して Pod がどのようにスケジュールされるかを決定します。この設定は、app: metallb ラベルを持つ Pod を同じホスト名を共有するノードにスケジュールするようにスケジューラーに指示します。これは、MetalLB 関連の Pod を同じノード上に配置するのに役立ち、これらの Pod 間のネットワーク通信、遅延、リソース使用量を最適化できる可能性があります。

  4. MetalLB カスタムリソース設定を適用します。 

    $ oc apply -f MetalLBPodConfig.yaml
    Copy to Clipboard Toggle word wrap

検証

  • metallb-system namespace の Pod に割り当てた優先クラスを表示するには、次のコマンドを実行します。 

    $ oc get pods -n metallb-system -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priorityClassName
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                                 PRIORITY
controller-584f5c8cd8-5zbvg                          high-priority
metallb-operator-controller-manager-9c8d9985-szkqg   <none>
metallb-operator-webhook-server-c895594d4-shjgx      <none>
speaker-dddf7                                        high-priority
    Copy to Clipboard Toggle word wrap

  • スケジューラーが Pod アフィニティールールに従って Pod を配置したことを確認するには、次のコマンドを実行して Pod のノードのメタデータを表示します。 

    $ oc get pod -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name -n metallb-system
    Copy to Clipboard Toggle word wrap
5.4.2.4.3. MetalLB デプロイメントでの Pod CPU 制限の設定
リンクのコピー

オプションで、MetalLB カスタムリソースを設定することで、Pod の CPU 制限を controller Pod と speaker Pod に割り当てることができます。controller Pod または speaker Pod の CPU 制限を定義すると、ノード上のコンピュートリソースを管理するのに役立ちます。これにより、ノード上のすべての Pod に、ワークロードとクラスターのハウスキーピングを管理するために必要なコンピューティングリソースが確保されます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • MetalLB Operator がインストールされている。

手順

  1. CPULimits.yaml などの MetalLB カスタムリソースファイルを作成し、コントローラー および speaker Pod の cpu 値を指定します。 

    apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  logLevel: debug
  controllerConfig:
    resources:
      limits:
        cpu: "200m"
  speakerConfig:
    resources:
      limits:
        cpu: "300m"
    Copy to Clipboard Toggle word wrap

  2. MetalLB カスタムリソース設定を適用します。 

    $ oc apply -f CPULimits.yaml
    Copy to Clipboard Toggle word wrap

検証

  • Pod のコンピューティングリソースを表示するには、次のコマンドを実行し、<pod_name> をターゲット Pod に置き換えます。 

    $ oc describe pod <pod_name>
    Copy to Clipboard Toggle word wrap

5.4.2.6. 次のステップ
リンクのコピー

5.4.3. MetalLB Operator のアップグレード
リンクのコピー

デフォルトで namespace を metallb-system にサブスクライブする Subscription カスタムリソース (CR) は、installPlanApproval パラメーターを Automatic に自動的に設定します。そのため、Red Hat が提供する Operator カタログに MetalLB Operator の新しいバージョンが含まれている場合、その MetalLB Operator は自動的にアップグレードされます。

MetalLB Operator のアップグレードを手動で制御する必要がある場合は、installPlanApproval パラメーターを Manual に設定します。

5.4.3.1. MetalLB Operator の手動アップグレード
リンクのコピー

MetalLB Operator のアップグレードを手動で制御するには、namespace を metallb-system にサブスクライブする Subscription カスタムリソース (CR) を編集する必要があります。Subscription CR は Operator のインストール中に作成されます。この CR の installPlanApproval パラメーターは、デフォルトで Automatic に設定されます。

前提条件

  • クラスターを最新の z-stream リリースに更新した。
  • OperatorHub を使用して MetalLB Operator をインストールした。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスします。

手順

  1. 次のコマンドを入力して、metallb-system namespace 内の metallb-operator サブスクリプションの YAML 定義を取得します。 

    $ oc -n metallb-system get subscription metallb-operator -o yaml
    Copy to Clipboard Toggle word wrap

  2. installPlanApproval パラメーターを Manual に設定して、Subscription CR を編集します。 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator
  namespace: metallb-system
# ...
spec:
   channel: stable
   installPlanApproval: Manual
   name: metallb-operator
   source: redhat-operators
   sourceNamespace: openshift-marketplace
# ...
    Copy to Clipboard Toggle word wrap

  3. 次のコマンドを入力して、最新の OpenShift Container Platform 4.19 バージョンの MetalLB Operator を見つけます。 

    $ oc -n metallb-system get csv
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                       DISPLAY            VERSION    REPLACES    PHASE
metallb-operator.v4.16.0   MetalLB Operator   4.16.0                 Succeeded
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを入力して、namespace に存在するインストールプランを確認します。 

    $ oc -n metallb-system get installplan
    Copy to Clipboard Toggle word wrap

    手動インストールプランとして install-tsz2g が表示された出力例

    NAME            CSV                                     APPROVAL    APPROVED
install-shpmd   metallb-operator.v4.16.0-202502261233   Automatic   true
install-tsz2g   metallb-operator.v4.16.0-202503102139   Manual      false
    Copy to Clipboard Toggle word wrap

  5. 次のコマンドを入力して、namespace に存在するインストールプランを編集します。<name_of_installplan> は、install-tsz2g などのインストールプランの名前に置き換えてください。 

    $ oc edit installplan <name_of_installplan> -n metallb-system
    Copy to Clipboard Toggle word wrap

    1. エディターでインストールプランを開いた状態で、spec.approval パラメーターを Manual に設定し、spec.approved パラメーターを true に設定します。

      注記

      インストールプランを編集すると、アップグレード操作が開始します。アップグレード操作中に oc -n metallb-system get csv コマンドを入力すると、出力に Replacing または Pending ステータスが表示される場合があります。

検証

  1. 次のコマンドを入力して、アップグレードが成功したことを確認します。 

    $ oc -n metallb-system get csv
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                                          DISPLAY            VERSION              REPLACE                                 PHASE
metallb-operator.v4.<latest>.0-202503102139   MetalLB Operator   4.16.0-202503102139  metallb-operator.v4.16.0-202502261233   Succeeded
    Copy to Clipboard Toggle word wrap

5.4.3.2. 関連情報
リンクのコピー

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat