- Kubernetes は過去10年間、コンテナオーケストレーションの革新を主導してきた
- 現行の YAML 構成、etcd 依存、Helm によるパッケージ管理 にはさまざまな限界があり、改善の必要性が見られる
- HCL の導入、プラグイン型ストレージ、新しいパッケージマネージャー (KubePkg)、IPv6 のデフォルト化 などが Kubernetes 2.0 の変化要素として議論されている
- 現在のオープンな構造も重要だが、デフォルト設定と公式な方向性の提示がエコシステムの革新に決定的な影響を与える
- Kubernetes は 継続的で破壊的な改善 を通じて、より広いユーザーと組織に適したものになる必要があることが確認される
Kubernetes の10年: 成功と限界
始まりと成長
- 2012〜2013年、Google 社内の Linux コンテナシステム Borg に関するうわさが sysadmin コミュニティに広まり始めた
- 2014年に Kubernetes が公開され、当初は発音すら難しい名前だった
- Microsoft、RedHat、IBM、Docker など主要企業がすぐに加わり、Kubernetes はエコシステムの標準として定着し始めた
- 2015年の v1.0 公開と CNCF 発足により、本格的なオープンエコシステムが形成された
主な革新ポイント
コンテナの大規模管理
- Kubernetes は コンテナベースのソフトウェア開発とデプロイ にスケーラビリティをもたらした
- 単純な開発環境から数千台のサーバーに至るまで、大規模な同一環境デプロイ を可能にした
- 組織は モノリシック構造 から分散型 マイクロサービス へ移行するきっかけを得られた
低コストな保守と自己修復
- サーバー管理は "Simpsons"（各サーバーに愛称を付けて手作業で運用）時代から、"UUID"（完全置換、自動化、ステートレス）時代へと急速に変化した
- マシン寿命、OS サポート期間 という概念はほぼ消え、障害時には「ノード再生成」によって自動で再構成される
- 多くの Linux スキルは、今や必須条件ではなく「あれば望ましい」レベルへと変化した
バッチ処理と Job 管理
- かつて「cron 専用ボックス」に依存していた バッチ処理 は、キューベースの自動化タスクと 再試行 の仕組みに置き換えられた
- ジョブ失敗時の自動再起動と柔軟な処理によって、運用効率 と開発者満足度が大きく向上した
サービスディスカバリとロードバランシング
- IP アドレスのハードコーディングの代わりに、内部 DNS ベースのサービス命名体系 を導入した
- API、固定 IP、ホスト名 によってサービス間接続を単純化し、外部サービスも内部と同じように扱えるようにした
Kubernetes 2.0: 主要改善案
YAML から HCL へ、構成言語の置き換え
YAML の限界
- YAML は見やすく、JSON や XML より優れて見えるが、エラーを誘発しやすい、型をサポートしない、デバッグが難しい など深刻な問題がある
- 例) ノルウェー問題（
NO が false と解釈される）、インデントエラー、文字列と数値の混同など、数多くの障害要因を内包している
代替案: HCL 採用
- HCL(HashiCorp Configuration Language) は Terraform の標準フォーマットで、強い型付け、検証、関数、条件分岐 など優れた機能を提供する
- すでに相当数の Kubernetes クラスターが Terraform とともに HCL を活用している
- HCL は型安全性、重複削減、動的設定、反復処理、条件ロジック、優れたコメント対応、モジュール性、有効性検証など、YAML より強力な機能を備える
- オープンソースライセンスの問題（MPL 2.0 → Apache 2.0 との互換性）は残るが、品質向上のための価値は十分にある
例: HCL vs YAML
- 型、変数、関数、条件文、ループ文といった HCL の利点により、構成ミスの予防、保守性向上、複雑な環境でも一貫性の確保が可能になる
etcd 代替オプションのサポート
- etcd は強力だが、小規模クラスターや低スペック環境では過剰なリソース消費が発生する
- Kine などのプラグイン型バックエンドを公式にサポートすることで、デフォルトストレージの柔軟性 を広げる必要性が提起されている
- 例) k8s-dqlite: 分散 SQLite+Raft により軽量で柔軟なデータ層を提供
Helm を超えて: ネイティブパッケージマネージャー
Helm の限界
- Helm は一時的なハック的解決策が標準になった例であり、テンプレートの複雑さ、デバッグの難しさ、依存関係やバージョン競合、検証不足など多くの問題がある
- 複数チャートの重複、バージョン不一致、ネームスペースをまたぐインストールの難しさ、チャート検索やメタデータの欠如、セマンティックバージョン非準拠、安全でない CRD 管理など、実運用で多くの困難が発生している
新しいパッケージシステムの提案: KubePkg
- Kubernetes リソースの形 で、パッケージ、依存関係、セマンティックバージョン、セキュリティ、ライフサイクル、メタデータまで包括的に管理する
- 高度なライフサイクル Hook、状態およびバックアップ/リストア戦略、宣言的構成、検証可能な署名プロセス、監査記録、組織ポリシー制御などを完備する
- Linux パッケージマネージャーの利点 を継承し、実際のインフラ管理で強い信頼性と一貫性を提供することを目指す
主な要件
- 完全な Kubernetes ネイティブリソース構造
- ステートフルアプリケーションの組み込みサポート
- 署名/検証/セキュリティスキャンのプロセス強化
- 構造化された宣言的構成 + スキーマ検証
- ライフサイクル全体の制御と簡単な Upgrade/Hook サポート
- Linux スタイルの依存関係/バージョン解決
- 変更履歴と監査追跡
- 組織ごとのポリシー適用可能性
- 親しみやすい Linux パッケージ管理 UX の提供
IPv6 のデフォルト化
- 現在 IPv6 と dualstack はサポートされているが、デフォルトは依然として IPv4 である
- クラスター間通信、NAT の問題、IP 不足 を解決し、単純なネットワーク構造、組み込み IPSec などの利点がある
- 大量の IP を必要とする環境（例: /20 帯域、ノード40台、1ノードあたり30個の pod）では、IPv4 の限界にすぐ突き当たる
- パブリック IPv6 環境での運用簡素化、クラウド利用者の確保、プライベート領域管理の負担軽減など、実用的な利点は明確だ
結論: 変化の必要性とデフォルトの力
- 「オープンプラットフォームなのだからコミュニティが何とかする」という意見もあるが、デフォルト設定 が業界の行動様式を主導する
- Kubernetes 2.0 には、公式な信念、優れた設計、強力なデフォルト が必要な時期に来ている
- 業界標準であり、グローバルなデータセンター運用の主流という地位にふさわしい 新鮮な飛躍 が重要な時期だ
- すでにモバイル、Web などさまざまな技術分野で、大胆な変化 によるエコシステム全体の革新が繰り返し起きている
- Kubernetes も今や、記念碑的な 2.0 を通じて次の段階を考える時期に来ている
2件のコメント
オープンソースを組み合わせて作られたバニラk8sを構成・運用できるエンジニアは、今後も少数のままだと思います。
HadoopクラスターをClouderaプラットフォームとしてまとめて購入するのではなく、バニラのHadoopエコシステムを運用できたエンジニアがごく少数だったのと同じように。
Hacker Newsの意見
Kubernetesの最大の問題は、「とにかく普通に動く」システムではないことだと思う。実際、本番環境で無理なくサービス運用できるエンジニアはごく少数で、VM上に直接Kubernetesクラスターを構築して維持するのはなおさら難しい。だから最近伸びているサーバーレス系スタートアップは、(1) 時間を食い、(2) 非常にエラーが多く、(3) 本番環境で失敗する確率が高い、という認識が広がっているからだ。Kubernetes 2.0では、誰でも簡単にデプロイ基盤をセルフホストし、自信を持って使えること、そして小さく強力なオーケストレーターのコアを維持する方向を考えるべきだと思う。自分でも Rivet というオーケストレーター兼デプロイ基盤を開発しており、Rivet オープンソースサーバーレスプラットフォーム だと打ち出しているが、自分でも「Kubernetes 2.0とは何だろう？」とよく考える。人々が予想以上のシナリオでRivetを導入するケースも増えている。Rivetの最大の強みは、Kubernetes controller級の機能を簡単に開発できる点で、これによってゲームサーバー、テナントごとのデプロイ、高度なワークロードオーケストレーション、マルチテナンシー、テナント別課金、強力なオペレーター設計など、さまざまなシナリオに活用できる。
この見方にはかなり反感を覚える。年も取って少しシニカルになっているせいか、よく見るパターンだ。Xという技術は重すぎるから「自分はこれ抜きでノートPCで簡単に動かしたい」という人がY技術を作る。するとYも人気が出て、実際にノートPC以外で動かす段になるとスケーラビリティが必要になり、いろいろな機能が追加されて重くなる。すると誰かが「今度はYが重すぎる」と同じことを言い出す。まるで『時の車輪』のように、始まりも終わりもない繰り返しだ。
実際のところ、k3s（軽量k8s）は本当に管理が楽だ。k3sの自動更新と適切なevictionルールさえあれば、ほとんど手を入れる必要はないし、Cephのようなストレージが難しいなら、LemonやLonghornのような「管理ゼロ型」の代替を選べる。何千ものHelmチャートがあるので、複雑なデータベースでも1分でそのままデプロイできる。サービスのデプロイも、よく使われるHelmテンプレートだけ使えばとても簡単だ。Helmは完璧ではないが、好みに合わせて整えれば値の補完機能なども使える。サーバーレスより参入障壁は少し高いが、1週間ほど学んで実運用で数千万円を節約できるなら、十分価値がある。
Kubernetesが解決する問題は「これをどうやってデプロイするか？」だ。RivetのDocsを見ると、シングルコンテナ、Docker Compose、手動デプロイ（Dockerコマンド）しかない。現実的に、サーバーレスインフラを実際の規模でこんな形でデプロイできるのか疑問だ。最初の疑問は「この段階なら、RivetをKubernetes上で（コンテナ、kube-virtなどで）動かせないのか？」ということだ。Docker ComposeがKubernetesより堅牢だったりスケーラブルだったりするとは思えない。そうでなくクラウドサービスを売るのなら、それはKubernetes 2.0というコンセプトにも合わない。もしRivetを自前ホスティングするなら、ドキュメントを書き換えてKubernetes上で動かせるようにすると思う。
クラスター管理をクラウドベンダーにアウトソースした「サービスとしてのk8s」を使っているなら、何がそんなに複雑に感じられるのか気になる。設定の幅は広いが、実際に本番へ出すサービス構成で必要になる設定はごく一部だ。Docker Composeより少し複雑なくらいの設定で、十分k8sにデプロイできる。ただ、大半のアプリにとってはその「少し余分」ですら不要かもしれない。実際、Docker Composeこそ大衆的なニーズに合っていたのに、継続的な関心を得られなかったのは残念だ。
インフラ運用で「ただ動く」ものは絶対に生まれない、というのが自分の経験だ。Herokuでさえスケールすると問題が出る。誰でも簡単に採用できるデプロイ基盤が欲しいなら、Kubernetesを特定のPaaSの基盤プリミティブとして理解する方が現実的だ。Rivetは独特だし、BEAMエコシステムのいくつかのアイデアも見えて興味深い。個人的には大規模デプロイより、堅牢さとローカルファーストの方に関心がある。
「Low maintenance」か……。EKS（マネージドk8s）をかなり使っているが、クラスターの状態自体は直接気にする必要がない（もちろん自分がノードを壊す奇抜な方法は別として）。Kubernetesは本当に「できるだけ保守不要」であるかのように振る舞うが、実際には純粋なメンテナンスの塊だ。yamlを差し出すだけでソフトウェアを世に即座にデプロイできる点は本当にすごい。だが、その代償が複雑な運用保守だ。クラスター設定、ArgoCDの初期化、ハブ&スポークモデルで別クラスターを登録することなどは、単なるサーカスの一幕にすぎない。そのうえで CNCF Landscape tooling にある使えそうなオペレーターの導入や、補助ツール群（物理的には一次ではないが必須）を最低30個くらい動かすことになる。
values.yamlの設定も1〜2時間では済まず、ほとんどはArgoCDとテンプレート作業だ。Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> Anothervalues.yamlのように、boolean値を1つ渡すだけでも時間を食うことが多い。クラスターやオペレーターの更新周期も速く、常に保守課題がつきまとう。Karpenterでオートスケールするときは、ノード置き換えと無停止運用がまた別の綱渡りになる（状態を持つアプリはk8s上だと面白さが倍増する）。要するに、本当の「Low maintenance」は皮肉表現だ。「Low Maintenance」は結局、代替案との相対的な概念だ。自分の経験では、k8sを使ったときの方が、スケーリング、フェイルオーバー、ロールバック、災害復旧、DevOps、独立クラスターのスピンアップなど全般で、同じ品質のサービスを得るための保守負担はずっと低かった。状況次第では違うかもしれないが、自分にとってはそうだった。
自分はここ2年、hetznerでk3sを使ってきて、100%の稼働率を経験している。保守負担があまりに低くて、マスターノードのSSHキーを失くしたことすらあったが、クラスター全体を再プロビジョニングするのに、ドキュメント更新まで含めて90分しかかからなかった。本当に急いでいれば15分で十分だったはずだ。月20ユーロで、ARMベースの3ノード＋1マスター、少しのストレージ、自動DNSまでCloudflareと連携させてk8sクラスターを運用している。
でも実際に管理しているのはKubernetesそのものではなく、CI/CDシステム、シークレット管理システム、データベース運用自動化のような周辺システムだ。昔ならyamlの代わりにcron job、ansible、systemd、bashスクリプトなどでやっていたはずだ。
自分の手でサーカス小屋を建てたようなものだ。そんなに多くのものを入れるべきではない。何かを追加するたびに技術的負債と保守コストが増える。無料ツールでも同じだ。オートスケールが節約より負債や維持費の方が大きいなら、単に切ってしまった方がいい。
同じようなサービス群を個別に組んで運用していたら、保守負担はずっと大きい。だがKubernetesは、火がついたあと放置できるくらい管理が楽だ。ただし、自分が何をしているのか分かっていないと、「格好よさそうなツール」を入れたくなる誘惑に負けてしまう。
K8Sはyamlの強制でもない。idiomaticではあるかもしれないが、必須ではない。kubectl applyは最初からjsonもサポートしていたし、endpointもjsonとgrpcだ。jsonnetのようなさまざまな言語から設定を生成できる。次に、Helmチャートでdependencyやdependency orderingがなぜ問題になるのか気になる。Kubernetesの主なイディオムはループにある。依存関係がなければアプリはrecoverable errorとして扱い、可能になるまで繰り返し試す。あるいはクラッシュして、ReplicaSetコントローラーが自動再起動する。チャートに依存関係がなければ依存衝突もない。本当に依存するアプリなら、Helmチャート内に依存アプリやサービスを一緒に含めるのが正しい。
（主要意見の引用） > crashしたときにReplicaSetコントローラーがアプリを再起動してくれるだけでは不十分だ。たとえばkeycloakの起動に1分かかるとすると、それに依存するサービスはkeycloakなしで即座にクラッシュし、再試行しているうちにthrottleがかかって、keycloak起動後も5〜10分無駄に待つことになる。依存関係が明確なら、mainコンテナに渡す前にinitコンテナで依存サービスをチェックしてから進む方が適切だ。Kubernetesに明示的な起動依存関係宣言機能があればいいと思う。クラッシュして何度か再試行したあとthrottleをかけるのが答えではない。依存関係はただ存在する現実だ。
依存関係の失敗は必ずrecoverableであるべきだと思う。以前、実際には使ってもいないdependencyのためにfail-closed動作になって障害になったことがある。サーバー間の依存関係はほとんどがsoft dependencyだ。downstream dependencyが使えないなら単に500を返せばいいし、ロードバランサーがunhealthyなサーバーを避ければいい。
「supposed to」と言うけれど、それがうまく当てはまるのはin-houseソフトウェアスタックを構築するケースだけだ。すでに出来上がった古いソフトウェアがdockerしかサポートしていなかったのに、あとからkubernetesで動くようになった例も多い。開発者が自分の哲学どおりにツールを作っても、人は結局やりたい使い方をして、ひどい結果になることもある。結局、人にはさまざまな機能と選択肢を与える必要があり、市場は望むように使う。
「yamlではなくjsonも使える」という事実でこの件を批判するのは論点ではない。誰も本当にそこを気にしていない。どうでもいい揚げ足取りだと思う。
yamlの代わりにHCLへ置き換えようという意見には強く反対する。HCLは開発者にとって見づらく、読みにくい。importのサポート有無やデバッグの難しさなど、usabilityの面でも不満が多い。なぜprotobufのようなインターフェース定義言語を中心に据えて、ユーザーの好みで表現だけ変換できるようにしなかったのか理解できない。
HCLは最悪だ。k8s yamlだけで足りなかったことはない。もし設定が複雑すぎるなら、config mapよりアプリ設計そのものの問題に近い。
実際のところ、HCLでもJSONでもYAMLでも、クライアント側でシリアライズ/デシリアライズすれば済む話だ。つまりこれはKubernetes自体の問題ではなく、単なる外部変換レイヤーにすぎない。
Kubernetesのインターフェース定義は、例外としてcrdを除けば、すでにprotobufベースだ。
自分のHCLに対する主な不満はfor loop構文だ。本当に最悪だ。
「HCLは開発者にとって難しく、lintやデバッグも難しい」という話は、新しいものを学びたくないという話に近く聞こえる。複雑なドメインとHCLを学ぶことを混同して生じた問題に見える。
「Kubernetes 2.0」スタイルで nebulousプロジェクト を開発中だ（まだpre-alpha段階）。目標は、全世界に分散しつつ軽量で、ノートPC上ではシングルバイナリとして動作し、クラウドでは数千ノードまで拡張でき、Tailnetネットワーク、BitTorrentストレージ、マルチテナンシー、ライブマイグレーションなどを備えること。要件の多くはML運用（特にGPU不足）から生まれたもので、今後MLが当たり前の時代になれば、これが標準になるかもしれない。
ライブマイグレーションは面白い。自分たちは今、複数クラスターや複数クラウド間でオートスケーリングを使った価格戦略を取っているが、ライブマイグレーションはまた別次元の挑戦だ。
これはKubernetesではなく、GPU運用に特化した別システムだ。
「グローバル分散」はむしろ非要件かもしれない。Tailnetを標準ネットワークにするなら、真っ先に外したい機能だ。KubernetesがシングルNIC前提なのは、クラウド向けの窮屈な遺産だ（複数CNIや、最近のMultusのようなプロジェクトはうれしい。参考: redhatブログ）。マルチテナント設計がk8sと実質的にどう違うのか気になる。BitTorrentでストレージをやるなら、パブリックなコンテナイメージまで共有した場合、egressトラフィック料金が莫大になる。
GitHubを見るとChart.yamlがあり、しかも
provider_aws.yamlのようなテンプレートまで見えるが、あれは本当にやらないでほしいコードパターンだ。Kubernetesは今でも本当に複雑だと感じる。普及したことでそう見えにくくなっているだけだ。Kubernetes 2.0では、ユーザー体験、とくによくやる運用作業（アプリのデプロイ、サービス公開、サービスアカウント/イメージ変更など）がもっと簡素化されるといいと思う。ただ、今の主流はLLMなので、後続の開発は難しそうだ。
Kubernetesは抽象化レイヤーが多すぎる。podsはすばらしい中核概念だが、deployment、replica set、namespaceなどが追加されるにつれ、Docker Swarmくらいシンプルならと思ってしまう。Terraformも単一レイヤーで学びやすかった。k8sの学習曲線が本当に急だと実感している。
「コンピュータプログラムの型区分は人間の認識の結果だ」と感じさせる話だ。オペレーター/コントローラーは、昔のCOM/CORBAのように抽象化されすぎている（長所でもあり短所でもある）。単純な実装には、もっと制約の強いk8s-liteの方がむしろ向いている気がする。一方で、複雑な環境では逆に既存のk8sの抽象化でも足りないことが多い。1つのシステム（Kubernetes 2.0でも何でも）が、現実の問題すべてを包み込んだまま、人間の開発者や設計者に扱えるのか疑問だ。
「sane default」、つまり特に選ばなくてもデフォルト状態がそこそこ十分（ネットワーク/ストレージ/ロードバランサーなど）なシステムが欲しい。yamlもHCLも好きではない。もっと良い設定方法が必要で、言語を変えるだけでは解決しないと思う。IPv6は必須だと思う。Docker、コンテナ、Kubernetesは、内部的にはIPv6-onlyであるべきだったし、IPv4はingress controllerで例外対応するのが正しい。
「Sane defaults」と「マネージドサービス顧客への転換」の間には本質的な葛藤がある。K8sを長く見ているほど、ストレージやネットワークなど「batteries not included」の思想が強くなり、それをAWS/GCPなどが高価な統合サービスとして売る傾向が濃くなる。現実のK8sは、もはやオープンソースというより、クラウドのギャップを埋めるための販売促進ツールとして使われている面すらある。
（個人的経験）Terraform/HCLがYAMLより良い点は、見えない文字に依存しないので読みやすいことだ。
「sane defaults」があるからこそ、k3sの方がずっと好きだ。
2.0リリースとしては、やや控えめなウィッシュリストだと思う。自分の周りでは、みんな本番k8sの複雑さにかなり不満を持っている。後方互換性とシンプルさをどう同時に実現するかが本当の核心だ。普通は後方互換性のせいで複雑性が爆発する（新システムが新旧両方の機能を全部背負い込むことになる）。
自分はすでにTerraformでクラスターとアプリを管理していて、「Kubernetes 2.0の世界」に生きている感覚がある。
tf apply一発でクラスター、ノード、クラウド連携（S3など）、クラスター内サービスまで一気に構成できるフロントエンド出身としては、Kubernetesはかなり直感的だと感じた。以前はデータを入力してUIをリアクティブに作っていたが、今は制御プレーンにリソースと設定を合わせ込むコードを書いている感覚だ。