Kubernetes クラスターに MetalLB を導入して負荷分散を実現する

概要

パブリック クラウドに展開された Kubernetes クラスターでは、パブリック クラウド ベンダーが LoadBalancer タイプのサービスを提供します。ただし、ローカル環境に基づいてデプロイされた k8s クラスターは、私たちがよく使用するテスト環境と開発環境です。外部トラフィックは NodePort と externalIP を介してクラスターに導入する必要があり、多くの不便が生じます。

特に、Helm を介して一部のサービスをデプロイする場合、LoadBalancer のリソース タイプに依存することが多く、作成されたサービス内のtype: LoadBalancers が常に Pending 状態になります。ウェアハウスを取得して、値を手動で変更する必要があります。

Metallb は標準のルーティング プロトコルを使用してこの問題を解決します。 MetalLBもCNCFサンドボックスプロジェクトであり、最初にリリースされたのは
https://github.com/google/metallb で開発され、後に https://github.com/metallb/metallb に移行されました。

MetalLB はMetalLB フックを通じてSVCの変更を監視します。次に、スピーカーコンポーネントを介して対応するモードを使用して、外部トラフィックをKubernetesクラスターノードの到達可能なパスに送信します。具体的には、Pod 内では、トラフィックは転送モード (iptables または ipvs) に従ってkuber-proxyを介して Pod に転送されます。

MetaLB はホスト ディメンションからの負荷分散を担当し、ポッド レプリカ間の負荷はkube-proxyを通じて実現されます。 MetalLB は、IP アドレスの割り当て、設定されたブロードキャスト モードに従ったブロードキャスト、ノードの選択、ノードのフェイルオーバーなどの機能を担当します。トラフィック転送プロセスは、ARP、NDP、BGP 標準ルーティング プロトコルを通じて実現されます。

2つの主な機能:

1. アドレスの割り当て: ユーザーは構成でアドレス プールを提供する必要があります。Metallb はそこからサービスに割り当てるアドレスを選択します。
2. アドレス ブロードキャスト (IP 外部宣言): 構成に応じて、Metallb はレイヤー 2 (ARP/NDP) または BGP モードでアドレスをブロードキャストします。

動作モード:

1. BGP モード (レイヤー 3) は、BGP プロトコルを使用してアドレス プールを割り当てます。 BGP を実行しているデバイスはルーティング情報を交換できます。 BGP プロトコルを通じて他のデバイスに独自の IP セグメントを通知できるため、他のデバイスはデータ パケットをサーバーに正しくルーティングできます。 BGP にはルーターのサポートが必要です。 Calico も BGP モードを使用している場合、競合が発生し、metallb が正しく動作しなくなる可能性があります。
2. ARP (IPV4)/NDP (IPV6) 動作モード (レイヤー2) ARP/NDP プロトコルを使用してアドレス プールを割り当てます。サーバーの内部サブネットで未使用の IP を見つけ、他のコンピューターがこの IP にアクセスすると、ARP パケットで応答します。この IP は実際にはどのネットワーク カードにもバインドされておらず、iptables 内のレコードにすぎない場合もありますが、他のコンピューターはこの IP が通信できる場所を認識します。割り当てられた IP は、サーバーの他の IP と同じサブネット内にのみ存在できるため、すべてのノードが同じレイヤー 2 ネットワーク内にある必要があります。

詳細については、公式ドキュメントhttps://metallb.universe.tf/ を参照してください。

建築

2 層デプロイメントのアーキテクチャ図については、Red Hat OpenShift の公式ドキュメントを参照してください。

上の図は、MetalLB に関連する次の概念を示しています。

• アプリケーションは、 172.130.0.0/ 16 サブネット上のクラスター IP を持つサービスを通じて利用できます。この IP アドレスはクラスター内からアクセスできます。サービスには、サービスに割り当てられた MetalLB の外部 IP アドレス(192.168.100.200)もあります。
• ノード 1 と 3 には、アプリケーション用のポッドがあります。
• スピーカーデーモンは、各ノードで実行されるポッドを設定します。 MetalLB オペレーターがこれらのポッドを起動します。
• 各スピーカーポッドはホスト ネットワークのポッドです。ポッドの IP アドレスは、ホスト ネットワーク上のノードの IP アドレスと同じです。
• ノード 1 のスピーカーポッドは、ARP を使用してサービスの外部 IP アドレス192.168.100.200 を通知します。外部 IP アドレスを宣言するスピーカーポッドは、サービス エンドポイントと同じノード上に存在し、エンドポイントは準備完了状態である必要があります。
• クライアント トラフィックはホスト ネットワークにルーティングされ、 192.168.100.200 IP アドレスに接続します。トラフィックがノードに入ると、サービス プロキシは、サービスに設定された外部トラフィック ポリシーに基づいて、同じノード上のアプリケーション ポッドまたは他のノードにトラフィックを送信します。
• ノード 1 が使用できなくなった場合、外部 IP アドレスは別のノードにフェールオーバーされます。アプリケーション ポッドとサービス エンドポイント インスタンスがある別のノードでは、スピーカーポッドが外部 IP アドレス192.168.100.200 のアナウンスを開始し、新しいノードがクライアント トラフィックを受信します。グラフでは、唯一の候補はノード 3 です。

展開する

環境要件

クラスターのバージョン情報は次のとおりです。

MetalLB をサポートする CNI は次のとおりです。

注記：

