要約

  • containerd は CNCF の卒業プロジェクトであるオープンソースデーモンで、Linux と Windows 上の上位プラットフォーム向けに、イメージコンテンツ、スナップショット、コンテナメタデータ、実行中のタスクを管理する。
  • このプロジェクトは Docker のランタイム再構成から生まれ、2017年に Cloud Native Computing Foundation へ移管された。完全なコンテナプラットフォームではなく、複数の製品が共有するインフラ層となった。
  • Kubernetes は Container Runtime Interface を通じて containerd を利用する。一方、ネットワーク、低レベルの分離、イメージの信頼性、クラスタースケジューリングは別の責任であり、最終的な結果を左右する。
  • containerd 2.3 は2026年4月30日に現行の LTS 系列となった。その後のセキュリティ修正とライフサイクル修正は、クリーンアップ、整合化、パッチ配布もランタイムの正確性を構成することを示している。

プロセスが起動しても、マウントの残存はランタイム障害である

2026年7月10日、containerd はバージョン 2.3.3 を公開した。修正には、サンドボックス状態の検証、NRI の終了処理、フック失敗時にマウントが残る可能性がある処理経路の変更が含まれていた。いずれもコンテナエスケープほど劇的には聞こえない。しかし運用者にとって、消えるべきマウントが残ることは明確なランタイム障害である。ノード群で繰り返されれば、小さな残存物でもホスト資源を消費し、クリーンアップを複雑にし、正常に見えるマシンを退避または再構築が必要な状態に変え得る。

このリリースは、containerd が重要である理由を端的に示している。大半の利用者はデーモンを直接操作しない。Kubernetes にポッドの起動を依頼し、Docker にコンテナの実行を指示し、またはマネージドクラウドサービスからノードを提供してもらう。containerd はその下で要求を受け取り、イメージコンテンツ、ファイルシステムのスナップショット、コンテナ記録、ランタイムシム、実行中のプロセスに関わる状態遷移へ変換する。利用者から見えるプラットフォームは処理を再配置して回復できるかもしれないが、ランタイムはその後もノードを理解可能で再利用できる状態に戻さなければならない。

したがって、プロセスの起動は正確性の一部にすぎない。作成、観測、削除、復旧のすべてが重要である。タスクが素早く起動しても、マウント、古いネットワーク状態、孤立したシム、整合化されていないメタデータを残すなら、運用上は正しくない。障害は、ほかの何百回、何千回もの処理が成功した後にゆっくり現れることもある。

これが containerd を巡る中心的な緊張関係である。このプロジェクトは、多くの製品の下に置かれる共通の中間層となることで成功した。同じ普及度の高さにより、日常的なライフサイクル上の判断が、アプリケーションチームには containerd の名前すら見えない大規模なノード群へ影響する。

containerd はプラットフォームにならないことで有用になった

containerd は組み込み型のランタイムデーモンであり、完全なコンテナ製品ではない。クラスター全体でワークロードをスケジュールせず、アプリケーションサービスモデルを提供せず、企業がソフトウェアをどのように構築して配備すべきかも決定しない。安定した gRPC サービスが提供する機能はより限定的で、イメージコンテンツの転送と保存、メタデータの維持、ファイルシステムスナップショットの準備、コンテナ記録の作成、実行中タスクの管理である。

この境界は意図的なものだ。Docker Engine はその上に利用者向け製品を構築できる。Kubernetes は Container Runtime Interface を通じてノードランタイムとして利用できる。クラウド事業者はノードイメージへ組み込める。Linux ディストリビューションは独自の初期設定やバックポートとともに提供できる。それぞれの上位システムは、基本的なイメージ管理とプロセスライフサイクルの仕組みを再実装せず、異なる運用モデルを提示できる。

この違いは、containerd に同梱されるコマンドctrが誤用されやすい理由も説明する。プロジェクトはこれを、サポート対象の利用者向け契約ではなく、不安定なデバッグおよび開発用インターフェースとして扱っている。ctrの内部動作へ密かに依存する本番ワークフローは、何年も動いた後で、変更の自由を意図的に残した領域の上に構築されていたと気付く可能性がある。

