Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — インフラは性能ではなく運用負担で交代します
1. rkt
2. dockershim
3. Classic Swarm
4. Docker Machine
5. Compose V1
6. Heapster
7. Apache Mesos
8. PodSecurityPolicy
9. CoreOS Container Linux
10. ingress-nginx
11. TerraformとVagrant — ライセンスが変えた例
まとめ — インフラを交代させるのはたいてい人数です
あわせて読みたい
シリーズ

はじめに — インフラは性能ではなく運用負担で交代します

フロントエンドツールがプラットフォームの吸収で交代するなら、インフラ層は別の理由で交代します。運用負担、標準化、そしてその標準を維持する人の数です。以下の11個はいずれも自分の時代に広く使われ、多くは後続への経路が公式文書に書かれています。公式告知、メンテナーの公開声明、リポジトリのアーカイブ状態のように日付の付いた事実を確認した項目だけを入れました。

1. rkt

何だったのか — CoreOSが作った代替ランタイムです。デーモンなしで実行し、podを一級の単位として扱いました。
なぜ当時は正しかったのか — コンテナ実行が単一ベンダーのデーモンに縛られているという問題意識は正当でした。標準のない市場に標準を要求したプロジェクトです。
何が変わったのか — リポジトリが2020年2月24日にアーカイブされ、READMEはプロジェクトが終了し開発と保守活動がすべて止まったと述べています。
何がその場所に来たのか — containerdとCRI-O、そしてデーモンレス実行モデルはPodmanが引き継ぎました。
何を残したのか — コンテナイメージと実行を標準化せよという圧力です。この圧力がOCI標準につながり、いまはすべてのランタイムがその上にあります。
いまでも使うのが正しい場合 — ありません。アーカイブ済みで後続経路も明確です。

2. dockershim

何だったのか — KubernetesがDocker Engineと通信するために自ら抱えていたアダプタコードです。
なぜ当時は正しかったのか — CRIがなかった頃、Kubernetesが実際に使えるランタイムはDockerだけで、このコードがなければ初期の普及はありませんでした。
何が変わったのか — Kubernetes v1.24で削除されました。公式FAQは、このコードが最初から一時的な解決策として意図されていたと説明し、docker buildで作ったイメージはすべてのCRI実装でそのまま動くと明記しています。
何がその場所に来たのか — containerdやCRI-OなどCRI互換のランタイムです。
何を残したのか — CRIというインターフェースそのものです。アダプタを外すにはまず規約を作る、という順序を示した事例です。
いまでも使うのが正しい場合 — ありません。ただしイメージビルドツールとしてのDockerは何の影響も受けていません。

3. Classic Swarm

何だったのか — 複数のDockerホストを一つに見せていた最初のオーケストレーションプロジェクトです。
なぜ当時は正しかったのか — 既存のDocker APIをそのまま使いながらクラスタへ拡張する設計は、学習コストがほぼありませんでした。
何が変わったのか — リポジトリが2021年2月1日にアーカイブされ、READMEはもはや活発に開発されていないと述べ、Docker Engine内蔵のSwarmモードか他のオーケストレーションシステムを勧めています。
何がその場所に来たのか — Docker Engineに内蔵されたSwarmモード、そしてKubernetesです。
何を残したのか — API互換を保ったまま分散へ拡張するという発想と、オーケストレーションは別の層であるべきだという結論です。
いまでも使うのが正しい場合 — Classic Swarmはありません。Swarmモードは別物でいまも動きます。

4. Docker Machine

何だったのか — 仮想マシンやクラウド上にDockerホストを作り管理するツールです。
なぜ当時は正しかったのか — Linux以外のノートPCでDockerを使うにはVMが必要で、その管理の自動化は実質的な価値でした。
何が変わったのか — リポジトリが2025年7月18日にアーカイブされ、Docker公式の廃止一覧がもはや保守されておらずDocker DesktopかDocker Engineを直接使うよう案内しています。
何がその場所に来たのか — Docker Desktopと、リモートエンドポイントを扱うdocker contextです。
何を残したのか — 複数のDockerエンドポイントを名前で切り替えるという概念が、コンテキスト機能として残りました。
いまでも使うのが正しい場合 — ありません。公式文書が代替経路を指定しています。

5. Compose V1

何だったのか — Pythonで書かれた初期のdocker-composeコマンドです。
なぜ当時は正しかったのか — 複数コンテナをファイル一つで宣言する方式がローカル開発体験を変えました。
何が変わったのか — Dockerが2023年1月31日のブログで2023年6月以降はサポートせず、以後のDocker Desktopからは削除すると述べました。廃止一覧も保守されていないのでV2へ移るよう案内しています。
何がその場所に来たのか — Goで書き直されDocker CLIに統合されたCompose V2、つまりdocker composeです。
何を残したのか — Composeファイル形式です。実装は変わりましたが、人が書く宣言の形はそのまま残りました。
いまでも使うのが正しい場合 — ありません。多くの場合ハイフンを外すだけで動きます。

6. Heapster

何だったのか — Kubernetesクラスタのメトリクスを集めていた初期のコンポーネントです。
なぜ当時は正しかったのか — オートスケーリングに使うCPUとメモリの数値をどこかで集める必要があり、当時は標準APIがありませんでした。
何が変わったのか — リポジトリが2018年12月1日にアーカイブされ、READMEが引退状態であることを明記し変更を行わないと述べています。
何がその場所に来たのか — 同じREADMEがオートスケーリング用にmetrics-serverを、一般的な監視にはPrometheus形式のメトリクス収集ツールを勧めています。
何を残したのか — オートスケーリング用のリソースメトリクスと一般的な監視を分離するという結論です。いまのメトリクスAPI構造はここから来ています。
いまでも使うのが正しい場合 — ありません。アーカイブされて長く経ちます。

