容器运行时
你需要在集群中的每个节点上安装一个容器运行时，以便 Pod 可以在那里运行。本页面概述了所涉及的内容，并描述了设置节点的相关任务。
Kubernetes 1.34 要求你使用符合容器运行时接口 (CRI) 的运行时。
有关更多信息，请参阅 CRI 版本支持。
本页面概述了如何将几种常见的容器运行时与 Kubernetes 配合使用。
注意
Kubernetes v1.24 之前的版本包含与 Docker Engine 的直接集成，使用了名为 _dockershim_ 的组件。该特殊的直接集成不再是 Kubernetes 的一部分（该移除已在 v1.20 版本发布时宣布）。你可以阅读检查 Dockershim 移除是否影响你，以了解此移除可能如何影响你。要了解如何从使用 dockershim 迁移，请参阅从 dockershim 迁移。
如果你运行的是 v1.34 以外的 Kubernetes 版本，请查看该版本的文档。
安装和配置前提条件
网络配置
默认情况下，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 驱动
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
注意
从 v1.22 及更高版本开始，使用 kubeadm 创建集群时，如果用户未在KubeletConfiguration 下设置 cgroupDriver 字段，kubeadm 默认将其设置为 systemd。如果你将 systemd 配置为 kubelet 的 cgroup 驱动，则还必须将 systemd 配置为容器运行时的 cgroup 驱动。有关说明，请参阅你的容器运行时文档。例如：
在 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 中失败。
注意
更改已加入集群的节点的 cgroup 驱动是一个敏感操作。如果 kubelet 使用一个 cgroup 驱动的语义创建了 Pod，则将容器运行时更改为另一个 cgroup 驱动可能会在尝试为这些现有 Pod 重新创建 Pod 沙箱时导致错误。重启 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 配置文件后，返回此步骤。
你可以在路径 /etc/containerd/config.toml 下找到此文件。
你可以在路径 C:\Program Files\containerd\config.toml 下找到此文件。
在 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 驱动。
注意
如果你是从软件包（例如 RPM 或 .deb）安装的 containerd，你可能会发现 CRI 集成插件默认是禁用的。
你需要启用 CRI 支持才能将 containerd 与 Kubernetes 配合使用。确保 cri 不包含在 /etc/containerd/config.toml 中的 disabled_plugins 列表中；如果你对该文件进行了更改，请同时重新启动 containerd。
如果在初始集群安装后或安装 CNI 后出现容器崩溃循环，软件包提供的 containerd 配置可能包含不兼容的配置参数。考虑使用 containerd config default > /etc/containerd/config.toml 重置 containerd 配置，如 getting-started.md 中所述，然后相应地设置上面指定的配置参数。
如果应用此更改，请务必重新启动 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
注意
这些说明假定你正在使用cri-dockerd 适配器将 Docker Engine 与 Kubernetes 集成。在你的每个节点上，按照 安装 Docker Engine 中的说明，为你的 Linux 发行版安装 Docker。
按照文档安装部分中的说明，安装
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。
下一步
除了容器运行时之外，你的集群还需要一个正常工作的网络插件。
本页上的项目引用了提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不对这些第三方产品或项目负责。有关详细信息，请参阅 CNCF 网站指南。
在提议添加额外第三方链接的更改之前，你应该阅读内容指南。