したがって、安定した境界は単なる API 上の判断ではない。ガバナンス上の選択でもある。プロジェクトは文書化されたサービスの互換性を約束しながら、その背後の実装を置き換える余地を維持する。下流製品が同じ境界を尊重する場合に限り、containerd は有用な共有層となる。

Docker は共通のランタイム中核を切り出し、他製品が再利用できるインフラを生み出した

containerd は Docker の内部で始まった。初期の Docker は、イメージ配布、ビルド、API、ネットワーク、プロセスライフサイクルを一つの製品にまとめていた。プラットフォームの成長に伴い、コンテナを準備し監視する継続的な仕組みを、Docker のほかの製品機能から独立して発展させられるよう、ランタイム処理が分離された。

公開リリースの履歴は、2015年12月4日付の 0.0 系列から始まる。2017年3月、Docker は containerd を Cloud Native Computing Foundation に寄贈した。2017年12月5日にはバージョン 1.0 が公開され、安定した gRPC API と本番利用を想定した組み込み契約が確立された。CNCF は2019年2月28日、プロジェクトの卒業を発表した。

この制度上の移行が重要だったのは、Docker が創設者であると同時に商用プラットフォーム企業でもあったためだ。競合するクラウド事業者、Linux ディストリビューター、Kubernetes ベンダーが利用するランタイムは、その上流ガバナンスが一つの製品ベンダーだけに所有されていない方が依存しやすい。Apache License 2.0 も、すべての採用者に同じ事業モデルを要求せず、幅広い商用利用とオープンソース利用を認めている。

財団による運営は、Docker の歴史や、メンテナーを雇用する企業の影響を消したわけではない。共有コードを統治する正式な経路を変えたのである。containerd は、他社が Docker の条件で受け入れなければならない内部部品ではなく、Docker も引き続き利用するインフラとなった。

技術的な結果も同様に重要だった。上位プラットフォームは、オーケストレーションと runc のような低レベルランタイムの間に持続的な層を得た。各製品が独自のイメージストア、スナップショットライフサイクル、プロセス監視モデルを考案する代わりに、複数の製品が同じ仕組みへ収束し、別の領域で競争できるようになった。

イメージ、コンテナ、タスクは意図的に異なる意味を持つ

コンテナに関する用語が分かりにくいのは、利用者向けツールが複数の構成物を一つの言葉にまとめることが多いためだ。containerd はそうしない。イメージはコンテンツとメタデータを指す。コンテナ記録は、意図されたランタイム設定とラベルを保存する。タスクは、その定義から作成された実行中のプロセス群を表す。それぞれは異なる時間軸で存在できる。

タスクの終了後もコンテナ記録を残せる。そのイメージを使ったすべてのコンテナが削除された後も、イメージを残せる。タスクが停止しても、そのコンテナを記述するメタデータが残る場合がある。この分離は、プロセスの寿命を関連するすべての構成物の寿命と同一視する必要がないため、再起動、調査、復旧に役立つ。

一方で、運用上の責任も生じる。一つを削除しても、関連するすべてのファイルシステム、BLOB、シム、ネットワーク資源が回収された証明にはならない。タスクを理解せずにコンテナ数だけを数える監視は、誤解を招く状態を報告し得る。一つの削除で残りも消えると仮定するクリーンアップ処理は、資源を残す可能性がある。

したがって、この構成モデルは実装上の細部ではない。意図された設定、保存されたコンテンツ、実行中の処理は異なる状態であるという基本的な問題に対する、ランタイムの回答である。確実な復旧を求めるシステムには、どの状態が失敗したのかを識別する能力が必要だ。

この違いは、部分的な障害の後に特に重要になる。デーモンの再起動、ノードの資源逼迫、フックエラーなどで処理が途中で中断した場合、復旧経路には、すでに何が行われ、何を削除または再作成する必要があるのかを判断できるだけの永続的な情報が必要になる。

コンテンツアドレス方式が証明するのは到着したバイトであり、そのバイトを信頼すべきかではない

コンテナイメージは変更不能なコンテンツのグラフである。containerd は暗号学的ダイジェストを使って BLOB を保存し、同一コンテンツの再利用とバイト単位の同一性検証を可能にする。イメージ記録は名前とマニフェストをそのコンテンツへ結び付け、転送サービスはレジストリ参照を解決して、必要な BLOB をローカルストアへ移動する。