• ご使用の環境が MetalLB をサポートしているかどうかを確認するには、クラウド互換性(https://metallb.universe.tf/installation/clouds/)を参照してください。
• BGP 動作モードを使用する場合は、BGP をサポートする 1 つ以上のルータが必要です。
• レイヤー 2 モードは ARP と NDP に依存しているため、MetalLB が適切に動作するには、クライアントがサービス停止していないノードと同じサブネット上に存在する必要があります。さらに、サービスに割り当てられる IP アドレスは、クライアントがサービスにアクセスするために使用するネットワークと同じサブネット内にある必要があります。
• L2 動作モードを使用する場合、すべてのノードは同じレイヤー 2 ネットワーク内にある必要があります。ノードはポート 7946 (TCP および UDP、他のポートも構成可能) を介して通信できるように許可されている必要があり、memberlist サービスはこのポートをリッスンします。レイヤー 2 モードでは、IP を動作ノードのネットワーク インターフェイスにバインドする必要はありません。これは、ローカル ネットワーク上の ARP 要求に直接応答し、ローカル MAC アドレスをクライアントに提供することで機能します。
• Kubernetes v1.14.2 以降では、kube-proxy が IPVS モードを使用する場合は、厳密な ARP モードを有効にする必要があります。 kubectl edit configmap -n kube-system kube-proxyを使用して、次のように変更します。

 apiバージョン: kubeproxy 。 設定。 k8s 。 io / v1alpha1
 種類: KubeProxyConfiguration
 モード: "ipvs"
 IPvs :
 strictARP : 真

Helm経由でインストール

MetalLB は、Kubernetes マニフェスト、Kustomize、Helm を使用してインストールできます。ここでは helm を使用してインストールします。

 $ helm リポジトリに metallb を追加します https://metallb.github.io/metallb
 $ helm リポジトリを検索 -l metallb
 $ helm フェッチ metallb/metallb --version=0.13.4
 $ tar zxvf metallb-0.13.4.tgz
 #ここでは、必要に応じて値を変更できます。たとえば、元のイメージアドレス（quay.io）を取得できない場合は、まずそれを取得して独自のイメージリポジトリにアップロードし、その後アドレスを変更します。
 $ kubectl 名前空間 metallb-system を作成します
 $ helm インストール metallb -n metallb-system ./metallb

以下のようにインストールを確認します

metallb-system名前空間の下に、次の 2 つのコンポーネントがインストールされます。

• コントローラーのデプロイメント: サービス リソースの変更を監視する役割を担います。対応する IP アドレス プールに基づいて IP アドレスを割り当てるコントローラ。
• スピーカーデーモンセット: サービスリソースの変更を監視する役割を担います。プロトコルを通じてサービス間の接続を維持し、対応するブロードキャストと応答を開始し、特定のプロトコルに基づいてノード リーダーを選出します。

スピーカーポッドは、IPv4 サービスと IPv6 の NDP 要求に応答します。

マニフェスト経由でインストール

MetalLB をインストールするには、yaml アプリケーション マニフェストを使用します。

 $ kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.4/config/manifests/metallb-native.yaml

構成

クラスターはテスト環境で動作するため、L2 動作モードを使用します。

レイヤー 2 モードは最も簡単に始めることができ、あらゆる環境で動作します。特別なルーターは必要ありません。

負荷分散サービスに割り当てる IP アドレス プールを定義します。

metallb の新しいバージョンでは、CR (カスタム リソース) が使用されます。ここでは、 IPAddressPoolの CR を通じてアドレス プールを定義します。

インスタンスにIPAddressPoolセレクターL2Advertisement が設定されていない場合、 L2AdvertisementはデフォルトでインスタンスのすべてのIPAddressPoolsに関連付けられます。

metallb-config-ipaddresspool.yaml を作成します。

 apiバージョン: metallb .io / v1beta1
 種類: IPアドレスプール
メタデータ:
 名前: ファーストプール
名前空間: metallb - システム
仕様:
 住所:
 - 192.168 .74 .100 - 192.168 .74 .110

L2 関連アドレス プールをバインドします。ここでタグセレクターも使用できます。

metallb-config-L2Advertisement.yaml を作成します。

 apiバージョン: metallb .io / v1beta1
 種類: L2広告
メタデータ:
 名前: 例
名前空間: metallb - システム
仕様:
 ipアドレスプール:
 - 最初- プール

テスト

テスト用に LoadBalancer タイプの SVC を作成し、yaml ファイルtutorial-1.yaml を作成します。

 apiバージョン: アプリ/ v1
 種類: デプロイメント
メタデータ:
 名前: nginx
 名前空間: デフォルト
仕様:
 セレクター:
 マッチラベル:
 アプリ: nginx
 テンプレート：
 メタデータ:
 ラベル:
 アプリ: nginx
 仕様:
 コンテナ:
 - 名前: nginx
 画像: nginx : 1
 ポート:
 - 名前: http
 コンテナポート: 80
 ---
 APIバージョン: v1
 種類: サービス
メタデータ:
 名前: nginx
 名前空間: デフォルト
仕様:
 ポート:
 - 名前: http
 ポート: 80
 プロトコル: TCP
 ターゲットポート: 80
 セレクター:
 アプリ: nginx
 タイプ: ロードバランサー

結果は次の図に示されています。

ブラウザ経由でアクセス:

参考URL:

• https://access.redhat.com/documentation/zhcn/openshift_container_platform/4.9/html/networking/_load-balancing-with-metallb。
• https://metallb.universe.tf/ をご覧ください。