容器运行时

你需要在集群中的每个节点上安装容器运行时,以便 Pod 可以在其中运行。本页面概述了相关步骤和设置节点的相关任务。

Kubernetes 1.33 要求你使用符合容器运行时接口 (CRI) 的运行时。

有关更多信息,请参见CRI 版本支持

本页面概述了如何将几种常见的容器运行时用于 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 上,控制组 (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 驱动,请编辑 KubeletConfigurationcgroupDriver 选项并将其设置为 systemd。例如

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

如果你将 systemd 配置为 kubelet 的 cgroup 驱动,则还必须将 systemd 配置为容器运行时的 cgroup 驱动。有关说明,请参阅你的容器运行时的文档。例如

在 Kubernetes 1.33 中,如果启用了 KubeletCgroupDriverFromCRI 特性门控 并且容器运行时支持 RuntimeConfig CRI RPC,则 kubelet 会自动从运行时检测相应的 cgroup 驱动,并忽略 kubelet 配置中的 cgroupDriver 设置。

在 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 驱动。

如果你应用此更改,请确保重启 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"

更新配置文件后,你可能还需要重启 containerdsystemctl 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

  1. 在你的每个节点上,按照安装 Docker Engine 中的说明为你使用的 Linux 发行版安装 Docker。

  2. 按照文档安装部分的说明,安装 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 网站指南

在提出添加额外第三方链接的更改之前,你应该阅读内容指南

最后修改于 2025 年 1 月 6 日太平洋标准时间下午 5:48:升级 sandbox 镜像版本 (4787df6350)