在建立 VM 時，於 Compute Engine 執行個體上部署容器的容器啟動代理程式 (konlet) 已淘汰。
本文說明如何規劃將您在建立 VM 時建立的容器，遷移至其他 Cloud de Confiance by S3NS 服務。
一般資訊
- 什麼是 Compute Engine 中的容器啟動代理程式？
- 容器啟動代理程式可讓您在建立 VM 時，在 Compute Engine 執行個體或代管執行個體群組 (MIG) 的執行個體上部署及設定容器，並啟動 Docker 容器。
- 為什麼要淘汰容器啟動代理程式？
根據顧客的意見回饋， Cloud de Confiance by S3NS 強化了容器部署選項。我們已淘汰容器啟動代理程式，以便為您提供更彈性的容器部署選項。
如要進一步瞭解已淘汰的選項，請參閱「已淘汰的 VM 容器設定選項」。
- 這項淘汰作業的主要里程碑為何？如果我未在期限前採取行動，會發生什麼事？
2026 年 7 月 31 日起，凡是依附於容器啟動代理程式或
gce-container-declaration執行個體中繼資料的工作流程，都將無法再運作。自 2027 年 7 月 31 日起，Google 將停止支援容器啟動代理程式，且不會再為使用
gce-container-declaration中繼資料的任何執行中 VM 提供更新。您將自行承擔執行工作負載的風險，且這可能會影響工作流程。建議您在這些日期前將容器遷移至其他解決方案，確保轉換作業順利進行。
- 何時起，我將無法再使用
gce-container-declaration中繼資料直接部署容器，並建立新的 VM 或 MIG？ 自首次淘汰通知發布後 12 個月，也就是 2026 年 7 月 31 日。
- 我何時將無法在 VM 或 MIG 上執行容器部署作業，使用
gce-container-declaration中繼資料？ 自首次發出淘汰通知起 24 個月後，我們將停止支援使用容器啟動代理程式部署的任何工作負載，也就是 2027 年 7 月 31 日。
- 這項淘汰作業對我的 Terraform 設定有何影響？
如果您使用 Terraform 或類似的自動化工具，透過明確設定
gce-container-declaration中繼資料鍵來建立或更新 VM 或 MIG，工作流程將於 2026 年 7 月 31 日停止運作。為避免服務中斷，請更新 Terraform 設定，使用容器部署的開機指令碼，並移除對gce-container-declaration中繼資料金鑰的依附元件。如需詳細操作說明，請參閱遷移指南。- 這項淘汰作業是否代表 Container-Optimized OS 映像檔也會淘汰？
不會，Container-Optimized OS 映像檔不會遭到淘汰。這項異動與在採用 Container-Optimized OS 的 VM 上部署容器的方式有關。新版 Container-Optimized OS 不再支援 konlet，這是使用
gce-container-declaration中繼資料鍵部署容器的容器啟動代理程式。Container-Optimized OS 映像檔仍可使用，且會持續提供支援。不過，您必須更新 VM 設定，改用開機指令碼或cloud-init部署容器，而不是依賴gce-container-declaration中繼資料鍵。- 我使用
cloud-init在 VM 上執行容器。Am I impacted by this change? 不會。淘汰這項功能不會影響使用
cloud-init設定的 VM。您仍可繼續使用cloud-init設定執行個體。詳情請參閱「搭配 Cloud 服務設定使用 cloud-init」。- 如何判斷自己是否受到這項異動影響？
如果您在建立 VM 時，使用容器啟動代理程式或指定
gce-container-declaration，在 VM 上部署容器，就會受到這項淘汰作業影響。如要驗證專案中是否有任何受影響的執行個體，請執行下列 gcloud CLI 指令：gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"這個指令會列出專案中包含
gce-container-declaration中繼資料鍵的所有 VM 執行個體。中繼資料鍵可專屬識別屬於淘汰範圍的 VM。如果您使用多個專案，請在所有有效專案中執行指令。如要進一步瞭解如何查看專案中繼資料，請參閱中繼資料說明文件。
如要檢查特定執行個體，請執行下列 gcloud CLI 指令：
gcloud compute instances describe VM_NAME將 VM_NAME 替換為 VM 執行個體名稱。這項指令會提供指定執行個體的所有資訊，包括中繼資料。如果指令輸出內容中顯示
gce-container-declaration中繼資料金鑰，表示 VM 會受到這項變更影響。- 有什麼方法可以禁止建立使用容器啟動代理程式的 VM？
可以。機構管理員可以強制執行
compute.managed.disableVmsWithContainerStartupAgent機構政策限制，禁止建立使用容器啟動代理程式和gce-container-declaration中繼資料鍵的資源。您也可以在模擬測試模式下強制執行這項政策，監控資源用量，然後再封鎖資源建立作業。詳情請參閱「禁止建立使用已淘汰容器中繼資料的 VM」。- 遷移期間，專案安全或隱私權是否會面臨任何風險？
不會。安全性和隱私權是 Google 一切業務的基礎。 使用我們的指令碼或代管解決方案時，您可以彈性設定特定安全和隱私權設定，以符合您的需求。詳情請參閱遷移指南。
另外也提供
- 有哪些建議的替代解決方案 (取代 Compute Engine 上的容器)，以及如何根據需求選擇合適的解決方案？
您可以選擇下列任一選項來遷移容器：
- 如要繼續在 VM 或 MIG 上部署容器，或執行容器進行測試和開發，或執行由單一 VM 組成的工作負載，請使用啟動指令碼或 cloud-init。
- 如果您有無狀態容器應用程式和中小型作業，建議使用 Cloud Run。您也可以使用啟動指令碼。
- 如果容器是具有明確結束狀態且需要額外運算資源的批次工作，請考慮使用 Batch。您也可以使用啟動指令碼。
- 如需進階控管和擴充性，或無法透過其他選項滿足需求，請考慮使用 GKE。
如需遷移選項的詳細指南和建議，請參閱遷移指南。
- 相較於使用開機指令碼，為什麼我應該考慮遷移至 Cloud Run、GKE 或 Batch 等代管服務？
建議您考慮遷移至容器解決方案，例如 Google Kubernetes Engine、Cloud Run 和 Batch。相較於傳統的 VM 部署作業，這些代管服務具有顯著優勢，包括提升擴充性、彈性和進階管理功能。
主要福利包括：
- 減少管理負擔：做為全代管服務，Cloud de Confiance會處理底層基礎架構 (VM、修補、擴縮)。這種做法可節省寶貴的員工時間，並減輕營運負擔。
- 自動調度資源並確保彈性：這些服務會根據需求自動調整資源。與過度佈建 VM 相比，這能提高資源使用率，並節省費用。
- 提高閒置負載的成本效益：VM 即使閒置也會產生費用，但對於流量波動或偏低的應用程式，代管服務的成本效益更高。
- 善用免費方案：GKE、Cloud Run 和 Batch 提供免費方案，讓您執行較小的工作負載或進行測試，可能無需支付任何費用。
如需詳細遷移指南，請參閱這篇文章。
- 每種替代解決方案的費用考量因素為何？與目前的設定相比如何？
容器部署開機指令碼或 cloud-init：直接使用開機指令碼或
cloud-init做為替代方案，不會改變 Compute Engine 費用。您仍須支付基礎 VM 資源的費用。代管服務：改用 Cloud Run 或 Batch 等服務可節省成本，特別是使用量不穩定的應用程式。與閒置時仍會收費的 VM 不同，這些受管理服務的效率更高。此外，免費層級可進一步降低小型臨時工作負載的成本。
- 這項淘汰作業是否代表 Container-Optimized OS 映像檔將遭到淘汰？如果我們想在 Compute Engine VM 上執行 Docker，是否需要自行設定 VM 範本？
不會。Container-Optimized OS 映像檔本身不會遭到淘汰。這項異動與使用 Container-Optimized OS 在 VM 上啟動容器的方式有關。新版 Container-Optimized OS 不再支援 konlet，這是容器啟動代理程式，可使用
gce-container-declaration中繼資料鍵啟動容器。也就是說，Container-Optimized OS 映像檔仍可使用，且會繼續提供支援。不過，您必須更新 VM，改用開機指令碼或cloud-init設定部署容器，而不是使用gce-container-declaration中繼資料鍵。
遷移程序
- 將容器遷移至替代解決方案時，建議採取哪項做法？
建議您採取下列步驟進行遷移：
- 瞭解相關選項：請參閱遷移指南，瞭解執行容器的替代方式。
- 及早規劃遷移作業：為確保轉換作業順利進行，請在 2026 年 7 月 31 日前，開始規劃目前容器部署作業的遷移事宜。
- 為新工作負載做好準備：請確保新的容器工作負載已準備就緒，可在 2026 年 7 月 31 日前透過替代解決方案執行，因為屆時將無法再直接將容器部署至 VM 或 MIG。
- 最終遷移期限：請務必在 2027 年 7 月 31 日前，將所有現有容器工作負載遷移至替代解決方案，屆時直接部署方法將全面淘汰。
- 我是否必須遷移至其中一個建議解決方案，還是有其他替代方案可用？
我們支援您彈性採用符合業務需求且持續支援的解決方案。您可以參考遷移指南等資源，選擇最適合的方案。
- 遷移程序是否需要備份或匯出資料？
執行資料備份或匯出作業，一向是確保資料安全和業務持續性的重要最佳做法，但這並非本次遷移程序的必要步驟。
- 我需要多少時間才能改用替代方案？是否有任何因素會影響我投入的時間？
容器部署開機指令碼： 使用開機指令碼進行初始設定和測試，大約需要 1 到 2 小時。之後每次部署作業應只需要幾分鐘。
代管服務：選擇 Cloud Run、Batch 或 GKE 等解決方案 (無伺服器全代管 PaaS 產品) 可能需要投入更多時間和精力。Cloud de Confiance by S3NS 這是因為從以 VM 為中心的 (IaaS) 方法 (您管理基礎架構)，到平台處理大部分這類工作的 PaaS 模式，都發生了根本性的變化。這項調整可能需要變更應用程式，例如確保應用程式為無狀態，但長期效益包括大幅提升作業效率、擴充性和成本效益。
如需這項轉換的指引，請參閱遷移指南。
- 如果我選擇遷移至替代方案， Cloud de Confiance by S3NS 專案、VM、服務和應用程式是否會中斷或停機？
一般來說，改用建議的替代解決方案時，系統不會停機。
如要遷移 Compute Engine VM 上長時間執行的容器，建議您設定具有替代設定的新 VM，並在測試完成後切換流量，以免發生中斷。
- 這項遷移作業對我的 Terraform 設定有何影響？
如果您使用 Terraform 或類似的自動化工具，透過明確設定
gce-container-declaration中繼資料鍵，建立或更新含有容器的 VM 或 MIG，您的工作流程將於 2026 年 7 月 31 日停止運作。為避免服務中斷，請務必更新設定，加入容器部署的開機指令碼，並移除對gce-container-declaration中繼資料鍵的依附元件。如需如何實作這項變更的詳細操作說明，請參閱「遷移在建立 VM 時部署的容器」。
取得支援
- 如果對遷移程序有疑問，應該向 Compute Engine 的誰尋求協助？
- 如有任何疑問或需要協助，請與 Google Cloud 支援團隊聯絡。
- 有哪些資源可協助我遷移及提供技術指導？
- 我們提供這份常見問題、遷移指南和 Google Cloud 支援，協助您完成遷移程序。