Kubernetesクラスタ
シングルバイナリなディストリビューション
k0sctlという(不安定なところもあるが)それなりに便利なインストールツールがあり，単体でIaCなデプロイが実現できる Service Mesh や L7 Network Policy とか面白そうな機能がたくさんある
可視性は普通に便利
PureLBは任意のルーティングデーモンを用いた LoadBalancer Service を提供する アドレスプールの管理と各ノードにルーティングのためのインターフェースを生やすことまでが責務
カスタムリソースを利用してプロキシの持つ機能の全てを提供しようとしていること
豊富なミドルウェアを活用できるのはうれしい
微妙なところはある
キャッシュ機構がないこととか
方向性としては定番なので，守りの選択
自分用 GCP プロジェクトの Secret Manager に向いている ClusterSecretStore を1つ定義して利用する マルチテナントは今のところあんまり考えてないので，ClusterSecretStore を何も保護しないで使っているが，必要になったら Admission Webhook で守る方向性
本当はセルフホストしたくないものなのだが，Auth0 が OIDC の groups claim に対応していないことで困ったことがあったので 選定
継続デプロイ
要件
(MUST) apply するツールを拡張できること
この部分で遊びまくりたいと思っているため
(MUST) Pull-based であること
apply 中に中途半端な状態で停止するkubectlに苦しめられたため
検討中
ツール拡張
Pros
マルチテナントの強力なサポート
ApplicationSet
Git リポジトリ以外の状態を見てクラスタの状態を変化させるように定義できる
ブランチプレビュー，最新版への自動デプロイが簡単にできるのではという期待
Cons
とにかく巨大であること
持ってる権限も巨大だし，エコシステムも巨大
謎の CSV を書きたくない
ダッシュボードはわかるけど，AppProject，君は？？？
ツール拡張
Pros
シンプルに構成されている
ダッシュボードとかもなさそう
Source とそれを適用する方法(Kustomize, Helm, ……)が分離されて定義されているのが特徴的
それぞれのリソースは CRD を用いて定義されているので，拡張したければ自分で定義して Controller を書いてくださいという方向らしい
マニフェストを適用するコントローラにServiceAccountを紐付けられる
俺たちが本当に欲しかった RBAC
Cons
あんまりリッチではない感じ
マルチテナントとかがどれだけ定義されているのかは不明
厳密かつ拡張可能に作られている反面，何かやりたいときはコントローラを書くという方向なのが若干重さがある
やればいいのはそう
ムキムキになっちゃいそう
マニフェストの生成をするコントローラが適用も行う必要があるのが微妙い
脱落
ツール拡張ができない
Kubernetes 以外も対象にできるのは面白い
ストレージ
要件
高速なストレージと信頼性の高いストレージが使えること
同時に実現できれば言うことはないが，そんなことはないはず
複数のCSIプラグインで実現しても可
検討中
ノードのリソースを使って冗長化する
信頼性側だが，そこそこ速いとのウワサ
MayaStorバックエンドを使った場合は速いが，cStorやJivaを使った場合あんまり，というか悪いらしい
ノードのディレクトリをマウントする，オーバーヘッドの少ない高速側のストレージ
Podの移動はもちろん，ストレージの拡張やPVCによる動的プロビジョニングも提供されないが，特に癖とかはないしシンプルなので採用してもいいと思っている LVMを使ってノードのストレージをマウントする，高速側ストレージ LVMなので動的な割り当てや拡張ができる，スケジューラをカスタムしてストレージの空きに応じて重み付けもしてくれるらしい ストレージのトポロジーを考慮する，だからTopo
高信頼性ブロックストレージ・オブジェクトストレージを作ってくれるやつ
やってみたい
高信頼性側
シークレット管理 (一応決定)
要件
(MUST) オペレーションミスへのリカバリ耐性があること
ミスったらシークレットが消失するのは避けたい
(SHOULD) 他ツールへのロックインがないこと
色々遊びたいので
検討中
Secretリソースで保存している時点で平文なのでよくないというのはまあわからなくもないが，かといって現状のエコシステムだとSecretでないと困る状況も多そうという気もする
要件
軽量であること
Service Mesh 的な機能はいらない
認証とのインテグレーション
TLS 終端
必須
終端ができる
TLS の最小バージョン指定ができる
Cipher Suites の指定ができる
あったら欲しい
TLS の設定をエンドポイントごとに選べる
検討中
Dashboard とかはあんまりいらないんだよな……
大量のカスタムリソースを使ってきめ細かく定義ができる
ForwardAuth Middleware による認証機構がある
TLSOption リソースによる環境ごとの TLS 設定の選択がある
p384, p521 も使える
x448 は使えないが，必要かと言われると微妙
「全ての cipher suite が安全であると考えられているから」とのこと．まあ妥当だとは思う
若干パフォーマンスが低いらしい
圧倒的な個数の annotation によってきめ細かい制御が可能
ただし annotation なので，Ingressリソース全体に影響する どうnginxの設定に翻訳されるのかを想像しながら書く必要がある oauth2-proxyとかを使いたくなった場合，/oauth2を管理する Ingress とそれ以外の Ingress を別に定義する必要が生じる 普通のIngressコントローラだと同一ホストを参照する複数のIngressを定義することはできないので，そういう意味でも強いロックインが生じてしまう 脱落
TLS の設定ができない
認証も挟めない
筋はよさそうだけど，成熟してないのとarm64で動かない ext_authz フィルタベースの gRPC な認証機構がある TLS の設定がどこまでできるのかわからん
ECDSA256 までしか使えない
変換フィルタを入れる場合無効化するオプションを入れないとだめだって習わなかったんですか？
バックエンドとして Service を指定するが，Service の ClusterIP ではなく Service に対応する Endpoint リソースを参照し，それに対する L7 ロードバランシングを行う
「Service はただの L4 ロードバランサなので，無視して直接ロードバランスを行っても問題ない」という思想っぽい
Cilium Service Meshは機構としては Service の L4 ロードバランサを拡張して，L7 ロードバランサ/プロキシとして振る舞うようにするものなので，Service の ClusterIP に対するトラフィックにしか介入できず，Endpoint に直接トラフィックを流されると処理できない LoadBalancer Service provider (決定)
要件
(MUST) 真のロードバランシングができること
脱落