Kubernetes 2.0はどのようなものになるか

2025年6月19日原文(matduggan.com)

概要

Googleの Borg から始まったコンテナオーケストレーションの歴史
Kubernetes （k8s）の登場と普及の経緯
インフラ運用の変革とk8sの功績
YAMLの課題と HCL への期待
etcd依存からの脱却案

Kubernetesの進化とその影響

2012-2013年頃、Google内部のBorgがsysadminコミュニティで話題に
- Borglet、クラスター、セル、サービス、ジョブなど独特な用語
- サービスはユーザーリクエスト対応、ジョブは長時間バッチ処理
2014年6月7日、Kubernetesの最初のコミット
- 発音困難な「Kubernetes」だが、k8sの略称が普及
- Microsoft、RedHat、IBM、Dockerが早期にコミュニティ参加
2015年7月21日、v1.0リリースとCNCF設立
- Kubernetesは業界標準へと成長
インフラ管理の新常識
- サーバーレベルの管理から宣言的・スケーラブル・自己修復型運用へ
- 学習コストは高いが、圧倒的な生産性向上

Kubernetesがもたらした主なメリット

コンテナのスケール運用
- Docker Compose等では手動作業が多かったが、k8sで自動化と大規模展開が容易に
- マイクロサービス設計への移行を加速
低メンテナンスな運用
- 「Simpsons時代」：個別サーバーに固有名、手作業中心
- 「01時代」：Puppet/Ansibleで自動化、サーバーの使い捨て化進行
- 「UUID時代」：サーバーはコンテナ実行のための消耗品、自己修復が標準
ジョブ管理の進化
- cron専用サーバー不要、k8sのジョブで再実行やスケジューリングも簡単
- バックグラウンド処理の品質向上
サービス発見とロードバランシング
- 固定IPやDNS依存から解放、Service APIで安定した接続先を提供
- ExternalNameで外部サービスもクラスタ内のように扱える

YAMLの課題とHCLへの期待

YAMLの問題点
- インデントミスや型の曖昧さ、スケーラビリティの低さ
- "NO"がfalseになる「Norway問題」など、仕様上の落とし穴多数
HCL（HashiCorp Configuration Language）の利点
- Terraformで既に実績あり、型安全性・バリデーション機能が充実
- 変数・参照・関数・条件分岐・ループ等、柔軟な記述が可能
- コメントやエラー処理も強化、再利用性・検証性も向上
- YAMLより冗長だが、品質・保守性の大幅向上
- MPL-2.0ライセンスのためApache 2.0プロジェクト統合時は法的確認が必要

HCLの例とYAMLとの比較

YAML
- 型の曖昧さやミスを招きやすい
- 動的値の生成や変換に外部ツールが必要
HCL
- 型・バリデーション・動的生成を言語レベルでサポート
- 例：変数参照、条件分岐、組み込み関数で柔軟な設定が可能

etcdからの脱却案

etcd依存の課題
- 小規模クラスタではリソース過多、唯一の選択肢であることに疑問
- k8s以外での利用が減少し、今後の保守性に懸念
代替案としてのkineやdqlite
- バックエンドの抽象化で将来の拡張性・柔軟性を確保
- 例：分散SQLite＋Raftで軽量クラスタを実現
- etcdが適している場合はそのまま利用可能、選択肢の拡大

まとめと今後への提言

Kubernetes はコンテナ管理の標準として定着し、運用の常識を変革
YAML の限界を認識し、 HCL 等への移行を検討
etcd 以外の選択肢を公式にサポートし、より幅広いユースケースに対応
コミュニティ全体で「より使いやすく、安全で拡張性の高いk8s」を目指す推進

Hackerたちの意見

2.0リリースにしてはあまり野心的なウィッシュリストじゃないね。話をする人みんな、プロダクションでのk8sの複雑さに不満を持ってるから、重要なのは、十分な後方互換性を持たせて、段階的に導入できるようにして、シンプルにできるかってことだと思う。後方互換性があると、常に新しいシステムが新しいことをする分、複雑さが増すからね。

└

