KubeVipとは

自宅サーバーはminipc x 3, rasberry pi x 2で構成されています。これらでKubernetesクラスタを組んで運用していますが、minipcの上にはproxmoxでそれぞれvmを3つずつ立てています。 コントロールプレーンを冗長化させたいため、minipc上それぞれに立っているvm上にコントロールプレーンをそれぞれ1nodeずつ、計3nodeがcontrol planeとして動作しています。

これら3つのcontrolplaneを冗長化するためにロードバランサーを設置する必要があります。kubeadmのHA構成の記事に具体的な手順が記述されています。

https://kubernetes.io/ja/docs/setup/production-environment/tools/kubeadm/high-availability/

しかし新にロードバランサーを設置するのはめんどくさく、またロードバランサーが単一障害点になりがちです。なので今回はKubernetesクラスタ内で完結しHA構成にできるkube-vipというものを使用しています。

kube-vip は、外部のハードウェアやソフトウェアに依存せずに、コントロール プレーン (高可用性クラスターを構築するため) とタイプ LoadBalancer の Kubernetes サービスの両方に仮想 IP とロード バランサーを備えた Kubernetes クラスターを提供します。

アーキテクチャについてはいかが詳しいのでそれを参考にしてください。

https://kube-vip.io/docs/about/architecture/

問題

kube-vipを使って暫く運用していましたが、3つのコントロールプレーンの内2つのホストマシンが落ちてしまい、control planeが2つ死んでしまいました。するとクラスタに接続できなくなった。

考えてみると当たり前のことだけど、戸惑ったのでメモ。

chatGPTの結論は以下。

3台 control-plane / 3台 stacked etcd 構成で、2台 control-plane が落ちたため、etcd quorum を失い、kube-vip の leader election に必要な Kubernetes API / Lease 更新ができなかった。

現在の構成としては以下のようになっていて、kube-vipがleaseを使用してleader electionしています。

prd-cp1: kube-apiserver + etcd + kube-vip
prd-cp2: kube-apiserver + etcd + kube-vip
prd-cp3: kube-apiserver + etcd + kube-vip

今回2台のホストPCが落ちたため、2台のapi-server, etcdが落ちたことになります。これにより 2台 / 3台の過半数が取れず、etcd quorum が喪失し、Leaseを書き込むことができず、CotrolPlaneが昇格せず、クラスタ全体が落ちました。