このモデルは重複を減らし、ノードがどのバイトを受け取ったかを安定して示せる。しかし、誰が公開したのか、その公開者を信頼すべきか、署名を受け入れられるか、既知の脆弱性が含まれるかは証明しない。悪意あるイメージにも完全に有効なダイジェストが付く。変更可能なタグは、個々の BLOB が常に正しくアドレス指定されていても、時間とともに異なるコンテンツを指し得る。

この違いが重要なのは、containerd がより広いサプライチェーンシステムの内部に置かれることが多いためだ。レジストリ認証、署名ポリシー、ソフトウェア部品表、証明書類、脆弱性スキャン、受け入れポリシーは、ほかの構成要素または下流製品が処理する。ランタイムは、完全な信頼基盤にならずにコンテンツの完全性を維持できる。

運用者にとって実務上の原則は単純だ。イメージの識別とイメージへの信頼は別の統制である。障害調査では、実行されたダイジェストと、その実行を許可したポリシーの両方を記録すべきだ。ダイジェストで管理されたストアをセキュリティシステムと呼ぶことは、二つの異なる問いを一つにまとめてしまう。

この分離は移植性にも役立つ。安定したコンテンツモデルにより、異なる上位プラットフォームが同じローカルデータを利用できる。しかし、レジストリの認証情報、信頼ポリシー、プラットフォーム選択の違いにより、あるノード群では使えるイメージが別のノード群では拒否される場合がある。

スナップショッターは変更不能なイメージを稼働用ファイルシステムへ変える

イメージは、実行可能な状態でなくても保存できる。実行中のコンテナには、イメージレイヤーと書き込み可能な状態を組み合わせたファイルシステム表示が必要だ。containerd はこの処理をスナップショッタープラグインへ委ねる。

スナップショッターのインターフェースは、コンテンツ配布とファイルシステム実装を分離する。スナップショッターは、アクティブ、表示用、確定済みのスナップショットを準備し、展開または実行のためにマウントし、後で削除できる。一般的な実装には overlay ベースとネイティブ方式があり、特化型やリモート型のスナップショッターは、ワークロード開始前に取得するデータ量を変えられる。

利点はモジュール性である。ファイルシステム戦略ごとに中核デーモンを書き直す必要がない。クラウド事業者、ストレージベンダー、エッジプラットフォームは、共有サービス境界の背後で起動時間、ディスク使用量、リモートアクセスを最適化できる。

代償として、スナップショットの動作は一様ではない。ガベージコレクション、マウントの意味、容量制限の動作、起動遅延、復旧は実装に依存する。したがって、イメージ取得経路、レジストリ、ディスク、スナップショッターを明示せず、高速なコールドスタートを「containerd」の成果とするベンチマークは不完全である。

2.3.3 のマウント残存修正は、障害側から同じ点を思い起こさせる。フックまたはライフサイクル処理が失敗したとき、ストレージ状態を適切に巻き戻さなければならない。スナップショットやマウントへの参照が誤って残ると、上位プラットフォームがワークロードは削除済みと判断した後もコンテンツがディスクに残り得る。大規模なノード群では、クリーンアップ動作が容量問題になる。

リモート型や遅延取得型のスナップショッターは、このトレードオフを強める。必要に応じてイメージ経路のより多くを利用可能にすることで、起動遅延やローカルディスク使用量を減らせる。一方、完全にローカルにあるイメージとは異なる形で、レジストリまたはリモートストレージの可用性が実行条件になる。抽象化された境界が安定していても、その下の障害モデルは変化する。

runtime v2 シムにより、タスクは作成元デーモンを越えて存続できる

containerd は通常、Linux コンテナのプロセスを自ら実行しない。ランタイムシムを使用して runc などの低レベルランタイムと通信し、低レベルランタイムがホスト OS の機能を使って最終的な作成と実行を行う。

runtime v2 モデルでは、各タスクまたはサンドボックスに、長時間稼働する containerd デーモンとは独立して生存できる仲介プロセスが置かれる。デーモンが再起動しても、実行中のワークロードを必ずしも停止する必要はない。containerd はシムへ再接続し、保存された状態から監視を再構成できる。

