從 EKS 搬到 GKE，Google 想讓 AI 產出的設定先過審

企業把工作負載從 Amazon EKS 搬到 Google Kubernetes Engine（GKE），最怕的不是 AI 寫不出設定檔，而是設定檔看似正確，上線後權限、流量或容量卻變了。Google 於 2026 年 9 月 24 日宣布開源 GKE 遷移代理，主張以大型語言模型（LLM）處理推理工作，再由確定性工具與防護機制約束產出，而非讓工程師只靠零散的提示詞取得替代設定。2

遷移要保留的是行為，不只是欄位

EKS 與 GKE 都使用 Kubernetes，但遷移不能簡化成替設定檔改名。基礎設施即程式碼及 Kubernetes 資源設定轉換後，團隊仍須確認工作負載能存取哪些資源、請求會被送往哪裡，以及節點是否提供足夠容量。Google 的容器遷移指引也把盤點工作負載及其相依性列為前期工作。19

對這類遷移，至少有三組值得逐項核對的問題：

• **身分與權限：**AWS 的身分設定轉為 GKE 的 Workload Identity 後，工作負載能否取得原本需要的權限，又不會被賦予過多存取權？
• **對外流量：**負載平衡器的入口設定改用 Gateway API 後，請求是否仍依預期規則到達正確服務？
• **節點配置：**節點供應方式改變後，工作負載是否仍能如預期排程，並取得所需容量？

這些是遷移流程中應審查的對應關係，不是已經證實工具能正確處理所有情況的保證。Google 公告確認了 LLM 推理與確定性工具的組合，但現有公告摘錄沒有逐一說明外掛的操作與轉換規則。2

讓 AI 提案接受檢查，而不是直接當成部署指令

模型情境協定（Model Context Protocol，MCP）可讓代理透過共同介面使用工具，但介面本身不會證明轉換結果正確。確定性的離線檢查則能讓同一批產出檔案接受可重複的規則驗證；它能發現什麼，取決於規則實際涵蓋什麼，無法單憑檢查結果保證切換後的應用程式行為完全相同。Google 稱這項工具設有確定性防護機制，但現有公告摘錄未列出離線驗證的完整範圍。2

另一道關卡是程式碼審查。依所描述的遷移流程，產出變更可先形成拉取請求（pull request，PR），交由工程師檢視差異，再透過既有的持續整合與持續部署（CI/CD）流程執行測試、政策檢查及核准，而非直接修改運作中的叢集。這與 Google 對 GKE 部署使用版本控制及 CI/CD 的一般建議相符；不過，現有公告摘錄並未獨立證實這項工具的每一步 PR 操作。172

Google 公告引用 Persistent 高階主管 Rahul Shrivastava 的說法，將這種做法稱為「可證明、編譯器等級的遷移工廠」。這個比喻有助於理解其產生、檢查與審核遷移產物的思路，卻不等於整場遷移已獲數學證明安全。權限、效能、相依服務及正式切換後的運作，仍須測試。2

與 Intrinsic Core 的共同點：降低採用門檻

在 GKE 公告前兩天，Intrinsic 於多倫多的 ROSCon 2026 發表開源的 Intrinsic Core。它提供相容於機器人作業系統 ROS 的控制、動作與抓取規劃、模擬及姿態估計等能力；報導指出其採用 Apache 2.0 授權。Intrinsic 也介紹了不綁定特定硬體的即時控制框架與數位分身功能。403337

兩項發布沒有已證實的技術依賴關係，但可從降低門檻的角度並看：GKE 工具試圖減少跨雲遷移的轉換工作，Intrinsic Core 則提供建構工業機器人應用的共用基礎。媒體以「機器人的 Android」形容後者的生態系策略；然而，開源基礎技術不代表開發者一定會購買 Google 的 AI 服務，也不代表 AWS 客戶一定會轉向 Google Cloud。230

**實務判斷：**GKE 遷移代理的價值，在於把 AI 產出的設定與驗證、部署權限分開，讓團隊有機會沿用既有審查流程。它可能使遷移更容易評估，但不能取代逐一驗證工作負載；目前提供的資料也沒有量化的失敗率或成本改善數據。219