容器執行時

你需要在叢集中的每個節點上安裝一個容器執行時，以便 Pod 可以在那裡執行。本頁面概述了所涉及的內容，並描述了設定節點的相關任務。

Kubernetes 1.34 要求你使用符合容器執行時介面 (CRI) 的執行時。

有關更多資訊，請參閱 CRI 版本支援。

本頁面概述瞭如何將幾種常見的容器執行時與 Kubernetes 配合使用。

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

安裝和配置前提條件

網路配置

預設情況下，Linux 核心不允許 IPv4 資料包在介面之間路由。大多數 Kubernetes 叢集網路實現會更改此設定（如果需要），但有些可能期望管理員為他們完成此操作。（有些可能還期望設定其他 sysctl 引數、載入核心模組等；請查閱你的特定網路實現的文件。）

啟用 IPv4 資料包轉發

手動啟用 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

cgroup 驅動

在 Linux 上，控制組用於限制分配給程序的資源。

kubelet 和底層容器執行時都需要與控制組進行介面，以強制執行Pod 和容器的資源管理並設定 cpu/記憶體請求和限制等資源。為了與控制組進行介面，kubelet 和容器執行時需要使用一個_cgroup 驅動_。kubelet 和容器執行時使用相同的 cgroup 驅動並以相同方式配置是至關重要的。

有兩種可用的 cgroup 驅動

• cgroupfs
• systemd

cgroupfs 驅動

cgroupfs 驅動是 kubelet 中的預設 cgroup 驅動。當使用 cgroupfs 驅動時，kubelet 和容器執行時直接與 cgroup 檔案系統互動以配置 cgroups。

當 systemd 是 init 系統時，**不**建議使用 cgroupfs 驅動，因為 systemd 期望系統上只有一個 cgroup 管理器。此外，如果你使用 cgroup v2，請使用 systemd cgroup 驅動而不是 cgroupfs。

systemd cgroup 驅動

當 systemd 被選作 Linux 發行版的 init 系統時，init 程序生成並使用根控制組 (cgroup) 並充當 cgroup 管理器。

systemd 與 cgroups 緊密整合，併為每個 systemd 單元分配一個 cgroup。因此，如果你將 systemd 用作 init 系統並使用 cgroupfs 驅動，則系統將獲得兩個不同的 cgroup 管理器。

兩個 cgroup 管理器導致系統中可用和已用資源有兩個檢視。在某些情況下，配置為 kubelet 和容器執行時使用 cgroupfs，但其餘程序使用 systemd 的節點在資源壓力下變得不穩定。

緩解這種不穩定性方法是，當 systemd 是選定的 init 系統時，將 systemd 用作 kubelet 和容器執行時的 cgroup 驅動。

要將 systemd 設定為 cgroup 驅動，請編輯 cgroupDriver 的 KubeletConfiguration 選項並將其設定為 systemd。例如：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd

如果你將 systemd 配置為 kubelet 的 cgroup 驅動，則還必須將 systemd 配置為容器執行時的 cgroup 驅動。有關說明，請參閱你的容器執行時文件。例如：

• containerd
• CRI-O

在 Kubernetes 1.34 中，如果啟用了 KubeletCgroupDriverFromCRI 功能門，並且容器執行時支援 RuntimeConfig CRI RPC，kubelet 會自動從執行時檢測到適當的 cgroup 驅動，並忽略 kubelet 配置中的 cgroupDriver 設定。

然而，舊版本的容器執行時（特別是 containerd 1.x 及更低版本）不支援 RuntimeConfig CRI RPC，並且可能無法正確響應此查詢，因此 Kubelet 會回退到使用其自己的 --cgroup-driver 標誌中的值。

在 Kubernetes 1.36 中，此回退行為將被取消，舊版本的 containerd 將在新版 kubelet 中失敗。

在 kubeadm 管理的叢集中遷移到 systemd 驅動

如果你希望在現有的 kubeadm 管理的叢集中遷移到 systemd cgroup 驅動，請遵循配置 cgroup 驅動。

CRI 版本支援

你的容器執行時必須至少支援容器執行時介面的 v1alpha2 版本。

Kubernetes 從 v1.26 開始_僅支援_CRI API 的 v1 版本。早期版本預設為 v1 版本，但是如果容器執行時不支援 v1 API，kubelet 會回退到使用（已棄用的）v1alpha2 API。

容器執行時

containerd

本節概述了使用 containerd 作為 CRI 執行時的必要步驟。

要在系統上安裝 containerd，請按照containerd 入門上的說明進行操作。建立有效的 config.toml 配置檔案後，返回此步驟。

• Linux
• Windows

在 Linux 上，containerd 的預設 CRI 套接字是 /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 驅動。

如果應用此更改，請務必重新啟動 containerd

sudo systemctl restart containerd

使用 kubeadm 時，手動配置 kubelet 的 cgroup 驅動。

在 Kubernetes v1.28 中，你可以將 cgroup 驅動的自動檢測作為 Alpha 功能啟用。有關詳細資訊，請參閱 systemd cgroup 驅動。

覆蓋沙箱 (pause) 映象

在你的 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 安裝說明。

cgroup 驅動

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 時，它必須設定為 pod。通常需要保持 kubelet（通常透過 kubeadm 完成）和 CRI-O 的 cgroup 驅動配置同步。

在 Kubernetes v1.28 中，你可以將 cgroup 驅動的自動檢測作為 Alpha 功能啟用。有關詳細資訊，請參閱 systemd cgroup 驅動。

對於 CRI-O，CRI 套接字預設為 /var/run/crio/crio.sock。

覆蓋沙箱 (pause) 映象

在你的 CRI-O 配置中，你可以設定以下配置值：

[crio.image]
pause_image="registry.k8s.io/pause:3.10"

此配置選項支援即時配置重新載入以應用此更改：systemctl reload crio 或透過向 crio 程序傳送 SIGHUP。

Docker Engine

1. 在你的每個節點上，按照 安裝 Docker Engine 中的說明，為你的 Linux 發行版安裝 Docker。

2. 按照文件安裝部分中的說明，安裝 cri-dockerd。

對於 cri-dockerd，CRI 套接字預設為 /run/cri-dockerd.sock。

Mirantis Container Runtime

Mirantis Container Runtime (MCR) 是一種商用容器執行時，以前稱為 Docker Enterprise Edition。

你可以使用 Mirantis Container Runtime 與 Kubernetes，透過 MCR 中包含的開源 cri-dockerd 元件。

要了解有關如何安裝 Mirantis Container Runtime 的更多資訊，請訪問 MCR 部署指南。

檢查名為 cri-docker.socket 的 systemd 單元，以找出 CRI 套接字的路徑。

覆蓋沙箱 (pause) 映象

cri-dockerd 介面卡接受一個命令列引數，用於指定使用哪個容器映象作為 Pod 基礎設施容器（“暫停映象”）。要使用的命令列引數是 --pod-infra-container-image。

下一步

除了容器執行時之外，你的叢集還需要一個正常工作的網路外掛。