【ITニュース解説】Sunsetting the Kubestack Catalog and Registry: Migrate to Platform Feature Modules

Kubestackは、クラウド上にシステムを構築する際に、特にKubernetesというコンテナ化されたアプリケーションを管理するプラットフォームの環境設定や、その上で動かすアプリケーションのデプロイを自動化し、効率良く進めるためのツールである。開発者は、インフラの設定をコードとして記述する「IaC（Infrastructure as Code）」という手法を用いて、一貫性のあるインフラを構築できる。これまでKubestackは、様々なアプリケーションやサービスのインフラを簡単にデプロイできるように、「カタログモジュール」という既製の部品を提供し、それを「レジストリ」と呼ばれる場所からダウンロードして利用する仕組みを運用してきたが、この提供方法が大きく変更されることになった。

具体的には、これまでの「Kubestackカタログ」と、そこからモジュールをダウンロードするための「kbst.xyzレジストリ」が廃止される。カタログは、オープンソースのソフトウェアやサービスをKubestack向けにパッケージングし、Terraformというツールで利用できるようにしたもので、GitHubのリポジトリで管理されていた。レジストリは、これらのパッケージ化されたモジュールをダウンロードできる場所で、kbst.xyzというURLで提供されていた。今回の変更により、GitHub上のカタログリポジトリとkbst.xyzレジストリは今後一切更新されなくなる。新しいカタログモジュールのバージョンが公開されたり、元のプロジェクト（アップストリーム）の新しいリリースがパッケージングされたりすることはなくなるため、既存のカタログモジュールは最新の状態に保たれなくなる。さらに重要なのは、kbst.xyzレジストリが2026年12月31日をもって完全にシャットダウンされる点だ。この日以降は、kbst.xyzをソースとして指定しているモジュールはダウンロードできなくなり、システムのデプロイや更新ができなくなる。現在使われている既存のモジュールバージョンはそれまでダウンロード可能だが、最終的なシャットダウンに備え、早急な移行が求められる。

自分のシステムが今回の変更の影響を受けるかどうかは、非常に簡単に確認できる。Terraformの構成ファイル（通常は.tfという拡張子を持つファイル）の中に、「kbst.xyz/catalog」という文字列が含まれているかどうかを調べればよい。具体的には、プロジェクトのルートディレクトリで以下のコマンドを実行する。grep -rn "kbst.xyz/catalog" *.tf。このコマンドは、指定された文字列をファイルの中から探し出し、見つかった行とそのファイル名を表示する。もしこのコマンドが何も結果を返さなければ、あなたのシステムはカタログモジュールを利用していないため、今回の変更による影響は受けない。しかし、何らかの結果が表示された場合は、2026年12月31日までにシステムを新しい方式へ移行する計画を立てる必要がある。一時的に古いバージョンをキャッシュしている場合など、猶予があるケースもあるが、新しい機能やセキュリティアップデートが受けられなくなるため、いずれにせよ移行は必須である。

Kubestackは、これまでの「アップストリームプロジェクトを再パッケージしてバージョン管理されたカタログモジュールとして提供する」というアプローチから、「プラットフォーム機能モジュール」という新しいアプローチへと移行する。この新しい方法では、Kubestackがパッケージ化したモジュールを利用するのではなく、ユーザー自身のリポジトリ内に、ごく小さなローカルTerraformモジュールを作成する。このモジュールは、対象となる機能の「アップストリームソース」（例えば、HelmチャートやプレーンなYAMLマニフェストなど）を直接デプロイする。例えば、Helmチャートをhelm templateコマンドでYAML形式に変換し、それをmanifests/upstream.yamlとしてリポジトリにコミットするといった形である。これにより、デプロイされるマニフェストとそれをラップするモジュールは、すべてユーザー自身のリポジトリ内に存在することになる。つまり、システムのインフラ設定の一部として、それらも完全に「所有」することになる。アップデートは、元のプロジェクト（アップストリーム）から直接受け取ることができ、Kubestackによる再パッケージングという中間ステップが不要になるため、より迅速かつ透明性の高い更新が可能になる。また、この新しいモジュールも、以前のカタログモジュールと同じ「kustomizationオーバーレイモジュールタイプ」と「設定継承モデル」を採用しているため、環境ごとの特定の設定（開発環境、本番環境など）をほとんどそのまま引き継ぐことができる。さらに、Kubestackの「スキル」を学習させたAIコーディングエージェントが、この新しいモジュールの作成や管理を支援してくれる。

