第26章 MetalLB を使用した負荷分散
26.1. MetalLB および MetalLB Operator について
クラスター管理者は、MetalLB Operator をクラスターに追加し、タイプ LoadBalancer
のサービスがクラスターに追加されると、MetalLB はサービスの外部 IP アドレスを追加できます。外部 IP アドレスがクラスターのホストネットワークに追加されます。
IP アドレスがレイヤー 2 プロトコルでアドバタイズされるように MetalLB を設定できます。レイヤー 2 では、MetalLB ではフォールトトレラントな外部 IP アドレスを使用できます。
IP アドレスが BGP プロトコルでアドバタイズされるように MetalLB を設定できます。BGP を使用すると、MetalLB で外部 IP アドレスに対するフォールトトレランス機能および負荷分散が提供されます。
MetalLB は、一部の IP アドレスにレイヤー 2 を、他の IP アドレスに BGP を提供できます。
26.1.1. MetalLB を使用するタイミング
MetalLB の使用は、ベアメタルクラスター、またはベアメタルのようなインフラストラクチャーがある場合や、外部 IP アドレスを使用したアプリケーションへのフォールトトレラントがあるアクセスが必要な場合に役立ちます。
ネットワークインフラストラクチャーを設定し、外部 IP アドレスのネットワークトラフィックがクライアントからクラスターのホストネットワークにルーティングされるようにする必要があります。
MetalLB Operator を使用して MetalLB をデプロイした後、タイプ LoadBalancer
のサービスを追加すると、MetalLB はプラットフォームネイティブなロードバランサーを提供します。
レイヤ 2 モードで動作する MetalLB は、IP フェイルオーバーと同様のメカニズムを利用してフェイルオーバーをサポートします。ただし、仮想ルーター冗長プロトコル (VRRP) とキープアライブに依存する代わりに、MetalLB はゴシップベースのプロトコルを利用してノード障害のインスタンスを識別します。フェイルオーバーが検出されると、別のノードがリーダーノードのロールを引き継ぎ、Gratuitous ARP メッセージがディスパッチされて、この変更がブロードキャストされます。
レイヤ 3 またはボーダーゲートウェイプロトコル (BGP) モードで動作する MetalLB は、障害検出をネットワークに委任します。OpenShift Container Platform ノードが接続を確立した BGP ルーターは、ノードの障害を識別し、そのノードへのルートを終了します。
Pod とサービスの高可用性を確保するには、IP フェイルオーバーの代わりに MetalLB を使用することを推奨します。
26.1.2. MetalLB Operator カスタムリソース
Metal LB Operator は、次のカスタムリソースについて独自の namespace を監視します。
MetalLB
-
MetalLB
カスタムリソースをクラスターに追加する際に、MetalLB Operator は MetalLB をクラスターにデプロイします。Operator はカスタムリソースの単一インスタンスのみをサポートします。インスタンスが削除されると、Operator はクラスターから MetalLB を削除します。 AddressPool
-
MetalLB には、タイプ
LoadBalancer
のサービスを追加する際にサービスに割り当てることができる IP アドレスの 1 つ以上のプールが必要です。AddressPool
カスタムリソースをクラスターに追加する際に、MetalLB Operator はプールから IP アドレスを割り当てることができるように MetalLB を設定します。アドレスプールには IP アドレスのリストが含まれます。リストは、1.1.1.1-1.1.1.1 などの範囲を使用して設定された単一の IP アドレス、CIDR 表記で指定された範囲、ハイフンで区切られた開始アドレスと終了アドレスとして指定された範囲、またはこの 3 つの組み合わせにすることができます。アドレスプールには名前が必要です。ドキュメントは、doc-example
、doc-example-reserved
、doc-example-ipv6
などの名前を使用します。アドレスプールは、Bare MetalLB がプールから IP アドレスを自動的に割り当てるか、名前でプールを明示的に指定するサービス用に IP アドレスを自動的に予約するかを指定します。アドレスプールは、Metal LB がレイヤー 2 プロトコルを使用して IP アドレスをアドバタイズするかどうか、または BGP プロトコルを使用するかどうかを指定します。 BGPPeer
-
BGP ピアカスタムリソースは、通信する MetalLB の BGP ルーター、ルーターの AS 番号、MetalLB の AS 番号、およびルートアドバタイズメントのカスタマイズを識別します。MetalLB は、サービスロードバランサーの IP アドレスのルートを 1 つ以上の BGP ピアにアドバタイズします。サービ出力ドバランサーの IP アドレスは、
Address Pool
カスタムリソースで指定され、protocol
フィールドをbgp
に設定します。 BFDProfile
- BFD プロファイルカスタムリソースは、BGP ピアの双方向フォワーディング検出 (BFD) を設定します。BFD は、BGP のみよりも、パスの障害検出が高速になります。
MetalLB
カスタムリソースをクラスターに追加し、Operator は MetalLB、Bare MetalLB ソフトウェアコンポーネント、controller
および 講演者
をデプロイした後に、実行を開始します。
Operator には、 Address Pool
およびBGP Peer
カスタムリソースに対する Webhook の検証が含まれます。アドレスプールのカスタムリソースの Webhook は、次のチェックを実行します。
- アドレスプール名は一意である。
- IP アドレス範囲は、既存のアドレスプールと重複しない。
-
アドレスプールに
bgpAdvertisement
フィールドが含まれている場合には、protocol
フィールドをbgp
に設定する必要があります。
BGP ピアカスタムリソースの Webhook は、次のチェックを実行します。
- BGP ピア名が既存のピアと一致する場合に、ピアの IP アドレスは一意である必要があります。
-
keepalive Time
フィールドを指定する場合は、holdTime
フィールドを指定し、keep-alive 期間は holdtime よりも短くする必要があります。 -
myASN
フィールドは、すべての BGP ピアで同じである必要があります。
26.1.3. MetalLB ソフトウェアコンポーネント
MetalLB Operator のインストール時に、metallb-operator-controller-manager
デプロイメントは Pod を起動します。Pod は Operator の実装です。Pod は、MetalLB
カスタムリソースおよび AddressPool
カスタムリソースへの変更の有無を監視します。
Operator が MetalLB のインスタンスを起動すると、controller
デプロイメントと speaker
のデーモンセットが開始します。
controller
Operator はデプロイメントおよび単一の Pod を起動します。
LoadBalancer
タイプのサービスを追加する場合、Kubernetes はcontroller
を使用してアドレスプールから IP アドレスを割り当てます。サービスに障害が発生した場合は、controller
Pod のログに次のエントリーがあることを確認します。出力例
"event":"ipAllocated","ip":"172.22.0.201","msg":"IP address assigned by controller
speaker
Operator は、
speaker
Pod 用に設定されたデーモンを起動します。デフォルトでは、Pod はクラスター内の各ノードで起動されます。Metal LB の起動時にMetalLB
カスタムリソースでノードセレクターを指定して、Pod を特定のノードに制限できます。controller
がサービスに IP アドレスを割り当てても、サービスがまだ利用できない場合は、speaker
Pod のログを確認してください。speaker
Pod が使用できない場合は、oc describe pod -n
コマンドを実行します。レイヤー 2 モードの場合には、
コントローラー
がサービスに IP アドレスを割り当てた後に、speaker
Pod はアルゴリズムを使用して、どのノードの、どのspeaker
Pod がロードバランサーの IP アドレスをアナウンスするかを決定します。このアルゴリズムには、ノード名とロードバランサーの IP アドレスのハッシュが含まれます。詳細は、MetalLB と外部トラフィックポリシーを参照してください。speaker
は、Address Resolution Protocol (ARP) を使用して IPv4 アドレスと Neighbor Discovery Protocol (NDP) を公開して、IPv6 アドレスにアナウンスします。
BGP モードの場合、コントローラー
がサービスに IP アドレスを割り当てた後に、各speaker
Pod はロードバランサーの IP アドレスを BGP ピアにアドバタイズします。どのノードが BGP ピアとの BGP セッションを開始するかを設定できます。
ロードバランサーの IP アドレスの要求は、IP アドレスを通知する speaker
でノードにルーティングされます。ノードがパケットを受信した後に、サービスプロキシーはパケットをサービスのエンドポイントにルーティングします。エンドポイントは、最適なケースでは同じノードに配置することも、別のノードに配置することもできます。サービスプロキシーは、接続が確立されるたびにエンドポイントを選択します。
26.1.4. レイヤー 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 モードの概念図](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Networking-ja-JP/images/41d8213d50dd7449fd60c44c47ffd01f/nw-metallb-layer2.png)
前述のグラフは、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 です。
26.1.5. BGP モードの MetalLB の概念
BGP モードでは、各speaker
Pod はサービスのロードバランサー IP アドレスを各 BGP ピアにアドバタイズします。BGP ピアは通常、BGP プロトコルを使用するように設定されたネットワークルーターです。ルーターがロードバランサーの IP アドレスのトラフィックを受信すると、ルーターは IP アドレスをアドバタイズした speaker
Pod が含まれるノードの 1 つを選択します。ルーターはトラフィックをそのノードに送信します。トラフィックがノードに入ると、CNI ネットワークプロバイダーのサービスプロキシーはトラフィックをサービスのすべての Pod に配信します。
クラスターノードと同じレイヤー 2 のネットワークセグメントに直接接続されたルーターは、BGP ピアとして設定できます。直接接続されたルーターが BGP ピアとして設定されていない場合は、ロードバランサーの IP アドレスのパケットが BGP ピアとspeaker
Pod を実行するクラスターノードの間でルーティングされるようにネットワークを設定する必要があります。
ルーターは、ロードバランサーの IP アドレスの新しいトラフィックを受信するたびに、ノードへの新しい接続を作成します。各ルーターのメーカーには、接続開始ノードを選択する実装固有のアルゴリズムがあります。ただし、アルゴリズムは通常、ネットワーク負荷のバランスをとるために、使用可能なノード間でトラフィックを分散するように設計されています。
ノードが使用できなくなった場合に、ルーターは、ロードバランサーの IP アドレスをアドバタイズするspeaker
Pod が含まれる別のノードとの新しい接続を開始します。
図26.1 BGP モードの MetalLB トポロジーの図
![ホストネットワーク 10.0.1.0/24 の speaker Pod は、BGP を使用して、ロードバランサーの IP アドレス 203.0.113.200 をルーターにアドバタイズします。](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.10-Networking-ja-JP/images/afe4598d665b24b7a193bfd5b4440d48/209_OpenShift_BGP_0122.png)
前述のグラフは、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 がない場合よりも早く新しい接続を開始できます。
26.1.6. 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 アドレスを判別できます。
26.1.7. 制限および制限
26.1.7.1. MetalLB のインフラストラクチャーについての考慮事項
MetalLB は、ネイティブのロードバランサー機能が含まれていないため、主にオンプレミスのベアメタルインストールに役立ちます。ベアメタルのインストールに加え、一部のインフラストラクチャーに OpenShift Container Platform をインストールする場合は、ネイティブのロードバランサー機能が含まれていない場合があります。たとえば、以下のインフラストラクチャーは MetalLB Operator を追加するのに役立ちます。
- ベアメタル
- VMware vSphere
MetalLB Operator および MetalLB は、OpenShift SDN および OVN-Kubernetes ネットワークプロバイダーでサポートされます。
26.1.7.2. レイヤー 2 モードの制限
26.1.7.2.1. 単一ノードのボトルネック
MetalLB は、1 つのノードを介してサービス内のすべてのトラフィックをルーティングします。この際、ノードはボトルネックとなり、パフォーマンスを制限する可能性があります。
レイヤー 2 モードは、サービスの Ingress 帯域幅を単一ノードの帯域幅に制限します。これは、ARP および NDP を使用してトラフィックを転送するための基本的な制限です。
26.1.7.2.2. フェイルオーバーのパフォーマンスの低下
ノード間のフェイルオーバーは、クライアントからの操作によって異なります。フェイルオーバーが発生すると、MetalLB は Gratuitous ARP パケットを送信して、サービス IP に関連付けられた MAC アドレスが変更されたことをクライアントに通知します。
ほとんどのクライアントオペレーティングシステムは、Gratuitous ARP パケットを正しく処理し、隣接キャッシュを迅速に更新します。クライアントがキャッシュを迅速に更新すると、フェイルオーバーは数秒以内に完了します。通常、クライアントは新しいノードに 10 秒以内にフェイルオーバーします。しかし、一部のクライアントオペレーティングシステムは Gratuitous ARP パケットをまったく処理しないか、キャッシュの更新を遅延させる古い実装があります。
Windows、macOS、Linux などの一般的なオペレーティングシステムの新しいバージョンは、レイヤー 2 フェイルオーバーを正しく実装します。フェイルオーバーが遅いという問題は、古くてあまり一般的ではないクライアントオペレーティングシステムを除いて、予期されていません。
古いクライアントで予定されているフェイルオーバーの影響を最小限にするには、リーダーシップをフラップした後に、古いノードを数分にわたって実行したままにします。古いノードは、キャッシュが更新されるまで、古いクライアントのトラフィックを転送することができます。
予定外のフェイルオーバー時に、古いクライアントがキャッシュエントリーを更新するまでサービス IP に到達できません。
26.1.7.3. BGP モードの制限
26.1.7.3.1. ノードに障害が発生すると、アクティブなすべての接続が切断される可能性があります
MetalLB には、BGP ベースのロードバランシングに共通する制限があります。ノードに障害が発生した場合や speaker
Pod が再起動した場合など、BGP セッションが中断されると、すべてのアクティブな接続がリセットされる可能性があります。エンドユーザーに、Connection reset by peer
のメッセージが表示される可能性があります。
BGP セッションが中断された場合にどうなるかは、各ルーターの製造元の実装によります。ただし、speaker
Pod の数を変更すると、BGP セッションの数に影響し、BGP ピアとのアクティブな接続が切断されることが予想されます。
サービスの中断の可能性を回避または低減するために、BGP ピアの追加時にノードセレクターを指定できます。BGP セッションを開始するノードの数を制限すると、BGP セッションのないノードでの障害が発生しても、サービスへの接続に影響はありません。
26.1.7.3.2. コミュニティーは 16 ビット値として指定されます
コミュニティーは、アドレスプールカスタムリソースの一部として、コロン区切りの 16 ビット値で指定されます。たとえば、ロードバランサーの IP アドレスが既知のNO_ADVERTISE
コミュニティー属性でアドバタイズされるように指定するには、次のような表記を使用します。
apiVersion: metallb.io/v1beta1 kind: AddressPool metadata: name: doc-example-no-advertise namespace: metallb-system spec: protocol: bgp addresses: - 192.168.1.100-192.168.1.255 bgpAdvertisements: - communities: - 65535:65282
コミュニティーが 16 ビット値としてしか指定されないという制限が、bgp-communities
フィールドと BGP コミュニティーの読み取り可能な名前をサポートする MetalLB のコミュニティーサポート実装との違いです。
26.1.7.3.3. 単一の ASN とルーター ID のみのサポート
BGP ピアカスタムリソースを追加するときは、 spec.myASN
フィールドを指定して、MetalLB が属する Autonomous System Number (ASN) を特定します。OpenShift Container Platform は、MetalLB を使用した BGP の実装を使用しますが、この実装は MetalLB が単一の ASN に所属する必要があります。BGP ピアを追加し、 spec.myASN
に既存の BGP ピアカスタムリソースとは異なる値を指定しようとするとエラーが発生します。
同様に、BGP ピアカスタムリソースを追加する場合には、spec.router D
フィールドはオプションです。このフィールドに値を指定する場合は、追加する他の BGP ピアカスタムリソースすべてに、同じ値を指定する必要があります。
単一の ASN と単一のルーター ID のサポートに制限がある点が、コミュニティーがサポートする MetalLB の実装との違いです。