徹底比較！HA Kubernetes ClusterにおけるControl Plane LoadBalancerの選択肢

Slide 1

Slide 1 text

Takuto Nagami X: @logica0419 GitHub: @logica0419 徹底比較！ HA Kubernetes Cluster におけるControl Plane LoadBalancerの選択肢

Slide 2

Slide 2 text

自己紹介 ● Takuto Nagami (logica) ● 千葉工業大学情報科学部情報ネットワーク学科 3年 ● ネットワークコンテンツ研究会所属 ○ 数人の自宅サーバーをVPNで繋いでクラウド基盤作ろうとしてます ● 最近はTraeﬁkへのコントリビューションをしたり、さくらのクラウドでDual Stack クラスタに挑戦したりしていました

Slide 3

Slide 3 text

Highly AvailableなK8sクラスタ ● コントロールプレーンが複数台あるクラスタのこと ○ 公式ドキュメントの中では「Highly Available Topology」と呼ばれている ○ etcd入りのコントロールプレーンを複数のタイプと etcdを外部に持つタイプがある ● コントロールプレーンが何個か落ちても大丈夫 ○ 3台以上のコントロールプレーンが必要とされる

Slide 4

Slide 4 text

HAクラスタを使ってるよって人？ (仕事 / 趣味問わず)

Slide 5

Slide 5 text

HAクラスタを構築した経験がある人？ (マネージドを除く)

Slide 6

Slide 6 text

このプロポーザルが落ちた原因が分かりましたね！ (と言えるくらいの比率になる予定) 正直マネージドが多いので需要が少ないとは思ってた

Slide 7

Slide 7 text

HAクラスタの Control Plane ロードバランシング問題

Slide 8

Slide 8 text

Control Planeが複数ある Plane Plane Plane

Slide 9

Slide 9 text

どこ接続すればいいか、わからない Plane Plane Plane ？？？

Slide 10

Slide 10 text

固定してしまったら Plane Plane Plane

Slide 11

Slide 11 text

死んだとき Plane Plane Plane

Slide 12

Slide 12 text

一巻の終わり Plane Plane Plane 💥

Slide 13

Slide 13 text

死んだときには Plane Plane Plane

Slide 14

Slide 14 text

別の所に接続できるように欲しい Plane Plane Plane

Slide 15

Slide 15 text

Worker Nodeからも apiserverに接続が必要なので、これはクラスタ自体の死活問題意外とちゃんとやらないとダメな問題なんです

Slide 16

Slide 16 text

Control Planeのロードバランシング ● コントロールプレーンを冗長化した際、apiserverに常に接続できる状態を維持する ○ 常に生きているプレーンにアクセスできる ○ 同一のIPアドレスで常に接続できる ● Kubernetesエコシステムの中にはツールが無い ○ “Since this is not part of Kubernetes or kubeadm, this must be taken care of separately.” とドキュメントに書いてある

Slide 17

Slide 17 text

何が必要でしょう？

Slide 18

Slide 18 text

何が必要でしょう？ 1. Virtual IPアドレスの割り当て / 広報 2. VIPにきた通信のロードバランシング

Slide 19

Slide 19 text

Virtual IPの割り当て / 広報 192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3

Slide 20

Slide 20 text

Virtual IPの割り当て / 広報仮想IP 192.168.0.5 192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3

Slide 21

Slide 21 text

192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3 仮想IP 192.168.0.5 Virtual IPの割り当て / 広報

Slide 22

Slide 22 text

192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3 仮想IP 192.168.0.5 Virtual IPの割り当て / 広報 192.168.0.5に来た通信はここに届けろ！！！

Slide 23

Slide 23 text

192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3 仮想IP 192.168.0.5 Virtual IPの割り当て / 広報

Slide 24

Slide 24 text

Virtual IPの割り当て / 広報 192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3 仮想IP 192.168.0.5 仮想IP 192.168.0.5

Slide 25

Slide 25 text

Virtual IPの割り当て / 広報 192.168.0.1 192.168.0.2 192.168.0.4 192.168.0.3 仮想IP 192.168.0.5 仮想IP 192.168.0.5 192.168.0.5に来た通信はここに届けろ！！！

Slide 26

Slide 26 text

Virtual IPの割り当て / 広報 ● コントロールプレーンへの通信の「受け口」を定める ○ 生きているマシンのどれかに必ず到達する ○ 「同一のIPアドレスで常に接続できる」を満たす ● 参考: DNSラウンドロビン ○ これは条件を満たさない ■ 死活監視ができず、生きている保証ができない ○ 死活監視をいれた高度なDNSなら満たすが、セルフホスト界隈でスタンダードな手法ではない

Slide 27

Slide 27 text

VIPにきた通信のロードバランシング仮想IP 適当なLB Plane Plane Plane

Slide 28

Slide 28 text

● 来た通信を複数台のコントロールプレーンにロードバランシングする ○ VIPとコントロールプレーンを繋ぐ ○ 落ちていれば別の所に自動的に振り分ける ● 一般的なHTTPリバースプロキシなら条件を満たす ○ kube-apiserverのAPIはHTTPなので ○ 設定のしやすさで選ぶのが良さそう VIPにきた通信のロードバランシング