これは重要な耐障害性である。ランタイムデーモンへのパッチ適用や再起動が、ノード上のすべてのワークロードを自動的に停止させるとは限らない。また、分離境界を変えるサンドボックス型ランタイムを含め、複数の低レベルランタイムを一つの上位 API の背後で共存させられる。

ただし保証には限界がある。停止または孤立したシム、破損したローカル状態、低レベルランタイムの不具合、ホストカーネルの障害により、監視機能またはワークロード自体が失われる場合がある。ノードの再起動はデーモンの再起動とは異なる。ディスク破損は正常なプロセス再起動とは異なる。この設計は特定の種類の障害を越えた継続性を支えるが、実行をマシンから独立させるものではない。

この階層型ランタイムモデルのため、「コンテナランタイム」という表現は曖昧になり得る。containerd は、長時間稼働するライフサイクルおよび状態管理サービスである。runc などの低レベルランタイムはプロセスを作成する。Kata Containers や gVisor は、containerd を上位の仲介役として残したまま、下位の分離モデルを変更できる。正確な障害原因の特定は、実際にどの層が失敗したかを明示することから始まる。

Kubernetes はクラスター制御を渡さずに containerd へ依存する

Kubernetes は Container Runtime Interface を通じて containerd を利用する。組み込みの CRI プラグインは、kubelet が求めるランタイムサービスとイメージサービスを実装し、ポッドサンドボックスとコンテナを containerd の構成物へ対応付け、設定されたランタイムおよびネットワーク経路と連携する。

これにより containerd は、多くの Kubernetes ノードの直接的な依存先となったが、Kubernetes 自体になったわけではない。ポッドをどこで実行するかは引き続きスケジューラーが選択する。意図されたアプリケーション状態はコントローラーが整合化する。ノード単位の意図は kubelet が管理する。クラスターネットワークとポリシーは CNI 実装やほかの構成要素に依存する。プロセスを分離する基本機能は、ホストカーネルと低レベルランタイムが提供する。

この境界は障害時に重要になる。ポッドが起動しない原因は、kubelet の設定、CRI の互換性、イメージの欠落、スナップショッターエラー、CNI の設定、シム、runc、カーネルのいずれかにある可能性がある。単に「containerd の障害」と報告すると、実際に失敗した受け渡し処理が隠れることがある。すべてのランタイム問題を「Kubernetes」と報告することも同じく不正確だ。

互換性にはバージョンの側面もある。Kubernetes ディストリビューションは、特定の containerd、CRI、設定の組み合わせを検証する。マネージドサービスには、下流パッチや公開が遅れたバージョンが含まれる場合がある。上流リリースが正しくても、クラウドのノードイメージが古いビルドにとどまることがある。クラウド事業者は、上流利用者が想定するようなバージョン変更を行わずに、セキュリティ修正をバックポートすることもある。

このため、実際に確認すべき対象はプロジェクト名だけでなく、ノードの部品表である。containerd、低レベルランタイム、CNI バイナリ、スナップショッター、カーネル、設定、下流パッチを含む。その一式が実際にポッドを起動し削除する。

CNI と NRI は責任をノード構成へ移すことで containerd の範囲を狭く保つ

containerd の設計は、構成要素の組み合わせに大きく依存する。CRI 経路は外部の Container Network Interface プラグインを呼び出し、サンドボックスのネットワークを作成・削除できる。Node Resource Interface プラグインは、ライフサイクルイベントを観測し、許可された資源設定やランタイム設定を調整できる。スナップショッターとランタイムプラグインは、中核 API を書き直さずにストレージおよび実行部分を置き換える。

これによりデーモンは、再利用可能な規模にとどまる。ネットワークの専門家は CNI 実装を発展させられる。ハードウェアベンダーは独自のフォークを維持する代わりに、NRI などの仕組みを利用できる。ストレージ開発者はリモートスナップショッターを追加できる。サンドボックスプロジェクトは代替ランタイムを統合できる。

すべての拡張機能は、障害要因と信頼上の依存関係も追加する。CNI の ADD または DEL が失敗すると、アドレス、インターフェース、名前空間が残る可能性がある。不適切な NRI プラグインはライフサイクル処理を妨げたり、ノード上の割り当てを変更したりし得る。第三者製スナップショッターはマウントを残し、ガベージコレクションを誤処理する可能性がある。あるカーネルでは正しく動くランタイムプラグインが、別のカーネルでは失敗する場合もある。

