Kubernetes オープンソース ロードバランサー - MetalLB (BGP)

1. 背景

昨年、アジア競技大会の準備として、当社では多くの大画面ディスプレイインターフェースを開発しました。これらの大画面ディスプレイページは、外部部門からもアクセスできるようにする必要があります。当初はIngress方式を採用していましたが、外部部門にDNS設定を依頼する必要があり、NodePortの導入を検討していました。しかし、経営陣はLoadBalancerの導入を希望しました。周知の通り、LoadBalancerは多くの場合、外部ロードバランサーを提供するクラウドプロバイダーでしか利用できず、当社はベアメタルクラスタを採用しています。そのため、オープンソースのLoadBalancerソリューションを探すしかありませんでした。

情報を探しているうちに、KubesphereのOpenELBとMetalLBという2つのソリューションを見つけました。しかし、OpenELBのドキュメントは少なく、古いものが多かったため、MetalLBを選択しました。

2. Metallbの紹介

こちらが公式紹介です。

Kubernetesはベアメタルクラスタ用のネットワークロードバランサを提供していません。Kubernetesが提供するネットワークロードバランサの実装はすべて、様々なIaaSプラットフォームの外部ロードバランサを呼び出します。サポートされているIaaSプラットフォームで実行していない場合、ロードバランサは作成後も無期限に「保留中」状態のままになります。

ベアメタルクラスタの運用担当者は、ユーザートラフィックをクラスタに誘導する方法として、「NodePort」サービスと「externalIPs」サービスの2つしか残されていません。どちらのオプションも本番環境での使用に重大な悪影響を及ぼし、ベアメタルクラスタをKubernetesエコシステムにおける二級市民に仕立て上げています。

MetalLB は、標準ネットワーク デバイスと統合するネットワーク ロード バランサ実装を提供することでこの不均衡を修正し、ベアメタル クラスター上の外部サービスも可能な限り「正常に動作」できるようにすることを目的としています。

MetalLB には、このサービスを可能にするアドレス割り当てと外部通知という 2 つの機能があります。

3. MetalLB（BGP）をデプロイする

（１）展開環境

これは、内部クラスタ トポロジの簡略化された図です。

注意:クラスターの CNI が calico を使用する場合は、calico の BGP モードを無効にする必要があります。無効にしないと、MetalLB の通常の動作に影響します。

（２）展開

 # インストール前の準備
# kube - proxy が IPVS モードを使用している場合は、staticARP を有効にする必要があります。
 kubectl edit configmap - n kube - システムkube - プロキシ
# staticARP を true に設定する
モード: "ipvs"
 IPVS :
 strictARP : 真
#metalLBをデプロイする
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/namespace.yaml
 kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.12.1/manifests/metallb.yaml
 #ポッドの実行ステータスを確認する
[ root @ node1 ~ ]# kubectl get pods - n metallb - system
 名前準備完了ステータス再起動年齢
コントローラー- 6554 b76d68 - gxwml 1 / 1 実行中0 35 d
 スピーカー- p9x5v 1/1 実行中0 35 d ​
 スピーカー- pgxkw 1 / 1 実行中0 35 日
#metalLB を設定する
cat > metallb - eip . yaml << EOF
 apiバージョン: v1
 種類: ConfigMap
 メタデータ
名前空間: metallb - システム
名前: config
 データ：
 設定: |
 仲間：
 - ピア- アドレス: 192.168.0.254 # BGPネイバーIP (コアスイッチIP)
 ピア- asn : 50000 #ピア AS 番号
my - asn : 50001 #ローカルAS 番号
アドレスプール:
 - 名前: デフォルト
プロトコル: bgp # このプロトコルはBGPを使用します
アドレス: # アドレスプール
- 10.11 .11 .1 - 10.11 .11 .254
 終了
以前は、 アドレス プールを 10.11.11.0/24 として構成し、 Metallb はアドレスを割り当てるときに10.11.11.0 も割り当てていました。
 #コアスイッチを構成する
[ コア- スイッチ] bgp 50000
 [ コア- スイッチ- bgp ] ピア192.168 .0 .1 as - 番号50001
 [ コア- スイッチ- bgp ] ピア192.168 .0 .2 as - 番号50001
 [ コア- スイッチ- bgp ] ピア192.168 .0 .3 as - 番号50001

BGP ネイバーの確立ステータスを確認するには、コマンド `[Core-Switch]dis bgp peer` を使用します。

 # K8S ダッシュボードを使って実験してみましょう。
 kubectl get svc - n kubernetes - ダッシュボード
名前タイプクラスタ- IP 外部- IP ポート( 秒) 年齢
ダッシュボード- メトリクス- スクレーパーClusterIP 10.1 .189 .92 < なし> 8000 / TCP 35 d
 kubernetes - ダッシュボードNodePort 10.1 .88 .59 < なし> 443 : 31956 / TCP 35 d
 #現在NodePortを使用していますが、LoadBalancerに変更します。
 kubectl edit svc - n kubernetes - ダッシュボードkubernetes - ダッシュボード
タイプ: ロードバランサー
#保存して終了し、 再度svcをチェックします
kubectl get svc - n kubernetes - ダッシュボード
名前タイプクラスタ- IP 外部- IP ポート( 秒) 年齢
ダッシュボード- メトリクス- スクレーパーClusterIP 10.1 .189 .92 < なし> 8000 / TCP 35 d
 kubernetes - ダッシュボードLoadBalancer 10.1 .88 .59 10.11 .11 .1 443 : 31956 / TCP 35 d
 #Kubernetes ダッシュボードの EXTERNAL - IP にアドレスが割り当てられていることがわかります。

次にスイッチを確認します: [Core-Switch]dis bgp routing-table [Core-Switch]dis ip rou 10.11.11.1.

ご覧の通り、スイッチはルート10.11.11.1を学習しています。ブラウザでhttps://10.11.11.1にアクセスします。