Slide 29

Slide 29 text

デプロイについて ● デプロイの方法 ○ 受け口は、コントロールプレーンと別でも良い ○ LB専用のマシンを設けるか、コントロールプレーンと同居させるかという選択 ● Static Pod - 同居の場合使える技術 ○ Kubeletベースの機能 (K3sとかは対応してない) ○ Kubernetesと別のライフサイクルを持つコンテナをKubeletが建てて、保全してくれる

Slide 30

Slide 30 text

VIP割り当てとLBを組み合わせる LB Plane Plane Plane VIP割り当て仮想IP LB VIP LB VIP

Slide 31

Slide 31 text

VIP割り当ての選択肢

Slide 32

Slide 32 text

マネージドサービスの場合例えばEKSなら、EKS public endpoint と ENI

Slide 33

Slide 33 text

Keepalived ● VRRP (Virtual Router Redundancy Protocol)を用いて VIPを割り当ててくれるOSS ○ 本来はルーターの冗長化などに使うプロトコル ● 「Keepalivedクラスタ」を構築し、そのクラスタ内で Masterのマシンに通信を振り分ける ○ 全てのLB用マシンが同じL2ネットワーク上にいる必要があり、そのL2ネットワークに広報 ■ インターネットへの広報はネットワーク次第

Slide 34

Slide 34 text

kube-vip ● Kubernetes用に設計されたVIPの割り当てOSS ○ ARPとBGPが選べる ○ ARPはL2ネットワークのみに広報だが、BGPならば外部のルータに対して広報できる ● Kubernetes本体に強く依存 ○ コントロールプレーン同居型セットアップのみ ○ Kubernetes APIへの接続が必要 ■ これが問題となった事件がある

Slide 35

Slide 35 text

唐突にv1.29で壊れたkube-vip https://github.com/kube-vip/kube-vip/issues/684

Slide 36

Slide 36 text

v1.29で何が起こったか ● admin.confの権限変更と、super-admin.confの追加が行われた ○ 無駄に高い権限がついていた所なので良いこと設定ファイルユーザグループ権限備考 admin.conf kubeadm:cluster- admins cluster- admin system:masters だった super-admin .conf system:masters 組み込み権限新設

Slide 37

Slide 37 text

kube-vipからのapiserver参照 ● kube-vipはkube-apiserverに接続する必要がある ○ 通常Podからアクセスするときは、Podに置かれた認証情報でアクセスできる ○ Static Podはセットされない (K8s管理じゃない) ● これまでの接続方法 ○ kubeadmが生成するadmin.confを使っていた ○ /etc/kubernetes/admin.conf に置かれる

Slide 38

Slide 38 text

admin.conf終了のお知らせ E1214 09:30:38.907904 1 leaderelection.go:332] error retrieving resource lock kube-system/plndr-cp-lock: leases.coordination.k8s.io "plndr-cp-lock" is forbidden: User "kubernetes-admin" cannot get resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system" 権限が…！足りない…！！！！！！

Slide 39

Slide 39 text

super-admin.confを使えばいいのでは？ Plane + kube-vip Plane + kube-vip Plane + kube-vip admin.conf admin.conf admin.conf super- admin.conf super- admin.conf super- admin.conf

Slide 40

Slide 40 text

残念ながら… Plane + kube-vip Plane + kube-vip Plane + kube-vip admin.conf admin.conf admin.conf super- admin.conf initしたやつ joinしたやつ joinしたやつ

Slide 41

Slide 41 text

これによって kube-vip on kubeadmは非常に苦しくなったまだ解決の兆しが立っていません

Slide 42

Slide 42 text

その他 ● lelastic ○ LinodeというAkamaiの子会社クラウドが開発した BGPベースの仮想IP割り当てOSS ○ Linode内で使う事しか想定されてなさそう ● とにかくソリューションが少ない！ ○ 現状これが欲しいユースケースが少なそう ○ BGPを用いた、Keepalivedの完全代替みたいなOSS が欲しいなぁという思いがあります

Slide 43

Slide 43 text

ロードバランサーの選択肢

Slide 44

Slide 44 text

あらゆるHTTPリバースプロキシで良い ● HAProxy ● Nginx ● Caddy ● Envoy ● kube-vip ○ なんとロードバランサー機能も備えているなどなど

Slide 45

Slide 45 text

これらを組み合わせたユースケース

Slide 46

Slide 46 text

Kubernetes公式ドキュメント ● https://github.com/kubernetes/kubeadm/blob/main /docs/ha-considerations.md#options-for-software- load-balancing で公式のオススメが提示されている ○ Keepalived + HAProxy ○ kube-vip ● Keepalived + HAProxy が安定していてオススメ ○ HAProxyの部分は、自分の設定しやすいリバースプロキシに置き換えるのが良いでしょう

Slide 47

Slide 47 text

kubespray ● kubesprayでは、HAクラスタを自動構築できる ○ Worker Nodeからコントロールプレーンへの接続はロードバランシングが必要 ● localhost + Nginx を使用 ○ Worker Node上でlocalhostをlistenするNginxを用意し、Nginxでロードバランシング ○ localhostがVirtual IPとして働く ● 外部からの接続は考えていない