中核プロジェクトの成熟度が、拡張機能全体へ自動的に引き継がれるわけではない。サポート対象の containerd リリースは、それと組み合わされるすべてのプラグイン、ランタイム、設定を認証しない。運用者は、ノードライフサイクルへ組み込む特権拡張機能ごとに、提供元、バージョン、署名、サポート経路、切り戻し計画を把握する必要がある。

したがって、プラグイン構成は containerd の主要な移植性の仕組みであると同時に、構成上のリスクの主因でもある。プロジェクトは拡張点を用意することでフォークの必要性を減らす。その代わり、本番環境の信頼性は、中核デーモンの評価から推測するのではなく、拡張機能を含めて評価しなければならない。

名前空間は一つのデーモン内でクライアントを整理するが、新たなホスト境界は作らない

containerd の名前空間により、複数のクライアントは一つのデーモン内で資源を分類し、指定できる。Docker、CRI、その他の組み込み利用者は、イメージ、コンテナ、スナップショット、タスクを論理的に分け、一つの平坦な空間で衝突することを避けられる。

これは複数クライアントを扱う上で有用な整理方法である。しかし、二つの利用者を別々のマシンへ分離することとは異なる。デーモンは引き続き特権プロセスであり、管理ソケットは影響の大きいインターフェースである。より強いサンドボックスを使わない限り、通常のコンテナワークロードはホストカーネルによる分離へ依存する。

十分なデーモンアクセス権を持つクライアントは、その権限とプラグインの動作に応じて、名前空間をまたいで情報を列挙したり操作したりできる場合がある。この境界は API の対象範囲を分ける仕組みであり、Unix 権限、ソケット保護、カーネル名前空間、cgroups、強制アクセス制御、仮想マシンによる分離の代替ではない。

この違いは技術面だけでなく商業面でも重要だ。プラットフォームは論理的な分離をうたいながら、複数の顧客を同じ特権ランタイムとホストカーネル上に配置できる。セキュリティ上の根拠は、containerd の名前空間文字列があることから推測するのではなく、ホスト層とサンドボックス層で示さなければならない。

この境界を明確に保つことはプロジェクトにも有益である。スタックの下位層が担う利用者分離まで解決すると装うことなく、整理された管理モデルを提供できる。

デーモンソケットはホスト管理と同じ脅威モデルに含めるべきである

containerd には、プロセス、マウント、名前空間を作成し、影響の大きいランタイム仕様を下位層へ渡す権限がある。多くのシステムでは、デーモンまたはそのソケットを制御することがホストの制御に相当し得る。

このため、ソケットアクセス、外部公開、認証、監査、プラグイン権限が主要なセキュリティ統制となる。デーモンを見えない実装上の細部として扱うと、Kubernetes API は保護していても、実際に特権プロセスを作成するノード内インターフェースへの注意が不足する可能性がある。

同じ注意はランタイム設定にも当てはまる。コンテナは、ホストとの関係を変えるケイパビリティ、デバイス、名前空間、マウントを要求できる。containerd はそれらの仕様を低レベルランタイムとカーネル機能へ渡す。ランタイム層は設定された制限を適用できるが、カーネル脆弱性を解消したり、危険な特権仕様を標準 API の利用だけで安全にしたりすることはできない。

したがって、セキュリティ上の原因特定には複数の層が必要になる。containerd の API 処理にある脆弱性は、runc のエスケープ、カーネルの不具合、安全でない CNI プラグイン、過剰な権限を持つ Kubernetes ワークロードとは異なる。上流の containerd 修正が存在しても、すべての下流ノードが保護されたことにはならない。安全な containerd リリースを使っても、脆弱なカーネルが安全になるわけではない。

2026年6月18日に公開されたバージョン 2.3.2 には、ほかのランタイム修正とともに、記載された五つの containerd CVE に対するパッチが含まれていた。適切な運用上の問いは、最新版が「安全」かどうかではない。どの勧告が配備済み設定に影響し、どのビルドに修正が含まれ、そのビルドが実際の稼働ノードへいつ到達したかである。

