Kubernetesを10年触って思う「最初から知りたかったこと」

Kubernetesを触り始めてから10年が経つ。v1.0がリリースされた頃から触っている。10年前の自分に教えたいことを書く。

「Kubernetesは銀の弾丸ではない」

最初に知りたかったのは、これ。Kubernetesを入れれば全てが解決するわけじゃない。

10年前はコンテナオーケストレーションの時代が来ると興奮していた。でも実際には、Kubernetesを入れることで新たな複雑さが生まれる。ネットワークポリシー、RBAC、リソース管理、モニタリング。運用コストは下がるどころか、最初は上がる。

小規模なサービスならDockerだけで十分なケースも多い。Kubernetesが必要な規模かどうかを見極めるのが最初の判断。

YAMLは覚えなくていい

マニフェストのYAMLを暗記しようとして無駄な時間を使った。apiVersion は何だったか、spec の下に何を書くか。全部覚える必要はない。

kubectl explain コマンドで構造を確認できる。Helmチャートやkustomizeで共通部分をテンプレート化できる。今ならAIにマニフェストを生成させることもできる。

大事なのは構造を理解すること。暗記ではなく、何がどう動くかの理解。

トラブルシューティングの順番

障害が起きた時、最初にどこを見るか。これを体系的に学ぶのに3年かかった。

Pod → Event → Log → Node。この順番で見る。

1. kubectl get pods でPodの状態を確認
2. kubectl describe pod でEventを確認
3. kubectl logs でアプリケーションログを確認
4. kubectl describe node でNodeのリソース状態を確認

この基本の流れを最初から知っていれば、障害対応の初動が速くなっていた。

ネットワークは最初に理解すべき

Kubernetesで一番ハマるのはネットワーク。Pod間通信、Service、Ingress、NetworkPolicy。レイヤーが多くて、どこで問題が起きているかわかりにくい。

CNIプラグインの違い（Calico、Cilium、Flannel）がネットワーク挙動に影響する。これを知らずに「なぜか通信できない」と悩んだことが何度もある。

ネットワークの基礎（IPルーティング、DNS、iptables）を理解してからKubernetesに入った方が、遠回りに見えて近道。

リソースリクエストとリミットの罠

resources.requests と resources.limits の設定。これを適当にすると本番で痛い目を見る。

requestsを低く設定しすぎると、スケジューラが小さいNodeにPodを詰め込んで、実行時にリソース不足になる。limitsを高く設定しすぎると、OOMKillやCPUスロットリングが起きる。

適切な値を設定するには、実際のリソース消費を観測する必要がある。最初から正解は出せない。VPA（Vertical Pod Autoscaler）の推奨値を参考にしつつ、徐々に調整する。

Helmとkustomize、どっちを使うか

10年間で何度も議論された話題。結論は「チームによる」。

Helmはパッケージマネージャとして便利。サードパーティのチャートを使えるし、valuesファイルで環境差分を管理できる。ただし、テンプレートが複雑になると読みにくい。

kustomizeはシンプル。ベースマニフェストにパッチを当てる方式。Kubernetesネイティブ。ただし、大きな差分管理には向かない。

自分のチームでは両方使っている。サードパーティはHelm、自社サービスはkustomize。

10年後のKubernetes

10年前と比べて、Kubernetesは確実に使いやすくなった。マネージドサービス（GKE、EKS、AKS）の成熟、エコシステムの充実、ドキュメントの改善。

でも複雑さは増している。サービスメッシュ、GitOps、ポリシーエンジン。覚えることは減っていない。

10年触って思うのは、Kubernetesは「覚える」ものじゃなく「付き合う」もの。技術の進化に合わせて学び続ける覚悟が必要。

関連記事

• 障害は金曜日の夕方にやってくる。オンコール対応で学んだこと
• ターミナルだけで仕事が完結する時代が来ている
• Cloudflare Workersで個人サイトを運用するリアルなコスト