由 EKS 搬去 GKE，Google 想將 AI 產出的改動先送審、後部署

Google 新開源的 GKE 遷移代理，重點唔係叫 AI 寫完設定就直接部署。Google 將它形容為一套以大型語言模型（LLM）推理、再配合確定性工具與防護措施的遷移流程，目標是取代臨時向模型發問、逐份設定檔修改的做法。2

對要由 Amazon EKS 搬到 Google Kubernetes Engine（GKE）的團隊來說，問題不只是「新設定可唔可以讀取」，而是搬完之後，應用程式的權限、流量去向和可用運算資源會唔會走樣。

最值得審的三類改動

遷移可能涉及基礎設施即程式碼和 Kubernetes 設定檔，但欄位對應不等於行為相同。Google 的容器遷移指引亦建議，先盤點工作負載及其依賴關係，再規劃搬遷。19

• **身份與權限：**若把 AWS 的身份設定對應到 GKE 的 Workload Identity，原有存取權限有冇保留？會唔會意外授予過多權限？
• **入口流量：**若把負載平衡器入口設定轉成 Gateway API，請求仲會唔會按預期到達正確服務？
• **節點配置：**轉換節點供應設定後，工作負載仲有冇所需的排程方式和容量？

以上係對遷移流程中各類對應關係的審核問題，唔代表已有證據證明工具能正確處理每一種情況。設定檔即使通過語法檢查，實際權限或流量行為仍可能改變。

確定性檢查同 Pull Request，各自把守一關

按所描述的工作流程，模型負責提出轉換建議，工具則提供可重複執行的檢查。Model Context Protocol（MCP）可以讓代理使用工具，但 MCP 本身唔會保證產出的設定正確。Google 公告確認工具結合 LLM 推理與確定性工具；不過，現有公告摘錄未有逐項交代外掛的操作、轉換規則或離線驗證涵蓋範圍。2

離線檢查的價值，在於同一批檔案可以按同一套規則先行測試，而唔使單靠 AI 解釋自己點解做得啱。但檢查只能涵蓋規則有檢測的項目，無法單憑結果證明切換後應用程式表現完全一樣。2

若按所描述的 Pull Request（程式碼修改請求）方式處理，生成的改動會先讓工程師看差異，再交由既有的持續整合與部署（CI/CD）流程執行測試、政策檢查及審批，而非直接改動運行中的叢集。這與 Google 對 GKE 使用原始碼管理和 CI/CD 的指引方向一致；但現有公告摘錄未能獨立確認此工具每一步的 Pull Request 流程。172

Google 公告引述 Persistent 高層 Rahul Shrivastava，稱這種做法是「可驗證、編譯器級別的遷移工廠」（“provable, compiler-grade migration factory”）。這個比喻可以用來理解「產出設定、檢查、再審批」的流程，卻唔等於整次遷移獲得數學上的安全保證；執行時行為、效能、依賴關係和正式切換仍要另外測試。2

同 Intrinsic Core 有咩關係？

GKE 公告前兩日，Intrinsic 於多倫多 ROSCon 2026 發布 Intrinsic Core，開源一套與機械人作業系統 ROS 相容的工業機械人基礎能力，包括控制、動作與抓取規劃、模擬及姿態估計；報道指採用 Apache 2.0 授權。Intrinsic 亦介紹了不綁定特定硬件的即時控制框架及數碼孿生功能。403337

兩者並非技術上相連，而是有相似的策略思路：GKE 工具嘗試降低轉雲的工程門檻，Intrinsic Core 則降低開發工業機械人應用的起步成本。有報道以「機械人版 Android」形容後者的生態策略；但開源發佈本身，既不能證明 AWS 客戶會轉用 Google Cloud，亦不能證明開發者最終會購買 Google 的 AI 服務。230

**實際判斷：**這套 GKE 設計嘗試將「AI 可以提出改動」與「改動可以獲准部署」分開，讓團隊沿用熟悉的審核流程。它有助令建議更容易檢視，卻不能取代逐個工作負載驗證；現有資料亦沒有提供遷移失敗率或成本下降的實測數字。219