イベントとガベージコレクションにより、整合化は継続的な作業になる

長時間稼働するランタイムには、中断された処理から復旧するために十分な状態を記憶しながら、不要になった資源を回収する機能が必要である。containerd のメタデータ、イベント、ガベージコレクションの仕組みは、この作業を支える。

イベントにより、オーケストレーターや監視システムは、すべてを継続的に確認しなくても、ライフサイクルとコンテンツの変化へ対応できる。イベントは整合化と可観測性に役立つが、利用側はイベントストリームを、完全に順序付けられ永続的に保存されるデータベースとして扱うべきではない。再接続処理では現在の状態を問い合わせ、欠落または順序が入れ替わった観測から回復する必要がある。

リース、ラベル、メタデータ参照は、使用中のコンテンツとスナップショットを保護しながら、到達不能な資源を回収できるようにする。この仕組みは、イメージを大量に扱うノード群のディスク増加を抑える。ただし、どちらの方向にも誤動作し得る。残存した参照はデータを無期限に保持し、誤った参照はコンテンツを早期削除の対象にする可能性がある。

したがって、アプリケーションのメモリーと CPU が正常でも、ディスク逼迫はランタイム問題である。イメージ取得、展開済みレイヤー、書き込み可能なスナップショット、古い状態はすべてホストストレージを奪い合う。イメージを取得、展開、削除できないノードは、ホスト自体が停止するより前にスケジューラーから利用不能になる可能性がある。

これも、containerd を削除と復旧を含むノード単位のサービス目標で運用すべき理由である。プラットフォームは、ポッドがどれほど速く起動するかだけでなく、失敗した処理の後もマシンを安全に再利用できる状態が保たれるかを把握する必要がある。

2.3 LTS 系列はリリース管理を運用上の契約に変える

containerd が 2.x 時代へ移行するにつれ、リリース方針はより明確になった。1.6 系列は2022年2月15日に始まり、1.7 LTS 系列が2023年3月10日に続いた。バージョン 2.0 は2024年11月5日に公開され、2.1 と 2.2 は2025年を通じて移行を継続した。

2026年4月30日、プロジェクトは containerd 2.3 を公開し、2028年4月30日までのサポートを予定する現行の長期サポート系列に指定した。さらに、4か月ごとのマイナーリリース周期へ移行し、プラットフォーム区分、API 安定性への期待、サポート対象のアップグレード経路を公開した。

これはリポジトリの整理ではなく、インフラ方針である。クラウド事業者と Kubernetes ディストリビューションは、ブランチがいつまで修正を受けるか、どのアップグレード順序が想定されているか、プロジェクトがどのプラットフォームを継続的に試験できるかを把握する必要がある。LTS 指定により、運用者はコミット状況からサポート期間を推測するのではなく、宣言された期間に基づいてノードイメージの保守を計画できる。

この契約の範囲は意図的に限定されている。安定性の保証は、文書化された API とサポート対象プラットフォームに適用される。ctrは保証の対象外である。第三者製プラグインは自動的には対象にならない。下流ディストリビューションはリリースをバックポート、延期、変更できる。プロジェクト単位のサポート期限から、企業が利用するマネージドクラウド事業者が脆弱なノードイメージをいつ置き換えるかは分からない。

記事の調査基準日である2026年8月6日時点では、2.3.3 が確認済みの最新安定版であり、6月にセキュリティ修正を含む 2.3.2 が先行していた。バージョン 2.4 は2026年8月26日に暫定的に予定されていた。この日付は計画であり、完了済みのリリースではない。記事の公開が基準日より後になる場合は更新すべきである。

このリリースモデルにより、見えにくい依存先を統治しやすくなる。成功は、バックポートの品質、2028年までの 2.3 ブランチの健全性、重要な修正が下流のノード群へ取り込まれるまでの時間に表れる。

プラットフォーム区分は、移植性が継続的な試験能力へ依存する場所を示す

containerd は複数の動作環境をサポートするが、すべてのアーキテクチャが同じように動作するという抽象的な主張ではない。調査基準日時点で、Tier 1 プラットフォームにはlinux/amd64、linux/arm64、windows/amd64が含まれていた。

