|
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
kubectl apply -f
#ポッドの実行ステータスを確認する
[ 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にアクセスします。 | 