はじめに
はじめまして @cp20 です。traP のサーバーの管理には一部 Kubernetes を利用しているのですが、そのクラスタを管理できる人がいなくなりそうな危機なので、さいきん Kubernetes のお勉強をしています。
ちなみにこれはアドベントカレンダー2024 の23日目の記事です。アドベントカレンダーもそろそろ終わりですね。つまり、そろそろクリスマスが、、、おや、誰か来たようだ、、、
Kubernetes とは
一言で言えば「コンテナオーケストレーションツール」です。もう少しかみ砕いて言うと、Docker コンテナを立てたり壊したりをよしなにやってくれるツールです。雑に言えば超強化版 Docker Compose です。
この記事を Kubernetes についての網羅的な解説記事にするつもりはないのでこの程度の説明に留めておきますが、詳しいことが知りたい方は次の記事 (ハンズオン資料) を読んでみると良いと思います。
難しいポイント
エコシステムが難しい
イケイケのクラスタなら ArgoCD とかを使ってクラスタを管理している(?)と思うのですが、既存のツールをクラスタに統合するのが結構難しいです。単に追加するだけならワンコマンドでできるんですが、ちょっと設定を変更したいと言ったときに結構めんどくさくなります。
そもそも Kubernetes クラスタを作るというのは、作業としては manifest の YAML ファイルを書くことです。単なる YAML ファイルなので、外部からパラメータを注入する余地はありません。じゃあどうやって設定を変更するのかというと、もともとの設定ファイルの一部だけ書き換えるという設定ファイルを書きます。
この書き方は (少なくともボクにとっては) 直感的ではなく、かなり難しいと感じました。
デバッグが難しい
結局ここが一番難しい原因なのではないかと思います。Kubernetes においてプログラマー(?)が入力として与えるのはプログラムではなく設定ファイルで、出力として得られる (観測できる) のはそこにあるクラスタの状態です。
ボクがよくやる print デバッグがほとんど使えないので、ドキュメントなどをひたすら読み漁るなどして上手く動かない原因を気合で特定する作業が必要になります。本当につらい。
ボクが nameReference
周りで詰まった例を挙げてみます。kustomize の挙動に secret
に hash suffix を付けてくれるというものがあります。こうすることで secret が変わったときに自動で名前が変わり、リソースが更新されるというメリットがあるのですが、使う側の名前を適切に更新してあげる必要があります。そこで使われるのが nameReference
という機能なのですが、secret の namespace が一致している必要があるということに気付いてなくて、1日以上溶かしました。言われてみればそれはそうという感じですが、この原因を特定するのもひたすら試行錯誤を繰り返した結果たまたま見つかったという感じで、デバッグの困難さがうかがえます。
がんばる
そんな難しいのになんで世間でこんなに Kubernetes が流行っているのかというと、やはり安定性の高さと拡張の容易性が買われているのかなと。確かにそれは欲しいので、がんばって Kubernetes と仲良くなりましょう。
ボクは仲良くなるための第一歩としておうちクラスタを組みました。
ソースコードも公開しているので、こちらも良ければぜひ。
がんばるために
さっきもちらっと挙げたんですが、@toki さんが素晴らしい資料を作ってくださったので、それを読んでみると大まかな概念はつかめると思います。
あとボクは『つくって、壊して、直して学ぶ Kubernetes入門』も読みました。上のハンズオンのもう少し踏み込んだバージョンという感じだったので、興味があればぜひ。
ある程度基礎が学べたら、実際にクラスタを作ってみる、あるいは既存のクラスタを改造してみるという経験を積んでいくしかないのかなと思っています。ボクは今その段階にい (る思ってい) ますが、まだまだ経験値が足りないなぁと感じています。
おわりに
Kubernetes についてもっと詳しく語れれば良かったんですが、今のボクにはそれをするだけの技術力が足りなかったみたいです。もっと詳しくなった時にまたお会いしましょう。