移行作業は、手動で行う必要はない。Kubestackは、AIコーディングエージェントを活用した移行プロセスを推奨している。まず、もしAIエージェントにKubestackスキルを学習させていない場合は、提供されているURL（https://www.kubestack.com/SKILL.md）を参考に、エージェントにスキルを学習させる必要がある。その後、エージェントに対して「（特定の）カタログモジュールをプラットフォーム機能モジュールに移行してほしい」と指示を出すだけでよい。例えば、「`Migrate the nginx catalog module to a platform feature module」のように指示する。エージェントは、modules/<feature_name>/というディレクトリに新しいローカル機能モジュールと、各クラスターに対応するバインディングファイルを作成してくれる。さらに、既存の環境ごとの設定も自動的に引き継いでくれる。最後に、ユーザーはhelm templateコマンドを実行して、新しいupstream.yaml`ファイルをレンダリングするように指示される。

この移行プロセスは、すでにクラスター上で稼働しているリソースに影響を与えないように設計されている。安全な移行を保証する主な仕組みは二つある。一つ目は、「movedブロック」というTerraformの機能が、各バインディングファイルに自動的に追加されることだ。これがない場合、モジュールのアドレスが変わっただけで、Terraformは既存のリソースを一度破棄し、再作成しようとすることがある。しかし、movedブロックがあることで、Terraformは変更を「その場での移動（in-place move）」として認識し、実際にはリソースを破壊・再作成することなく、Terraformの状態（どこに何のリソースがあるかの記録）だけを更新してくれる。これにより、予期せぬダウンタイムやデータ損失を防ぐことができる。二つ目は、新しいupstream.yamlファイルが、既存のリソースと同じ名前空間と名前を使用するように生成されることである。AIエージェントは、元の設定から名前空間などのアイデンティティに影響する設定をそのまま引き継ぐため、リソースが別の場所にデプロイされたり、意図せず名前が変わったりする心配がない。移行作業は、通常の「GitOps」ワークフローに従って進めることが推奨される。つまり、1つの機能モジュールにつき1つのプルリクエストを作成し、変更を提案する形だ。そして、プルリクエストをマージする前に、必ずTerraformの実行計画（terraform planコマンドで表示される内容）を慎重にレビューする必要がある。計画には、リソースの「破壊（destroy）」と「作成（create）」のペアが含まれていないことを確認し、モジュールの「移動（move）」のみが表示されていることを確認することが重要である。詳細な手順や例は、Kubestackの移行ガイドで確認できる。

現在の時点から、Kubestackカタログは非推奨となり、新しいモジュールバージョンは公開されない。kbst.xyzレジストリは、2026年12月31日までは引き続き利用でき、既存のモジュールバージョンをダウンロードすることは可能である。しかし、この日を過ぎると、レジストリはシャットダウンされ、モジュールソースの解決ができなくなる。したがって、現在カタログモジュールを利用しているユーザーは、この最終期限に間に合うように、今すぐ移行作業を開始することが強く推奨される。1つのモジュールにつき1つのプルリクエストという形で少しずつ移行を進めることで、安全かつスムーズに全モジュールの移行を完了させることができるだろう。もし移行ガイドに記載されていない問題に直面した場合は、GitHub上でディスカッションを開始してサポートを求めることが可能である。