7. Apache Mesos

何だったのか — データセンター単位の資源分離と共有を担ったクラスタマネージャーです。
なぜ当時は正しかったのか — Kubernetes以前に数万台規模のクラスタを実際に運用した数少ないシステムであり、オファーベースの二層スケジューリングはいま見ても精緻です。
何が変わったのか — Apache Atticのページによれば2013年6月にトップレベルプロジェクトとなり、2025年8月に引退、2025年10月にAtticへの移管が完了しました。Atticは開発とリリースの権限を持たない読み取り専用の管理組織です。
何がその場所に来たのか — Kubernetesです。同じページはClusterdというコミュニティフォークも案内しています。
何を残したのか — 二層スケジューリングとフレームワークという概念、そしてデータセンターを一つの資源プールとして扱えるという証明です。
いまでも使うのが正しい場合 — すでに運用中のクラスタを維持する場合です。新規導入の根拠は見つけにくいでしょう。

8. PodSecurityPolicy

何だったのか — Podが要求する権限をクラスタ全体で制限したKubernetes内蔵のAPIです。
なぜ当時は正しかったのか — 特権コンテナやホストマウントを防ぐ標準手段が必要で、ポリシーをAPIオブジェクトで表現する方向は正しいものでした。
何が変わったのか — 公式ブログがv1.21で非推奨となりv1.25で削除されたと述べています。同じ記事は、より簡単で持続可能な代替を開発中だと書いていました。
何がその場所に来たのか — Pod Security AdmissionとPod Security Standards、そしてポリシーエンジン系のツールです。
何を残したのか — Podのセキュリティ基準をアドミッション段階で強制するという概念です。代替も同じ位置で同じ仕事をします。
いまでも使うのが正しい場合 — ありません。API自体が存在しません。

9. CoreOS Container Linux

何だったのか — コンテナ実行だけを目的とした最小Linuxディストリビューションで、自動更新と不変ルートファイルシステムが特徴でした。
なぜ当時は正しかったのか — サーバーは直さず丸ごと入れ替えるという運用モデルを、OSのレベルで強制した最初の事例に近いものです。
何が変わったのか — Red Hatの公式ページが、2020年5月26日に最後の更新が配信され、以後に見つかったバグやセキュリティ脆弱性は修正されないと述べています。
何がその場所に来たのか — 同じページがFedora CoreOSを公式の後継として挙げています。
何を残したのか — 不変OSと自動更新、起動時の宣言的プロビジョニングという組み合わせです。いまのコンテナ最適化ディストリビューションの多くがこの形です。
いまでも使うのが正しい場合 — ありません。セキュリティ修正が出ません。

10. ingress-nginx

何だったのか — Kubernetes Ingressを実装する最も広く使われたコントローラーです。
なぜ当時は正しかったのか — 慣れたnginx設定をそのまま使いながらルーティングを付けられ、アノテーションでほぼあらゆる要求を吸収しました。
何が変わったのか — SIG Networkとセキュリティ対応委員会が2025年11月11日の告知で2026年3月の引退を予告し、2026年1月29日の声明で再確認しました。リポジトリは2026年3月24日にアーカイブされました。告知は、数年にわたり一人か二人が余暇に維持してきたこと、任意の設定を許す柔軟性が手に負えない技術的負債になったことを理由に挙げています。
何がその場所に来たのか — Gateway APIの実装群と、文書に整理された他のIngressコントローラーです。
何を残したのか — Ingressコントローラーが何をすべきかについての事実上の基準と、拡張点を無制限に開けばセキュリティ表面も無制限になるという教訓です。
いまでも使うのが正しい場合 — ありません。声明は引退後も使い続ける選択が利用者を攻撃にさらすと警告しています。ただし既存のデプロイは動き続け、インストール資産も残ります。

11. TerraformとVagrant — ライセンスが変えた例

何だったのか — インフラ定義と開発環境プロビジョニングの事実上の標準ツールです。
なぜ当時は正しかったのか — いまも正しいままです。この項目はコードの品質ではなく配布条件が変わった事例です。
何が変わったのか — HashiCorpが2023年8月10日の発表で、以後の製品リリースをMPL 2.0からBUSL 1.1へ変更しました。同じ記事は、競合製品を提供する場合を除けば商用利用も引き続き可能であり、APIやSDKなどはMPL 2.0のまま残ると述べています。
何がその場所に来たのか — TerraformについてはOpenTofuが2024年1月10日に1.6.0として正式リリースされました。Linux Foundationのプロジェクトであり、コミュニティ主導のフォークと自称しています。
何を残したのか — ツール自体はそのままです。残ったのは、依存関係を選ぶときにライセンス条項とその変更可能性も併せて見るべきだという実務感覚です。
いまでも使うのが正しい場合 — ほとんどの利用者です。競合製品を提供する事業でなければ発表文の基準で制約はありません。組織の方針がOSI承認ライセンスを求めるときだけフォークを検討すれば十分です。

まとめ — インフラを交代させるのはたいてい人数です

この一覧で性能が理由だった項目はほとんどありません。dockershimとPodSecurityPolicyは標準化が、Classic SwarmとMesosはエコシステムの集中が、ingress-nginxは保守人員が原因でした。

特に最後の事例は示唆的です。告知によれば、クラウドネイティブ環境の半数ほどが使っていたコンポーネントを一人か二人が余暇に維持していました。依存関係のリスクはコードの品質ではなく、そのコードを維持できる人の数にあります。 これはスター数では見えません。

状態情報は2026-08-12に直接確認しました。プロジェクトは再び活発になることもあるので、最新の状態はご自身で確認してください。