Kubernetesを自作してみた？2024年版・自作K8sの歩き方

Kubernetesを一から構築するという試み、エンジニアなら一度は憧れますよね。2024年現在のモダンな環境において、どうやって自分だけのK8sクラスターを組み上げるのか。その深淵なる世界へようこそ。

個人的には、Kubernetesが不可避なものだとは思わないし、この記事はそれを前提にしているように見える。K8sはウェブ経由で提供されるSaaSプロダクトを動的にスケーリングするには最適だ。でも、それ以外の状況、例えばオンプレミス環境や、単にAPI互換性のためにK8sを動かしているシングルノードの「クラスター」のようなケースでは、過剰スペックか、あるいは悪い選択肢に思える。クラウドでデプロイする場合でも、K8sは結局のところ、基盤となるクラウドプロバイダーのサービスやAPIの周りに「電池は別売り」のようなラッパーを被せているに過ぎないことが多い。それに、K8sの内部構造を深く理解している人たちの中には、真っ当な批判をしている人もいる。例えば、MetalLBの開発者によるこの記事とか: https://blog.dave.tf/post/new-kubernetes/ 何かを導入する前に、そのメリットとデメリット、そしてそれが解決するために作られた課題は何かを実際に理解すること。もし自分の抱える課題がK8sとあまり合致していないなら、他の方法を探すべきだ。

Kubernetesの何が悲しいって……全部セットアップし終えた後に、結局はimage tagをsedで書き換えるようなhackyなdeploy.shが必要になることだよ！そしてすぐに「親愛なる友人よ、君はHelmを自作してしまったのか」という状態に戻る。そうして設定という名の時計の針が回り続けるのさ……

これを公開したその日に見つけたのがこれ: https://github.com/oddur/yoink Kubernetesはやりすぎだった（仕事で毎日嫌というほど触ってるし）、Kamalは制限が多すぎた。結局、Yoinkを自分で作ることにしたよ。K8sに求めていた要素はそのままに、Hetznerのベアメタルマシンにも簡単にデプロイできるシンプルさがあって、自分のワークロードを全て動かすには十分さ。

少し大げさなのは承知の上だけど、Kubernetesが複雑すぎるとか不要だとか言われるのを聞くと、いつもこんな気分になるんだ。Kubernetesを提案すると決まって「そんなのK8sなしでも全部できるだろ」と言われる。もちろんその通り。K8sができることを実現する方法なんて100万通りあるし、中にはもっとシンプルで、今のユースケースにぴったりなものもあるだろう。K8sが提供する選択肢に対して、一つずつ自分で判断を下していけば、自分のワークロードにとってより完璧な環境を作れるかもしれない。でも、K8sの最大の利点は、それらの選択がすでに「決定・合意済み」であることなんだ。おかげでツール、専門知識、ブログ記事、AIの知見など、K8sの選択を理解して連携できる広大なエコシステムが手に入る。これは本当に強力だよ。

その通り！自分は自宅でK8sを動かしてる。以前はdocker-composeを使っていたし、今でもほとんどの人にはそちらを勧めるけど、4vcpu / 16GiのNUCを1台使っているだけの自宅ラボでも、やっぱりK8sでのデプロイが好きだな。個人的には本当にこっちの方がシンプルなんだ。もし何かの参考になれば、自分の構成はこんな感じ：ArgoCDをGitLabのリポジトリに向けていて、GitLabリポジトリにはHelmチャートが入っている。ほとんどのHelmチャートにはオープンソースのチャートがサブチャートとして含まれていて、バージョンは version: ~0 と設定しているから、メジャーバージョンが1になるまでは自動的にアップデートされる。アプリの更新は、UIにログインしてインフラとimage tagの更新を確認し、手動で同期ボタンを押すだけ。これを数ヶ月に1回やってる。次のサイドプロジェクトは、今のハードウェア制限を超えたくなった時に、セキュアなWireGuardトンネル経由でクラウドへオートスケーリングさせることかな。

K8sを使わずにComposeとシェルスクリプトでセルフホストしている身としては、シンプルさを維持したいという気持ちは痛いほど分かるし、これこそがK8sを否定する前に「K8sが何を解決するのか」を理解すべき理由だ。自分はオーバーレイネットワークなんて組んでないし、単一のベアメタルホストを使っている。K8sのクラスター管理者体験よりも、実際に自分でLinuxを管理する体験を重視しているからこそ、あえてK8sを使わない選択をしているんだ。でも、もし高可用性（HA）が必要になったり、ローカルVLANからマルチクラウドのオーバーレイに移行したくなったりして、ローカルのLinux管理が面倒になったら？その時は間違いなくリストのトップにK8sが来るよ。でも、今は自分の今のニーズにこのやり方がぴったりハマっているんだ。

Kubernetesは複雑な課題のための強力なツールだ。もし複雑に見えるのなら、おそらく君は複雑なデプロイの課題を抱えていないんだろう。でもこれって、どんな強力なツールにも当てはまることだよ。電圧を測るだけなら、4チャンネルのオシロスコープなんて確かに複雑すぎるように見えるだろうしね。

当時の議論:Dear friend, you have built a Kubernetes - https://news.ycombinator.com/item?id=42226005 - 2024年11月 (277コメント)

彼らが作ったのは「オーケストレーター」であって、Kubernetesではないね。決定的な違いが一つある。彼らはこのシステムを、隅々まで、ネジの1本からダクトテープの破片まで（Docker内部は別として）全て把握しているという点だ。複雑なシステムを維持する上で、これは非常に重要な違いだよ。LLMの登場で変わった部分もあるかもしれないけれど（意思決定のロジックに新しい能力がどう影響するかはまだ探っている最中だ）、機械知能が登場する前は、Kubernetesのトラブルシューティングは地獄そのものだったから。