Google Cloud、AWS EKSからGKEへの移行をAIが支援するオープンソースエージェント「GKE agentic migration」を発表

概要

Google Cloudは9月24日、AWS EKSからGKEへのクラスター移行を支援するオープンソースのAIエージェントプラグイン「GKE agentic migration」を発表した。手動でのKubernetesマニフェスト書き換えは時間がかかる一方、汎用LLMによる自動変換は廃止済みAPIフィールドの見落としやセキュリティ設定の欠落といったハルシネーションを起こしやすい。GKE agentic migrationは、LLMによる複雑な変換作業と決定論的な検証エンジンを組み合わせることで、この速度と正確性のトレードオフを解消することを狙っている。さらに、生成した変更をライブクラスタへ直接適用するのではなく、GitリポジトリをソースオブトゥルースとしたGitOpsベースのプルリクエストとして提出する仕組みを採用し、既存のCI/CDレビュープロセスの中で安全に移行を進められるようにしている。

移行フローとハイブリッド検証の仕組み

移行はまず、ソースGitリポジトリのクローンやEKSクラスタのスキャンによる深い発見(discovery)から始まり、マニフェストの索引化と依存関係のマッピングを経て、アーキテクチャ上の非互換性を洗い出した評価レポートが生成される。各ブロッカーには解決責任者と目標解決日が割り当てられ、プラットフォームエンジニアが移行範囲を承認したうえで、VPCやサブネット、GKEクラスターなどを定義するTerraformベースのランディングゾーン設計に進む。

続くクラウド翻訳のステップでは、AWS IRSAをWorkload Identityへ、ALBをGateway APIへ、KarpenterのノードクレームをGKEのNode Auto Provisioning(NAP)やCustom Compute Classesへ変換するなど、AWS固有の設定をGKEの対応機能へLLMが変換する。生成された結果はterraform validateやKubernetesマニフェストのスキーマチェックといった決定論的な検証にかけられ、ここで機械的に誤りを排除してからプルリクエストとして提出される仕組みだ。データベースやストレージのデータ転送そのものはプラグインの対象外とし、Google Cloud Database Migration ServiceやStorage Transfer Serviceを使う運用チーム向けのランブック生成に留めている点も特徴で、翻訳作業とデータ転送作業を明確に分離することでリスクを限定している。

マルチペルソナ設計と評価

同ツールはプラットフォームエンジニアとアプリケーション開発者という異なる役割を想定した状態管理も備える。プラットフォームエンジニアがランディングゾーンの設計と移行境界の承認を担い、その状態を永続化した移行状態グラフを介して、アプリ開発者が権限分離されたフォルダの中で個々のワークロードの翻訳を非同期に進められる。専用のCLIバイナリや中央コントロールプレーンを必要とせず、既存の開発環境からGit経由で協調作業できるオープンソース構成になっている点も、大規模かつ複数チームにまたがる移行を想定した設計といえる。

コンサルティング企業Persistentのシュリバスタバ氏(EVP)は、企業のクラウド刷新における最大の障壁は実行リスクと予測不可能性であるとしたうえで、生のチャットプロンプトとは異なり、構造化された状態永続化、プラットフォームとアプリチーム間のペルソナ境界、そして交渉の余地のない人間承認ゲートを組み合わせている点を評価するコメントを寄せている。Google CloudはGKE agentic migrationをGitHub上で公開しており、オンボーディングガイドに沿ってサンプルのEKSリポジトリで試すことができるとしている。