本頁面提供 containerd 容器執行階段的相關資訊、Google Kubernetes Engine (GKE) 中的 Docker 支援，以及必須遷移至使用 containerd 的節點映像檔的原因。如需如何遷移至 containerd 節點映像檔的操作說明，請參閱「從 Docker 遷移至 containerd 節點映像檔」。
總覽
Kubernetes 節點會使用容器執行階段啟動、管理及停止在 Pod 中執行的容器。Kubernetes 專案將在 1.24 以上版本中，移除對 Docker 執行階段的內建支援。為此，Kubernetes 將移除名為 dockershim 的元件，這個元件可讓 Docker 與 kubelet 等 Kubernetes 元件通訊。
Containerd 是新的預設執行階段，也是 Kubernetes 支援的業界標準容器執行階段，許多其他專案也使用這個執行階段。containerd 執行階段提供分層抽象化功能，可實作豐富的功能集，例如 gVisor 和映像檔串流，以擴充 GKE 功能。與 Docker 執行階段相比，Containerd 執行階段的資源效率更高，也更安全。
因此，GKE 1.24 以上版本不支援使用 Docker 做為執行階段的節點映像檔。如果叢集的任何節點集區使用以 Docker 為基礎的節點映像檔，或使用以 Docker 為基礎的預設節點映像檔類型進行節點自動佈建，就會受到影響。
在 2023 年 7 月 31 日 (GKE 1.23 版終止支援日期) 前，GKE 會暫停自動升級，並禁止手動升級至 1.24 版。如要在上述日期前將叢集的控制層升級至 GKE 1.24 以上版本，請務必更新節點自動佈建設定和所有節點，改用 containerd 執行階段。如要升級節點集區，必須改用以 containerd 執行階段為基礎的節點映像檔。
1.23 版終止服務後，GKE 會解除限制，允許尚未完成遷移的叢集手動將控制平面升級至 1.24 版，並開始逐步升級叢集，確保安全性和相容性。如要進一步瞭解 GKE 如何將叢集升級至 1.24，以及我們建議您如何從 Docker 節點映像檔遷移叢集，請參閱「版本 1.23 終止服務時的自動遷移」。
Docker 和 containerd 節點映像檔
自 Linux 1.19 版和 Windows 1.21 版起，所有新的 GKE 節點都預設使用 Containerd 做為執行階段。不過，GKE Standard 叢集仍支援使用 Docker 做為執行階段的節點映像檔。下表說明 GKE 1.24 以上版本不支援的 Docker 節點映像檔，以及對應的 containerd 映像檔：
| Docker 執行階段 | containerd 執行階段 |
|---|---|
含有 Docker 的 Container-Optimized OS (cos) |
擁有 Containerd (cos_containerd) 的 Container-Optimized OS |
含有 Docker 的 Ubuntu (ubuntu) |
擁有 Containerd (ubuntu_containerd) 的 Ubuntu |
採用 Docker 的 Windows Server LTSC (windows_ltsc) |
搭載 containerd 的 Windows Server LTSC (windows_ltsc_containerd) |
採用 Docker 的 Windows Server SAC ( |
採用 containerd 的 Windows Server SAC ( |
時間表和里程碑
在 GKE 1.23 版中，您無法再執行下列操作：
- 建立使用以 Docker 為基礎的節點映像檔的新叢集。
- 在現有叢集中新增以 Docker 為基礎的節點映像檔。
- 將
--autoprovisioning-image-type旗標設為以 Docker 為基礎的節點映像檔，啟用節點自動佈建功能。
如果升級至 GKE 1.23 版，可以繼續使用下列項目：
- 升級前建立的現有節點集區，使用以 Docker 為基礎的節點映像檔。
- 叢集自動配置器會依每個節點集區來運作，因此無法在採用 Docker 節點映像檔的節點集區上運作。
- 如果升級前已啟用，節點自動佈建功能會將
--autoprovisioning-image-type旗標設為以 Docker 為基礎的節點映像檔。
在 GKE 1.24 版中，您無法再執行下列操作：
- 如果控制平面執行 1.24 版，您就無法使用節點自動佈建功能，且
--autoprovisioning-image-type旗標會設為以 Docker 為基礎的節點映像檔。 - 如果節點集區執行 1.24 版，節點就無法使用以 Docker 為基礎的節點映像檔。
下表摘要說明與即將推出的 GKE 版本互動時，預期會發生的變更：
| 動作 | GKE 1.23 版 | GKE 1.24 版 |
|---|---|---|
| 使用 Docker 建立新叢集 | 否 | 否 |
| 使用 Docker 建立新的節點集區 | 否 | 否 |
| 使用 Docker 啟用節點自動佈建功能 | 否 | 否 |
| 從舊版升級，並沿用現有的 Docker 節點自動佈建設定 | 是 | 否 |
| 使用以 Docker 為基礎的節點映像檔 | 是 | 否 |
1.23 版終止服務時，系統會自動遷移
如果未在 2023 年 7 月 31 日前升級至 1.24 版，並遷移至 containerd 節點映像檔 (1.23 版將於當天終止支援)，GKE 會在一段時間後執行下列操作：
如果叢集具有節點自動佈建功能，且採用以 Docker 為基礎的預設節點映像檔類型，GKE 會更新設定，改用採用 containerd 執行階段的對等節點映像檔。您無法使用維護排除條件封鎖這項作業。為確保工作負載不受負面影響，建議您在 GKE 自動更新設定前，手動將節點自動佈建預設映像檔類型更新為以 containerd 為基礎的映像檔。
GKE 會將叢集的控制層升級至 1.24 版。
自 2023 年 9 月 1 日起，GKE 會將仍使用 Docker 的節點集區遷移至 containerd 節點映像檔。建議您在這之前手動遷移節點映像檔。或者，您也可以要求 GKE 啟動作業，將叢集遷移至使用 Containerd 映像檔。如要提出這項要求，請與 Cloud Customer Care 團隊聯絡。
如要暫時封鎖自動遷移作業，請將叢集升級至 1.24 以上版本，並設定維護作業排除項目。 如要進一步瞭解這項維護作業排除事項，請參閱「暫時延遲自動遷移至 containerd 節點映像檔」。
GKE 會將 1.23 版的節點集區升級至 1.24 版，就像處理任何不受支援的版本一樣，確保叢集健康狀態符合開放原始碼版本偏差政策。詳情請參閱 GKE 次要版本生命週期。您可以透過維護作業排除時段，暫時封鎖這項升級作業。
暫時延後自動遷移至 containerd 節點映像檔
將叢集的控制層升級至 1.24 以上版本後，您可以設定維護作業排除項目，暫時防止節點遷移，直到 2024 年 2 月 29 日版本 1.25 終止支援為止。如要符合這項維護作業排除條件，叢集必須註冊加入發布管道。將維護作業排除時段的「不執行任何次要或節點升級作業」範圍設為 --add-maintenance-exclusion-end 標記，並將該標記設為 2024-02-29T00:00:00Z 或更早。建議您盡快解除遷移作業的封鎖狀態，並允許節點升級至 1.24 版。已停止支援的次要版本不會再收到安全性修補程式和錯誤修正。
從 Docker 遷移至 containerd 節點映像檔
請參閱「從 Docker 遷移至 containerd 節點映像檔」，找出使用以 Docker 為基礎節點映像檔的叢集和節點集區，並將這些節點集區遷移至 containerd 節點映像檔。
根據 GKE 共同責任模式，客戶有責任維護工作負載的健康狀態，而 Google 有責任確保叢集維持運作，包括執行支援的版本。強烈建議您先測試工作負載並遷移叢集，再讓 GKE 自動執行這項作業。
在 1.23 版終止支援前，如果叢集的節點集區使用 Docker 節點映像檔，GKE 會禁止自動或手動升級至 1.24 版。將叢集遷移為僅使用 containerd 映像檔後，自動升級功能會在一天內恢復運作 (視 GKE 發布時間表而定)，您也可以手動升級叢集。
1.23 停止支援後，GKE 會解除自動或手動升級至 1.24 的限制，並按照自動遷移程序進行。
遷移的影響
改用 containerd 節點映像檔後，主要變更就是 Docker 不再管理容器的生命週期 (例如啟動和停止容器)。因此，您無法使用 Docker 指令或 Docker API，檢視或與節點上執行的 GKE 容器互動，這些節點使用 containerd 映像檔。
大多數使用者工作負載都不會依附於容器執行階段。Docker 執行階段也會實作 containerd，因此工作負載在 containerd 節點映像檔上的行為類似。
如果符合下列情況，你可能受到影響：
- 您執行的 Pod 具有特殊權限，可執行 Docker 指令。
- 您在 Kubernetes 基礎架構外部的節點上執行指令碼 (例如使用 SSH 進行問題疑難排解)。
- 您執行第三方工具，執行類似的權限作業。
- 部分工具會回應監控系統中的 Docker 專屬記錄。
- 您將外部供應商提供的記錄、監控、安全或持續整合工具部署到 GKE 叢集。請與這些供應商聯絡，確認影響程度。
在下列情況下，您不會受到影響：
- 您在 GKE 叢集外部有建構管道，使用 Docker 建構及推送容器映像檔。
- 您會在 GKE 叢集中使用
docker build和docker push指令。搭載 containerd 的 Linux 節點映像檔包含 Docker 二進位檔，並支援這些指令。
使用具備權限的 Pod 存取 Docker
如果使用者透過具備特殊權限的 Pod 存取節點上的 Docker Engine，您應更新這些工作負載，確保工作負載不會直接依附於 Docker。舉例來說，您可以考慮將記錄和監控擷取程序從 Docker Engine 遷移至 GKE 系統外掛程式。
使用 containerd 建構容器映像檔
您無法使用 containerd 建構容器映像檔。搭載 containerd 的 Linux 映像檔包含 Docker 二進位檔，因此您可以使用 Docker 建構及推送映像檔。不過，我們不建議使用個別容器和本機節點執行指令來建構映像檔。
Kubernetes 不會得知 Kubernetes 範圍外的本機處理程序所用的系統資源，而且 Kubernetes 控制層在分配資源時無法計入這些處理程序。這可能會導致 GKE 工作負載資源不足，或節點不穩定。
請考慮改用個別容器範圍外的其他服務 (例如 Cloud Build) 來完成這些工作，或使用 kaniko 之類的工具，以 Kubernetes 工作負載的形式建構映像檔。
如果上述建議都不適用，且您瞭解相關風險，可以繼續在本機節點上使用 Docker 建構映像檔。您必須先將映像檔推送至登錄檔，才能在 GKE 叢集中使用。Kubernetes with containerd 不會得知在本機建構的 Docker 映像檔。
在 containerd 節點上偵錯容器
如要針對 Linux 節點進行偵錯或疑難排解，您可以利用專為 Kubernetes 容器執行階段建構的可攜式指令列工具 (crictl) 與 Containerd 互動。crictl 支援檢視容器和映像檔、讀取記錄檔，以及在容器中執行指令等常用功能。如需完整的支援功能和使用資訊，請參閱 crictl 使用手冊。
如果是 Windows Server 節點，containerd daemon 會以名為 containerd 的 Windows 服務執行。
記錄的適用範圍如下：
- Windows：
C:\etc\kubernetes\logs\containerd.log - Linux：執行
journalctl -u containerd
您也可以在 LOG NAME: "container-runtime" 下方的記錄檔探索工具中，查看 Windows 和 Linux 節點的記錄。
疑難排解
如要排解問題，請參閱「排解 containerd 執行階段相關問題」。