容器运行时
你需要在集群中的每个节点上安装容器运行时,以便 Pod 可以在其中运行。本页面概述了相关步骤和设置节点的相关任务。
Kubernetes 1.33 要求你使用符合容器运行时接口 (CRI) 的运行时。
有关更多信息,请参见CRI 版本支持。
本页面概述了如何将几种常见的容器运行时用于 Kubernetes。
注意
v1.24 之前的 Kubernetes 版本包含使用名为 dockershim 的组件直接集成 Docker Engine。该特殊的直接集成不再是 Kubernetes 的一部分(此移除已作为 v1.20 发布的一部分公布)。你可以阅读检查 Dockershim 移除是否影响你来了解此移除可能如何影响你。要了解如何从使用 dockershim 迁移,请参见从 dockershim 迁移。
如果你运行的 Kubernetes 版本不是 v1.33,请查阅该版本的文档。
安装和配置先决条件
网络配置
默认情况下,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 上,控制组 (control groups) 用于约束分配给进程的资源。
kubelet 和底层容器运行时都需要与控制组接口,以强制执行针对 Pod 和容器的资源管理并设置诸如 CPU/内存请求和限制等资源。为了与控制组接口,kubelet 和容器运行时需要使用一个 cgroup 驱动。kubelet 和容器运行时使用相同的 cgroup 驱动并进行相同的配置至关重要。
有两种可用的 cgroup 驱动
cgroupfs 驱动
cgroupfs
驱动是kubelet 中的默认 cgroup 驱动。使用 cgroupfs
驱动时,kubelet 和容器运行时直接与 cgroup 文件系统接口来配置 cgroup。
当 systemd 是 init 系统时,不推荐使用 cgroupfs
驱动,因为 systemd 希望系统上只有一个 cgroup 管理器。此外,如果你使用cgroup v2,请使用 systemd
cgroup 驱动而不是 cgroupfs
。
systemd cgroup 驱动
当选择 systemd 作为 Linux 发行版的 init 系统时,init 进程会生成并使用一个根控制组 (cgroup
),并充当 cgroup 管理器。
systemd 与 cgroup 紧密集成,并为每个 systemd 单元分配一个 cgroup。因此,如果你使用 systemd
作为 init 系统并配合 cgroupfs
驱动,系统上就会有两个不同的 cgroup 管理器。
两个 cgroup 管理器会导致系统可用和正在使用的资源有两个视图。在某些情况下,为 kubelet 和容器运行时配置使用 cgroupfs
,但其余进程使用 systemd
的节点在资源压力下会变得不稳定。
解决这种不稳定性方法是,当 systemd 是选定的 init 系统时,将 systemd
用作 kubelet 和容器运行时的 cgroup 驱动。
要将 systemd
设置为 cgroup 驱动,请编辑 KubeletConfiguration
的 cgroupDriver
选项并将其设置为 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.33 中,如果启用了 KubeletCgroupDriverFromCRI
特性门控 并且容器运行时支持 RuntimeConfig
CRI RPC,则 kubelet 会自动从运行时检测相应的 cgroup 驱动,并忽略 kubelet 配置中的 cgroupDriver
设置。
注意事项
更改已加入集群的节点的 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 socket 是 /run/containerd/containerd.sock
。在 Windows 上,默认的 CRI endpoint 是 npipe://./pipe/containerd-containerd
。
配置 systemd
cgroup 驱动
要在 /etc/containerd/config.toml
中配合 runc
使用 systemd
cgroup 驱动,请设置
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
如果你使用cgroup v2,推荐使用 systemd
cgroup 驱动。
注意
如果你是通过软件包(例如 RPM 或 .deb
)安装的 containerd,你可能会发现 CRI 集成插件默认是禁用的。
要将 containerd 与 Kubernetes 一起使用,你需要启用 CRI 支持。请确保 /etc/containerd/config.toml
中的 disabled_plugins
列表中不包含 cri
;如果你修改了该文件,还需要重启 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 驱动。
覆盖 sandbox (pause) 镜像
在你的containerd 配置中,你可以通过设置以下配置来覆盖 sandbox 镜像
[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
中放置一个 drop-in 配置,例如
[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 socket 是 /var/run/crio/crio.sock
。
覆盖 sandbox (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 socket 是 /run/cri-dockerd.sock
。
Mirantis Container Runtime
Mirantis Container Runtime (MCR) 是一种商业容器运行时,以前称为 Docker Enterprise Edition。
你可以使用 MCR 中包含的开源组件 cri-dockerd
将 Mirantis Container Runtime 与 Kubernetes 一起使用。
要了解有关如何安装 Mirantis Container Runtime 的更多信息,请访问MCR 部署指南。
检查名为 cri-docker.socket
的 systemd 单元,找出 CRI socket 的路径。
覆盖 sandbox (pause) 镜像
cri-dockerd
适配器接受一个命令行参数,用于指定将哪个容器镜像用作 Pod 基础设施容器(“pause 镜像”)。要使用的命令行参数是 --pod-infra-container-image
。
下一步
除了容器运行时,你的集群还需要一个正常工作的网络插件。
本页面中的项目指的是提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不对这些第三方产品或项目负责。有关更多详细信息,请参阅 CNCF 网站指南。
在提出添加额外第三方链接的更改之前,你应该阅读内容指南。