いつも問題になるのは、その複雑さのどの部分を排除できるかってことだよね。今まで見た「k8sの抽象化」は、非常に小さなサブセットのものにしか機能しない（例えばHerokuのようなラッパー）か、最終的にはk8sと同じくらい複雑な完全なDSLを発展させる（そして今度はその仕事特有のDSLを学ばなきゃいけない）って感じだ。

追加したいのは「常識的なデフォルト」かな。つまり、何も選ばなければ、十分なロードバランサーやネットワーク、永続ストレージが得られるってこと。YAMLは良い選択じゃないってのには同意するけど、HCLもダメだよね。Terraformを読んだことある？あれもひどいよ。根本的に、Kubernetesクラスターを設定するためのもっと良い方法が必要だし、言語を変えるだけじゃ限界がある。IPv6、絶対に必要だよ。Dockerやコンテナ、Kubernetesは最初からIPv6専用で内部にするべきだった。IPv4が必要？それは特別なイングレスコントローラーで対応すればいい。

└

常識的なデフォルトは「クラウドプロバイダーの管理サービスの顧客にさせること」と矛盾してる。k8sを見れば見るほど、ストレージやネットワーキング周りが「バッテリーなし」って感じがする。結果として、バッテリーはAWSやGCPから請求書がついてくる。k8sはオープンソースプロジェクトというより、これらの非常に儲かるギャップフィラーサービスへの依存を促す手段になってる気がする。

└

YAMLよりもTerraform/HCLの方が読みやすいと思うのは、目に見えない文字を処理しなくていいからだね。

└

追加したいのは「常識的なデフォルト」だね。これがk3sの好きなところなんだ。

YAMLをHCLに置き換えるのには大反対だね。開発者はHCLをとても混乱してると思う。読みづらいし、今はインポートをサポートしてるの？エラーのデバッグも混乱することがある。protobufや似たようなインターフェース定義言語を使えばいいじゃん。ユーザーが自分が慣れてる言語で設定を指定できるようにすればいいのに。

└

Kubernetesの外からクライアントサイド（例えばkubectl）でHCL、JSON、YAMLなどを簡単に構築してシリアライズ/デシリアライズできるよ。これはKubernetes自体とは全く関係ない話だね。

└

これ知ってるかもしれないけど、Kubernetesのインターフェース定義はすでにprotobufなんだよ（crdを除いて）。

└

混乱してる？俺はインフラ側で、HCL/Terraformを使ってる時に、コードが書けない人向けの赤ちゃん向け設定言語を使ってる気分なんだ。JavaScriptを一日中使ってる人がHCLを混乱するなんて、想像できないな。はっきり言うと、HCLの構文とデータ型について話してるんだ。Terraformの処理方法は、確かに混乱することもあるけどね。でもKubernetesにはそんな落とし穴はないよ。

└

YAMLをHCLに置き換えるのには大反対だな。代わりに価値があると思う。最近、半日でプラットフォーム全体を立ち上げるためのTerraformコードに取り組んでるんだ（AWSサブアカウント、EKSクラスター、Karpenter用のマネージドノードグループ、Karpenterデプロイメント、Ingressコントローラー、LGTMスタック、パブリック/プライベートDNSゾーン、cert-managerなどなど）。Kubernetesリソースも含めて、すべてTerraformでやったよ。HCLでKubernetesリソース（やHelmデプロイメント）を作成するのが良かったのは、型があってスキーマがあるから、LSP（言語サーバープロトコル）に対応したIDEなら、意味のあるオートコンプリートや適切な構文チェックができるってこと。失敗するのを見ないと適用できないなんてことはないし、Emacs（言語サーバー経由）で自分が書いてることが間違ってるって教えてもらえるから、IDEとKubernetes APIリファレンスを行き来する必要がなくて助かるよ。

└

HCLは本当にひどいと思う。K8sのYAMLは全然問題ないよ。今までその型で解決できないユースケースに出会ったことがない。もしやりすぎてるなら、コンフィグマップが間違った選択かもね。

Hacker Newsで議論の続きを見る

ハクソク