您需要在叢集中的每個節點安裝 容器執行階段， 以便 Pod 能在其中執行。本頁概述了相關的內容，並說明設定節點的相關工作。
Kubernetes 1.35 要求您使用符合 Container Runtime Interface (CRI) 的執行階段。
如需更多資訊，請參閱 CRI 版本支援。
本頁概述了如何將數種常見的容器執行階段與 Kubernetes 搭配使用。
Kubernetes v1.24 之前的版本透過一個名為 dockershim 的組件，直接與 Docker Engine 整合。 這種特殊的直接整合已不再是 Kubernetes 的一部分（此移除已在 v1.20 版本發布時公告）。 您可以閱讀確認 Dockershim 移除是否會影響您， 了解此移除可能對您造成的影響。 若要了解如何從 dockershim 遷移，請參閱從 dockershim 遷移。
如果您執行的 Kubernetes 版本不是 v1.35，請查看該版本的文件。
預設情況下，Linux 核心不允許在介面之間路由 IPv4 封包。 大多數 Kubernetes 叢集網路實作都會修改此設定（如果需要），但有些實作可能會預期管理員代為執行此步驟。 （有些實作也可能預期管理員設定其他 sysctl 參數、載入核心模組等；請針對您所使用的特定網路實作，參閱其說明文件。）
若要手動啟用 IPv4 封包轉發：
# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
透過以下指令驗證 net.ipv4.ip_forward 是否已設定為 1：
sysctl net.ipv4.ip_forward
在 Linux 系統上，控制群組 是用於限制分配給程序的資源。
kubelet 與底層的容器執行階段都需要與控制群組互動， 以強制執行 Pod 與容器的資源管理，並設定如 CPU、記憶體等資源的請求與限制。 為了與控制群組互動，kubelet 和容器執行階段需要使用 cgroup 驅動程式。 最重要的是，kubelet 和容器執行階段必須使用相同的 cgroup 驅動程式，且設定必須一致。
目前有兩種可用的 cgroup 驅動程式：
cgroupfs 驅動程式是 kubelet 預設的 cgroup 驅動程式。
當使用 cgroupfs 驅動程式時，kubelet 和容器執行階段會直接與 cgroup 檔案系統互動以設定 cgroup。
當 systemd 是系統的 init 系統時，
不建議使用 cgroupfs 驅動程式，因為 systemd 預期系統上只有單一個 cgroup 管理器。
此外，如果您使用 cgroup v2，請使用 systemd cgroup 驅動程式而非 cgroupfs。
當 Linux 發行版選擇 systemd 作為 init 系統時，
init 程序會產生並使用一個根控制群組（cgroup），並扮演 cgroup 管理器的角色。
systemd 與 cgroup 具有緊密的整合，並會為每個 systemd 單元分配一個 cgroup。
因此，如果您將 systemd 作為 init 系統並搭配 cgroupfs 驅動程式使用，系統中將會出現兩個不同的 cgroup 管理器。
兩個 cgroup 管理器會導致系統對可用資源與已用資源產生兩種不同的解讀。
在某些情況下，如果節點被設定為在 kubelet 和容器執行階段使用 cgroupfs，而其他程序則使用 systemd；
當資源面臨壓力時，系統將會變得不穩定。
緩解這種不穩定性的方法是，當 systemd 被選為 init 系統時，kubelet 和容器執行階段也應該使用 systemd 作為 cgroup 驅動程式。
若要將 cgroup 驅動程式設定為 systemd，請編輯 KubeletConfiguration
中的 cgroupDriver 選項，並將其設定為 systemd。例如：
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
從 v1.22 及後續版本開始，當使用 kubeadm 建立叢集時，如果使用者未在 KubeletConfiguration 下設定 cgroupDriver 欄位，kubeadm 預設會將其設定為 systemd。
如果您將 kubelet 的 cgroup 驅動程式設定為 systemd，您也必須將容器執行階段的 cgroup 驅動程式設定為 systemd。相關說明請參閱您的容器執行階段文件。例如：
在 Kubernetes 1.35 中，若啟用 KubeletCgroupDriverFromCRI
功能開關，
並且容器執行階段支援 RuntimeConfig CRI RPC，kubelet 將自動從執行階段偵測合適的 cgroup 驅動程式，
並忽略 kubelet 設定中的 cgroupDriver 設定。
然而，較舊版本的容器執行階段（具體來說，containerd 1.y 及更低版本）不支援 RuntimeConfig CRI RPC，因此可能無法正確回應此查詢，導致 kubelet 退而使用自身 --cgroup-driver 參數的值。
在 Kubernetes 1.36 中，此退回機制將被移除，這意味著較舊版本的 containerd 在較新的 kubelet 上將無法運作。
對於已加入叢集的節點，變更其 cgroup 驅動程式是一項敏感的操作。 若 kubelet 已使用某種 cgroup 驅動程式的語意建立 Pod 的話，當嘗試重建這些既有 Pod 的沙盒時，將容器執行階段更換為另一種驅動程式可能會引發錯誤。這類錯誤可能無法透過重啟 kubelet 來解決。
如果您的自動化機制可行，請使用已更新設定的另一個節點來替換該節點，或是透過自動化機制重新安裝該節點。
systemd 驅動程式如果您希望在現有由 kubeadm 管理的叢集中遷移至 systemd cgroup 驅動程式，請遵循設定 cgroup 驅動程式的說明。
您的容器執行階段必須至少支援 v1alpha2 的容器執行階段介面。
Kubernetes 自 v1.26 起 僅支援 v1 版本的 CRI API。較早版本預設使用 v1 版本，但如果容器執行階段不支援 v1 API，kubelet 將退而使用（已棄用）v1alpha2 API。
本節概述將 containerd 作為 CRI 執行階段所需的步驟。
若要在您的系統上安裝 containerd，請遵循 getting started with containerd 中的說明。
當您建立好有效的 config.toml 設定檔後，請回到此步驟。
您可以在 /etc/containerd/config.toml 路徑下找到此檔案。
您可以在 C:\Program Files\containerd\config.toml 路徑下找到此檔案。
在 Linux 上，containerd 的預設 CRI socket 為 /run/containerd/containerd.sock。
在 Windows 上，預設的 CRI 端點為 npipe://./pipe/containerd-containerd。
systemd cgroup 驅動程式若要在 /etc/containerd/config.toml 中搭配 runc 使用 systemd cgroup 驅動程式，請根據您的 Containerd 版本設定以下配置：
Containerd 1.x 版本：
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
Containerd 2.x 版本：
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
...
[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
SystemdCgroup = true
如果您使用 cgroup v2，則建議使用 systemd cgroup 驅動程式。
如果您是透過套件（例如 RPM 或 .deb）安裝 containerd，您可能會發現 CRI 整合外掛程式預設是被停用的。
您需要啟用 CRI 支援才能讓 containerd 與 Kubernetes 一起運作。請確保 cri 未被包含在 /etc/containerd/config.toml 中的 disabled_plugins 列表中；如果您修改了該檔案，請同時重新啟動 containerd。
如果您在叢集初始安裝後或安裝 CNI 後遇到容器持續當機，可能是因為套件提供的 containerd 設定包含不相容的參數。建議參照 getting-started.md 的說明，使用 containerd config default > /etc/containerd/config.toml 重設 containerd 設定，再根據上述說明設定相關參數。
如果您套用了此變更，請務必重新啟動 containerd：
sudo systemctl restart containerd
使用 kubeadm 時，請手動設定 kubelet 的 cgroup 驅動程式。
在 Kubernetes v1.28 中，您可以將自動偵測 cgroup 驅動程式啟用為 alpha 功能。如需更多細節，請參閱 systemd cgroup 驅動程式。
在您的 containerd 設定中，您可以透過設定以下內容來覆寫沙盒映像檔：
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.10"
更新設定檔後，您可能還需要重新啟動 containerd：systemctl restart containerd。
本節包含將 CRI-O 安裝為容器執行階段所需的步驟。
若要安裝 CRI-O，請遵循 CRI-O 安裝說明。
CRI-O 預設使用 systemd cgroup 驅動程式，這通常可以正常運作。若要切換為 cgroupfs cgroup 驅動程式，您可以編輯 /etc/crio/crio.conf 或是在 /etc/crio/crio.conf.d/02-cgroup-manager.conf 放置一個補充設定檔，例如：
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
您也應注意已變更的 conmon_cgroup。當 CRI-O 與 cgroupfs 搭配使用時，conmon_cgroup 必須被設定為 pod。一般來說，必須保持 kubelet（通常透過 kubeadm 設定）和 CRI-O 的 cgroup 驅動程式設定同步。
在 Kubernetes v1.28 中，您可以將自動偵測 cgroup 驅動程式啟用為 alpha 功能。如需更多細節，請參閱 systemd cgroup 驅動程式。
對於 CRI-O，預設的 CRI socket 是 /var/run/crio/crio.sock。
在您的 CRI-O 設定中，您可以設定以下配置值：
[crio.image]
pause_image="registry.k8s.io/pause:3.10"
此設定選項支援即時重新載入以套用變更：執行 systemctl reload crio，或向 crio 程序發送 SIGHUP 訊號。
這些說明假設您正在使用 cri-dockerd 轉接器，以將 Docker Engine 與 Kubernetes 整合。
cri-dockerd，請遵循文件安裝章節中的說明。對於 cri-dockerd，預設的 CRI socket 是 /run/cri-dockerd.sock。
Mirantis 容器執行階段 (MCR) 是一種商用的容器執行階段，其前身為 Docker Enterprise Edition。
您可以透過 MCR 內建的開源 cri-dockerd 組件，將 Mirantis 容器執行階段搭配 Kubernetes 使用。
要進一步了解如何安裝 Mirantis 容器執行階段，請訪問 MCR 部署指南。
檢查名為 cri-docker.socket 的 systemd 單元，以找出 CRI socket 的路徑。
cri-dockerd 轉接器接受一個命令列參數，用於指定要使用哪個容器映像檔作為 Pod 的基礎設施容器（"pause 映像檔"）。
要使用的命令列參數為 --pod-infra-container-image。
除了容器執行階段外，您的叢集還需要一個可用的網路外掛程式。
Items on this page refer to third party products or projects that provide functionality required by Kubernetes. The Kubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website guidelines for more details.
You should read the content guide before proposing a change that adds an extra third-party link.