Kubernetesのオンプレ環境で負荷分散ができるMetalLBの動作説明をします。
MetalLBとは
- Kubernetes環境の通信の負荷分散をする場合、クラウドでしか利用できないLoadBalancerタイプのServiceリソースをオンプレ環境でも利用できるようにする機能
- 「BGPモード」と「L2モード」から選択して利用する
- IPv6も利用可能
- バージョン0.12.0からBFDをサポートするようになった
- 公式サイトが一番わかりやすい(https://metallb.universe.tf/)
LoadBalancerタイプとは
- Kubernetesクラスタに入ってくる通信を負荷分散することができる
- Podが外部通信が必要な場合、ServiceでNodePort/LoadBalancerのタイプを指定する必要があり、LoadBalancerタイプを選択すると通信を負荷分散することができる(MetalLBの紹介がメインなので細かくは書かない)
Speaker/Controllerについて
MetalLBを起動すると「Speaker」と「Controller」というPodが立ち上がります。
それぞれの役割について下記に記載します。
Speaker
- Kubernetesの各ノードで稼働するデーモン
- 割り当てられたIPアドレスを持つサービスをアドバタイズする
Controller
- Kubernetesクラスタから1台選出されてIPアドレスの管理を行う
- 設定したIPプールからIPアドレスの払い出しを行う
L2(ARP,NDP)/BGPモードについて
L2(ARP,NDP)
- ネットワークでいうところのVRRP構成(負荷分散機能ではない)
- ノードから1台リーダーが選出され、全ての通信はリーダーノードに運ばれる
- リーダーノードに障害が発生した場合、GARPを使って他ノードにリーダーが切り替わる
BGPモード
- BGPが利用できる装置とピアリングを行う
- ルータ側の機能(ECMP)を用いて負荷分散を行うことができる
- BFDを設定することで高速に障害を検知してルーティングプロトコルに通知して障害時間を短縮できる
クラスタ内の負荷分散について
BGPモードやL2モードは外部からの通信のお話で、ノードに入った後はカーネルのお仕事になります。
技術としてはiptablesかipvsを利用してPodの負荷分散を実現しています。
iptablesとipvsはMetalLBではなく、Kubernetesのコンポーネントであるkube-proxyの設定に依存しており、デフォルトではiptablesを利用します。
話が複雑になりそうなので詳しく知りたい人は参考サイトに記載しているKubernetes公式の解説を参照してください。(絵を描いたけどほぼ同じになってしまった…)
iptables
- 一昔前に一世を風靡したパケットフィルタリングなどを担当していたあいつ
- バックエンドにあるPodをランダムで選択し負荷分散を実現
ipvs
- iptablesを負荷分散特化にしたイメージ
- 負荷分散アルゴリズムを細かく設定できる
- ハッシュテーブルを利用しているのでiptablesと比べて低いレイテンシーで実行できる
クラスタの負荷分散について
デフォルトでは下図のように対象全てのPodに通信が分散されるような構成になっています。
冗長構成を考えた場合は正しい動きですがノード間通信が頻繁に発生して帯域を逼迫する恐れがあります。その場合は、下図の通り設定を変更することでノード間通信を減らすことができます。
ノード内のみで分散設定する場合はServiceにexternalTrafficPolicy: Localを設定することで変更できます。
apiVersion: v1
kind: Service
metadata:
name: sampleNodePort
spec:
type: LoadBarancer
externalTrafficPolicy: Local
最後に
最後までお読みいただきありがとうございます。
今回はMetalLBの動作について説明させていただきました。
次回は実際にBGPモードを利用した負荷分散の設定について書きたいと思います。