Kubernetesクラスタ
GitHub - tosuke-lab/k8s: 無限大の魔法
k0s
シングルバイナリなディストリビューション
k0sctlという(不安定なところもあるが)それなりに便利なインストールツールがあり,単体でIaCなデプロイが実現できる
CNIプラグイン - Cilium
Service Mesh や L7 Network Policy とか面白そうな機能がたくさんある
可視性は普通に便利
L7のサービスメッシュを導入せずともPod間の通信の様子がだいたいわかる
Multusを使ってmiscord-dev/tetrapodも動かすことになるんでは,というウワサもあります
LoadBalancer Service - PureLB w/ BIRD
PureLBは任意のルーティングデーモンを用いた LoadBalancer Service を提供する
アドレスプールの管理と各ノードにルーティングのためのインターフェースを生やすことまでが責務
BIRDはルーティングデーモン
PureLBの生やしたインターフェースを見て,OSPFを喋って経路を広告する
Ingress Controller - Traefik
ingress-nginxの次くらいにTLSの設定に気持ちがあること
カスタムリソースを利用してプロキシの持つ機能の全てを提供しようとしていること
実はあんまりない特徴で,ingress-nginxは100個くらいのannotationを持つしContourはEnvoyのフィルタをカスタムする機構を持たない
豊富なミドルウェアを活用できるのはうれしい
微妙なところはある
IngressRoute はネストした参照を構成できないので Kubernetes Gateway API におけるHTTPRouteみたいな運用はできないところとか
キャッシュ機構がないこととか
シークレット管理 - External Secrets Operator
方向性としては定番なので,守りの選択
自分用 GCP プロジェクトの Secret Manager に向いている ClusterSecretStore を1つ定義して利用する
GCP Secret Manager にはシークレットごとに IAM とかで可視性を分離する機構はないらしいので,ClusterSecretStore で問題ないはず
マルチテナントは今のところあんまり考えてないので,ClusterSecretStore を何も保護しないで使っているが,必要になったら Admission Webhook で守る方向性
OIDC Provider - dex
別に dex である必要はないのだけれど
本当はセルフホストしたくないものなのだが,Auth0 が OIDC の groups claim に対応していないことで困ったことがあったので
Auth0 以外にいい感じの無料枠がある OIDC Provider を知らない
選定
継続デプロイ
要件
(MUST) apply するツールを拡張できること
この部分で遊びまくりたいと思っているため
(MUST) Pull-based であること
apply 中に中途半端な状態で停止するkubectlに苦しめられたため
検討中
Argo CD
ツール拡張
Plugins - Argo CD - Declarative GitOps CD for Kubernetes
特に cue に関しては GitHub - zoetrope/argocd-cue が参考になりそう
Pros
マルチテナントの強力なサポート
ApplicationSet
Git リポジトリ以外の状態を見てクラスタの状態を変化させるように定義できる
ブランチプレビュー,最新版への自動デプロイが簡単にできるのではという期待
Cons
とにかく巨大であること
持ってる権限も巨大だし,エコシステムも巨大
RBAC が微妙
謎の CSV を書きたくない
ダッシュボードはわかるけど,AppProject,君は???
Flux CD (v2)
ツール拡張
Toolkit Component の拡張で可能 https://fluxcd.io/flux/components/
cue のコントローラ実装もある GitHub - phoban01/cue-flux-controller: A Kubernetes controller for CUE via Flux
Pros
シンプルに構成されている
ダッシュボードとかもなさそう
Source とそれを適用する方法(Kustomize, Helm, ……)が分離されて定義されているのが特徴的
それぞれのリソースは CRD を用いて定義されているので,拡張したければ自分で定義して Controller を書いてくださいという方向らしい
マニフェストを適用するコントローラにServiceAccountを紐付けられる
俺たちが本当に欲しかった RBAC
Cons
あんまりリッチではない感じ
マルチテナントとかがどれだけ定義されているのかは不明
厳密かつ拡張可能に作られている反面,何かやりたいときはコントローラを書くという方向なのが若干重さがある
やればいいのはそう
ムキムキになっちゃいそう
マニフェストの生成をするコントローラが適用も行う必要があるのが微妙い
脱落
Pipe CD
ツール拡張ができない
Kubernetes 以外も対象にできるのは面白い
ストレージ
要件
高速なストレージと信頼性の高いストレージが使えること
同時に実現できれば言うことはないが,そんなことはないはず
複数のCSIプラグインで実現しても可
検討中
OpenEBS
ノードのリソースを使って冗長化する
信頼性側だが,そこそこ速いとのウワサ
MayaStorバックエンドを使った場合は速いが,cStorやJivaを使った場合あんまり,というか悪いらしい
MayaStorはNVMe-OFを,cStorやJivaはiSCSIを使う
KubernetesのLocal Storage
https://kubernetes.io/docs/concepts/storage/volumes/#local
ノードのディレクトリをマウントする,オーバーヘッドの少ない高速側のストレージ
Podの移動はもちろん,ストレージの拡張やPVCによる動的プロビジョニングも提供されないが,特に癖とかはないしシンプルなので採用してもいいと思っている
TopoLVM
LVMを使ってノードのストレージをマウントする,高速側ストレージ
LVMなので動的な割り当てや拡張ができる,スケジューラをカスタムしてストレージの空きに応じて重み付けもしてくれるらしい
ストレージのトポロジーを考慮する,だからTopo
Rook / Ceph
高信頼性ブロックストレージ・オブジェクトストレージを作ってくれるやつ
Longhorn
やってみたい
Synology CSI Driver
高信頼性側
ブロックストレージをNASから切り出し,iSCSIでマウントする
シークレット管理 (一応決定)
要件
(MUST) オペレーションミスへのリカバリ耐性があること
ミスったらシークレットが消失するのは避けたい
(SHOULD) 他ツールへのロックインがないこと
色々遊びたいので
検討中
External Secrets Operator
Secrets Store CSI Driver
Secretリソースで保存している時点で平文なのでよくないというのはまあわからなくもないが,かといって現状のエコシステムだとSecretでないと困る状況も多そうという気もする
Ingress Controller (一応決定)
要件
軽量であること
Service Mesh 的な機能はいらない
認証とのインテグレーション
oauth2-proxy や似たような概念と連携したい
TLS 終端
必須
終端ができる
TLS の最小バージョン指定ができる
Cipher Suites の指定ができる
あったら欲しい
TLS の設定をエンドポイントごとに選べる
こんな感じ https://doc.traefik.io/traefik/https/tls/#tls-options
検討中
Traefik
Dashboard とかはあんまりいらないんだよな……
大量のカスタムリソースを使ってきめ細かく定義ができる
ForwardAuth Middleware による認証機構がある
oauth2-proxy からのサポートがある
TLSOption リソースによる環境ごとの TLS 設定の選択がある
p384, p521 も使える
x448 は使えないが,必要かと言われると微妙
TLS1.2 の ciphers も選択できる
TLS1.3 の ciphers は選択不可能
「全ての cipher suite が安全であると考えられているから」とのこと.まあ妥当だとは思う
若干パフォーマンスが低いらしい
まあGoだし
ingress-nginx
圧倒的な個数の annotation によってきめ細かい制御が可能
ただし annotation なので,Ingressリソース全体に影響する
どうnginxの設定に翻訳されるのかを想像しながら書く必要がある
oauth2-proxyとかを使いたくなった場合,/oauth2を管理する Ingress とそれ以外の Ingress を別に定義する必要が生じる
普通のIngressコントローラだと同一ホストを参照する複数のIngressを定義することはできないので,そういう意味でも強いロックインが生じてしまう
脱落
Cilium
CiliumEnvoyConfigの生成の設定があまりできない
TLS の設定ができない
認証も挟めない
Envoy Gateway
Contour と Kong Proxy,Ambassodor API Gateway あたりがあって混沌としていた Envoy ベースゲートウェイ実装を統合しようとするもの
Kubernetes Gateway API
筋はよさそうだけど,成熟してないのとarm64で動かない
Contour
どちらかと言うと HTTPProxy / Kubernetes Gateway API だけど
Envoy ベース
ext_authz フィルタベースの gRPC な認証機構がある
TLS の設定がどこまでできるのかわからん
TLS1.2 の ciphers の設定はできる
ECDSA256 までしか使えない
Envoyの制約
gRPC-Webのリクエストを強制的にgRPCに変換する(無効化できない)という驚愕のお節介機能が存在する
変換フィルタを入れる場合無効化するオプションを入れないとだめだって習わなかったんですか?
Ciliumの hubble-ui が死ぬ
バックエンドとして Service を指定するが,Service の ClusterIP ではなく Service に対応する Endpoint リソースを参照し,それに対する L7 ロードバランシングを行う
「Service はただの L4 ロードバランサなので,無視して直接ロードバランスを行っても問題ない」という思想っぽい
これがCilium Service Meshと致命的に相性が悪い
Cilium Service Meshは機構としては Service の L4 ロードバランサを拡張して,L7 ロードバランサ/プロキシとして振る舞うようにするものなので,Service の ClusterIP に対するトラフィックにしか介入できず,Endpoint に直接トラフィックを流されると処理できない
LoadBalancer Service provider (決定)
結論を言うとPureLB w/ BIRDしかない(わかっていた)
要件
(MUST) 真のロードバランシングができること
ECMPを構築する
(SHOULD) IPv6が使えること
現状のネットワーク(旧)では,上位のL3スイッチであるIX2105がBGPによるIPv6の経路交換をサポートしておらず,OSPFを使う必要がある
脱落
MetalLB
デフォルトだとIPv4のみ
FRR Setting の情報が少なすぎて不明
Cilium LoadBalancer
CIliumBGPPeeringPolicyとかで設定できるように見えるがそんなことはないらしく,ConfigMap で指定する
ルーティングデーモン相当の物体がgobgpなのでBGPのみ
BGPが使えるなら最良の選択肢だった