なぜ「動いているOSS」が半年後にメンテ停止するのか
Kubernetesクラスタに何かツールを組み込むとき、多くのエンジニアはまずGitHubを開く。スター数、最終コミット日、Issueの返信速度。これらは確かに参考になる指標だが、実は「このプロジェクトが1年後も生きているか」をほとんど保証しない。
CNCF（Cloud Native Computing Foundation）が管理するプロジェクトは、現在Graduated（卒業）38、Incubating（育成）36を含む数百のプロジェクトで構成されている（CNCF公式プロジェクト一覧、2026年8月時点）。Kubernetesエコシステムで「CNCFプロジェクトだから」という理由だけで採用を決めているなら、それは半分しか情報を見ていない。CNCFのプロジェクトには明確な成熟度ステージがあり、そのステージによって本番投入時に負うリスクの大きさがまったく異なるからだ。
K3sのような軽量Kubernetesディストリビューションを含め、多くのツールは最初「Sandbox」という実験段階からエコシステムに参加する。この段階のプロジェクトを本番のK3sクラスタに組み込むということは、開発チームの都合で方向転換されたり、メンテナが離脱したりするリスクを丸ごと引き受けるということでもある。
Sandbox / Incubating / Graduated — 3段階の違いを「本番投入の可否」で読み解く
CNCFプロジェクトの成熟度ステージは、TOC（Technical Oversight Committee）が継続的にモニタリングする動的なステータスだ。定例会議では卒業プロジェクトの追跡調査や新規レベルアップ申請のデューデリジェンスが常に議題に上がっており、「卒業」は一度取得したら終わりの称号ではない。
CNCF公式のプロジェクトライフサイクル定義を実務者向けに整理すると、確認すべきポイントは大きく3つに絞られる。
- 独立した採用実績: Incubatingへ進むには、TOCの判断で十分な質・規模を備えた独立採用者が複数存在することを文書化する必要がある。1社の内製ツールが外部公開されただけの段階とは重みが違う
- コミッターの組織分散: Graduatedには複数組織にまたがるコミッターが必要とされる。開発企業が買収・撤退・方針転換をしても、他組織が開発を継続できる構造かどうかが問われる
- セキュリティ運用の証明: OpenSSF Best Practices Badge（旧CII Best Practices Badge）の取得有無も判断材料になる。このバッジは脆弱性報告体制・ビルドの再現性・静的解析の実施など、6つのカテゴリにわたる基準を自己申告で証明する仕組みだ
裏を返せば、これらを満たしていないSandbox段階のプロジェクトを本番クラスタに組み込む場合、代替手段への移行やフォークを自分たちで引き受ける前提で採用判断をする必要がある。
Harborはなぜ「卒業済み」を選ばれる理由にできたのか
具体例として、コンテナレジストリのHarborを見てみる。Harborは2018年7月にCNCFへ参加し、同年11月にIncubating、2020年6月にGraduatedへ到達した（CNCF Harborプロジェクトページ）。イメージの脆弱性スキャン・署名・RBAC・レプリケーションといった機能を備え、コンテナレジストリという「本番運用の生命線」を担うコンポーネントとして、卒業ステータスは採用判断の重要な後ろ盾になった。
同様の軌跡は他の主要プロジェクトにも見られる。証明書自動更新のcert-managerは2020年11月にCNCF参加、2022年9月にIncubating、2024年9月にGraduatedへ到達している。GitOpsツールのArgoは2022年12月に卒業し、サービスメッシュのEnvoyもKubernetes・Prometheusに続く3番目の卒業プロジェクトとしてエコシステムに加わった。そもそもKubernetes自身も2018年3月にCNCF初の卒業プロジェクトという地位を得るまでに、明文化されたガバナンス体制と複数組織にまたがるコミッター構成を積み上げてきた歴史がある。
これらの共通点は明確だ。「機能が豊富」だから卒業したのではなく、「複数組織が運用に責任を持つ体制」を築いた結果として卒業ステータスが与えられている。技術選定の場面で見るべきは機能一覧ではなく、この体制の有無なのだ。
K3sベースの本番クラスタで、この選定コストを肩代わりする設計
とはいえ、個々のコンポーネントについてCNCFの成熟度ステージを毎回調べ、コミッターの組織分散まで確認する作業は、決して軽い運用負荷ではない。技術選定のたびにこの調査を一からやり直しているインフラチームは少なくないはずだ。
この選定コストを構成そのものに織り込んでおく、という考え方もある。KuboはK3sベースの本格Kubernetes環境に、Rancher管理基盤・cert-managerによる証明書自動管理・Prometheus + Grafanaによる標準モニタリングをあらかじめ組み込んで提供している。個別のCNCFプロジェクトを一つずつ吟味してスタックを組み上げる代わりに、既に運用実績のあるコンポーネント構成を土台として使えるのは、EKS/AKSのようなフルマネージドK8sと自前構築の中間にある選択肢としての価値だ。
特にセキュリティ要件が厳しい業種でオンプレミス運用が必要な場合は、Kubo On-Premiseのようにデータ主権を保ったまま同じ標準構成を再現できる選択肢も検討に値する。CNCFの成熟度基準を自分たちで毎回調べ直すコストを、構成の選定段階でどれだけ減らせるかは、地味だが運用チームの体力を大きく左右するポイントだ。
もし今、Sandbox段階のプロジェクトを本番導入するかどうかで悩んでいるなら、Kuboの標準構成と比較しながら、本当にそのリスクを引き受ける価値があるか検討してみてほしい。判断に迷う場合はお問い合わせから相談することもできる。
まとめ
CNCFプロジェクトを選ぶとき、GitHubスター数やコミット頻度は入り口の指標にすぎない。本当に確認すべきは、Sandbox・Incubating・Graduatedという成熟度ステージが示す「複数組織による運用継続体制」の有無だ。Harborやcert-manager、Argoのように卒業まで至ったプロジェクトは、機能の豊富さではなく体制の成熟によって本番運用の信頼を勝ち取ってきた。
次にKubernetesクラスタへ新しいOSSを組み込む前に、そのプロジェクトが今どのステージにいるのかを一度確認してほしい。そして、その確認作業自体を毎回繰り返さずに済む基盤として、Kuboのような標準構成を選択肢に入れることも、運用チームの持続可能性を高める一手になる。