プラットフォーム区分は、維持されている機能試験とプロジェクトの対応能力を反映する。Windows コンテナは Linux とは異なるホスト機能とランタイム経路を使う。ファイルシステムの意味、プロセス分離、継続的試験の対象範囲も異なる。そのため、共通 API に存在する機能でも、プラットフォーム群ごとに成熟度や障害時の動作が異なり得る。

この区分方針は、一部は技術文書であり、一部は人員・設備に関する文書でもある。プラットフォームが第一級の対象であり続けるには、信頼できる実行環境、ハードウェア、試験、試験失敗へ対応する人員が必要になる。移植性は、互換性の主張を支える継続的なインフラに依存する。

購入者にとって、これには二つの意味がある。第一に、プロジェクト機能は正確なサポート対象プラットフォームとランタイムの組み合わせに対して評価すべきである。第二に、プラットフォーム区分の昇格または降格は、単なる文書変更ではなく、ブランチを保証するプロジェクトの能力変化を示すため重要である。

同じ原則は、特化型ハードウェア統合にも当てはまる。デーモンが汎用的な拡張点を提供しても、特定の GPU、ストレージ、ネットワーク経路の本番品質は、別の場所で保守されるコードと試験へ依存する。

CNCF は中立的な上流を生み出したが、配備された containerd には多くの責任主体がいる

containerd は CNCF プロジェクトとして、メンテナー、コミッター、リリース責任者、ガバナンス記録、セキュリティ対応手順を通じて運営される。一般企業のような取締役会、株主、経営陣は存在しない。権限は株式所有ではなく、プロジェクト内の役割と貢献手続きに基づく。

このモデルにより、競合企業もランタイムを利用できる。クラウド事業者が別のクラウド事業者から containerd を購入する必要はない。Linux ディストリビューターはパッケージ化できる。Docker は組み込める。Kubernetes ベンダーは検証できる。異なる組織に雇用されたメンテナーが、同じ上流コードへ取り組める。

中立的なガバナンスは、雇用主の影響が消えることを意味しない。開発能力の多くは、ベンダーから報酬を受ける人や、ランタイムから利益を得る組織を通じて貢献する人によって提供される。継続的試験、リリース管理、セキュリティ対応には時間とインフラが必要だ。公開ガバナンス記録は正式な役割を示すが、非公式な方針への影響や非公開の商業上の優先事項を完全には測定できない。

配備の制御はさらに分散している。上流メンテナーは公式リリースへ何を含めるかを決める。Linux ディストリビューションは、何をパッケージ化しバックポートするかを決める。クラウド事業者は、どのビルドをノードイメージへ入れ、そのイメージをいつ顧客へ届けるかを決める。クラスター運用者は、稼働ノードをいつ退避し交換するかを決める。そのため、同じプロジェクトでも、実質的に異なる複数の本番ビルドが同時に存在し得る。

この階層化された制御は、障害報告の中心となる。上流のリリース日は、市場全体でパッチ適用が完了した日ではない。クラウドの勧告は、公開バージョン番号が上流と異なっていても、修正済みのノード群を説明する場合がある。信頼できる答えを得る唯一の方法は、正確なビルドと配布経路を追跡することである。

containerd は通常の売上項目を持たずに経済価値を生む

containerd は、損益計算書を公開する独立した製品企業ではない。提供された証拠には、containerd の売上、企業評価額、監査済み配備数は存在しない。CNCF がプロジェクトを運営し、雇用主が人材の作業時間を通じて開発の多くを支え、下流企業がランタイムを組み込んだ製品とサービスから収益を得ている。

その経済価値は主に、重複開発の回避として現れる。Docker、Kubernetes ベンダー、クラウド、ディストリビューションは、それぞれが完全に別のデーモンへ資金を投じる代わりに、イメージ処理とライフサイクルの仕組みを共有できる。一つの不具合修正を複数の製品へ広げられる。安定した API は、長期間にわたる統合保守の費用を下げられる。

公共財としての構造は、持続可能性の問題も生む。多くの企業は、依存度に見合う開発貢献をしなくても containerd を利用できる。LTS ブランチには、新しいリリースへの関心がほかへ移った後も、リリース責任者、継続的試験、バックポート作業、セキュリティ対応が必要だ。プラットフォーム固有の試験には、ハードウェアとメンテナーが必要になる。組み込み型であることはプロジェクトの価値を高める一方、直接的な予算を見えにくくする。

