本頁面提供在 Google Kubernetes Engine (GKE) 節點上使用含有 Containerd 的 Container-Optimized OS (cos_containerd) 的其他相關資訊。cos_containerd 映像檔提供 containerd CRI 執行階段環境的存取權。
在 GKE 叢集中使用 cos_containerd 映像檔
GKE v1.11 和更高版本提供 cos_containerd OS 映像檔這項測試版功能。建立新 GKE 叢集時、在現有叢集中建立新節點集區，或將現有 GKE 叢集更新為 v1.11 或更高版本時，都可以選取 cos_containerd 做為映像檔類型。
在測試期間，我們會收集客戶的意見。
目前 cos_containerd 只適用於 Container-Optimized OS (COS) 映像檔。
在 GKE 節點上執行 docker 指令
在 GKE v1.11 和更高版本中，Docker 適用於每個節點，但 containerd 是預設的執行階段。然而 Docker 不能管理節點上的 Kubernetes 容器，所以您無法使用 Docker 指令或 Docker API 檢視容器或與容器互動。
排解 GKE 節點上的容器問題
如要檢查或排解容器的問題，請改用預先安裝的 crictl，在所有符合容器執行階段介面 (CRI) 規格的執行階段上，crictl 都為可攜。GKE v1.11 和更高版本建議使用 crictl 工具與 containerd 和 Docker Engine 互動。詳情請瀏覽
crictl 使用者指南。
從具有特殊權限的 Pod 存取 Docker Engine
某些使用者目前會從節點上具特殊權限的 Pod 存取 Docker Engine。建議您更新工作負載，避免使用者直接使用 Docker。例如，假設您目前從 Docker Engine 擷取應用程式記錄或監控資料，請考慮改用 GKE 系統外掛程式來進行記錄和監控。
建構映像檔
containerd 不支援建構映像檔，因為 Kubernetes 本身不支援這項功能。
Kubernetes 不會得知 Kubernetes 範圍外的本機處理程序所用的系統資源，而且 Kubernetes 控制層在分配資源時無法計入這些處理程序。這會導致資源的 GKE 工作負載停擺，或造成節點不穩定。因此，我們建議不要在本機節點上執行指令。請考慮改用個別容器範圍外的其他服務 (例如 Cloud Build) 來完成這些工作，或使用 kaniko 之類的工具，以 Kubernetes 工作負載的形式建構映像檔。
如果以上建議都不適用，但您知道風險所在，那麼您可以繼續使用 Docker 來建構映像檔。您必須將映像檔推送到註冊資料庫後，再於 GKE 叢集使用這些映像檔。Kubernetes 不會得知在本機建構的映像檔。
後續步驟
您可以查看 Kubernetes 1.11 公告，進一步瞭解 containerd 整合。
詳情請瀏覽 containerd 和 CRI 外掛程式的說明文件。