したがって、2.3 LTS への取り組みには、公開予算がなくても財務的な側面がある。2年間のブランチ維持には継続的な労働が必要だ。その健全性は、架空のプロジェクト売上ではなく、リリース責任の分担、パッチ公開の頻度、試験範囲、貢献者の多様性によって判断すべきである。

完全な配備状況の調査も存在しない。Docker、Kubernetes、クラウド製品で広く利用されていることはプロジェクトの役割から明らかだが、正確な市場占有率を主張できる証拠にはならない。最も確実な表現は、containerd が広く組み込まれ重要な影響を持つというものであり、世界のコンテナの既知の割合を実行しているというものではない。

代替製品は、境界を明示して初めて containerd と比較できる

コンテナランタイムの比較では、異なる層で動作する製品が混同されることが多い。CRI-O は Kubernetes 向け CRI 配備における直接的な代替である。Docker Engine は containerd を組み込む、より広範な利用者向けプラットフォームであり、同じ範囲のすべての層を置き換えるものではない。Podman と libpod の一式は、異なる利用者モデルとデーモンモデルを採用する。runc は低レベルの OCI ランタイムで、containerd と競合するのではなく、その下で使われることが多い。

Kata Containers と gVisor は、ライフサイクルの仲介役より下にある分離モデルを変える。containerd が上位のイメージサービスとタスクサービスを担当したまま、ランタイム統合を通じて動作できる。Kubernetes 自体はノードランタイムより上のオーケストレーターである。Open Container Initiative はコンテナを運用するのではなく、この技術構成で使われる仕様を定義する。

これらの違いが重要なのは、一つの構成要素を切り替えても、すべての依存関係がなくなるわけではないためだ。containerd から別の CRI ランタイムへ移行すると、ノードイメージ、互換性試験、スナップショットストレージ、ランタイム設定、運用ツールに影響する。runc から仮想マシン型サンドボックスへの移行は別の境界を変える。Docker Engine を置き換えても、結果として構築される仕組みに containerd が残る場合がある。

したがって、最も有用なのは機能単位の比較である。どの層を置き換えるのか。どの状態を移動する必要があるのか。どの運用ツールが古い API や構成モデルを前提にしているのか。どの障害モデルが変わるのか。一般化された「ランタイム市場」という表現は、説明する以上に多くを隠してしまう。

containerd の利点は、代替が存在しないことではない。多くの製品が、その安定した中間層を中心に統合コード、運用知識、試験を蓄積してきたことである。ソフトウェアライセンスによる法的な囲い込みがなくても、蓄積された知識は移行費用を生む。

真の移植性試験は、処理が途中で止まったときに始まる

containerd の設計は、責任を有効に分離する考え方に基づいている。デーモンは永続的なランタイム状態とサービスを管理する。スナップショッターはファイルシステムを準備する。シムは実行中タスクを仲介する。低レベルランタイムはプロセスを作成する。CNI はネットワークを設定する。Kubernetes などの上位システムは何を実行すべきかを決める。カーネルは実際の分離機能を提供する。

この分業により、プロジェクトは再利用できるほど小さく保たれる。一方、単一の構成要素だけで結果全体を保証することはできない。コンテナは、イメージを解決できない、スナップショッターがマウントできない、CNI がクリーンアップできない、シムが消えた、ランタイムが仕様を拒否した、カーネルが処理を拒んだといった理由で失敗し得る。

したがって、成熟したノードランタイムは障害を理解可能にしなければならない。運用者は、処理が停止する前にどの状態が変化したか、どの資源が残っているか、再試行が安全か、ノードを再構築せずサービスへ戻せるかを把握する必要がある。エラー処理、タスク状態、イベント、クリーンアップ、復旧は、正常時の起動と同じくらい重要である。

これが containerd の長期的な成果を理解する最良の方法である。完全なコンテナプラットフォームへ変わることなく、共有可能な中間層を実現した。この共有基盤が、組み込みに十分な安定性、調査に十分な透明性、普及の大きさを理由に隠れた運用上の負債を受け入れずに済む置換可能性を維持する限り、プロジェクトは価値を保ち続ける。