容器运行时

你需要在集群中的每个节点上安装容器运行时,以便 Pod 可以在那里运行。此页面概述了涉及的内容,并描述了设置节点的相关任务。

Kubernetes 1.32 要求你使用符合容器运行时接口(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 上,控制组用于约束分配给进程的资源。

kubelet 和底层容器运行时都需要与控制组接口,以强制执行Pod 和容器的资源管理,并设置诸如 CPU/内存请求和限制之类的资源。为了与控制组接口,kubelet 和容器运行时需要使用 cgroup 驱动程序。至关重要的是,kubelet 和容器运行时使用相同的 cgroup 驱动程序,并且配置相同。

有两个可用的 cgroup 驱动程序

cgroupfs 驱动程序

cgroupfs 驱动程序是 kubelet 中的默认 cgroup 驱动程序。当使用 cgroupfs 驱动程序时,kubelet 和容器运行时直接与 cgroup 文件系统接口以配置 cgroup。

systemd 是初始化系统时,建议使用 cgroupfs 驱动程序,因为 systemd 期望系统上有一个单一的 cgroup 管理器。此外,如果你使用 cgroup v2,请使用 systemd cgroup 驱动程序而不是 cgroupfs

systemd cgroup 驱动程序

当选择 systemd 作为 Linux 发行版的初始化系统时,初始化进程会生成并使用根控制组 (cgroup) 并充当 cgroup 管理器。

systemd 与 cgroup 紧密集成,并为每个 systemd 单元分配一个 cgroup。因此,如果你使用 systemd 作为初始化系统和 cgroupfs 驱动程序,系统将获得两个不同的 cgroup 管理器。

两个 cgroup 管理器会导致系统中可用和正在使用的资源的两种视图。在某些情况下,配置为 kubelet 和容器运行时使用 cgroupfs,但其余进程使用 systemd 的节点在资源压力下变得不稳定。

缓解此不稳定性的方法是,当 systemd 是选定的初始化系统时,为 kubelet 和容器运行时使用 systemd 作为 cgroup 驱动程序。

要将 systemd 设置为 cgroup 驱动程序,请编辑 KubeletConfigurationcgroupDriver 选项,并将其设置为 systemd。例如

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

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

在 Kubernetes 1.32 中,启用 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 套接字是 /run/containerd/containerd.sock。在 Windows 上,默认的 CRI 端点是 npipe://./pipe/containerd-containerd

配置 systemd cgroup 驱动

要在 /etc/containerd/config.toml 中使用 systemd cgroup 驱动程序以及 runc,请设置

[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 驱动程序

覆盖沙箱(暂停)镜像

在您的 containerd 配置中,您可以通过设置以下配置来覆盖沙箱镜像

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.2"

更新配置文件后,您可能还需要重启 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 中,例如

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

您还应该注意更改后的 conmon_cgroup,在使用带有 cgroupfs 的 CRI-O 时,必须将其设置为 pod 值。通常,必须保持 kubelet(通常通过 kubeadm 完成)和 CRI-O 的 cgroup 驱动程序配置同步。

在 Kubernetes v1.28 中,您可以启用 cgroup 驱动程序的自动检测作为 alpha 功能。有关更多详细信息,请参阅 systemd cgroup 驱动程序

对于 CRI-O,CRI 套接字默认为 /var/run/crio/crio.sock

覆盖沙箱(暂停)镜像

在您的 CRI-O 配置中,您可以设置以下配置值

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

此配置选项支持实时配置重新加载以应用此更改:systemctl reload crio 或向 crio 进程发送 SIGHUP

Docker Engine

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

  2. 按照文档的安装部分中的说明安装 cri-dockerd

对于 cri-dockerd,CRI 套接字默认为 /run/cri-dockerd.sock

Mirantis 容器运行时

Mirantis Container Runtime (MCR) 是一种商业可用的容器运行时,以前称为 Docker Enterprise Edition。

您可以使用 Mirantis Container Runtime 与 Kubernetes,使用 MCR 包含的开源 cri-dockerd 组件。

要了解有关如何安装 Mirantis Container Runtime 的更多信息,请访问 MCR 部署指南

检查名为 cri-docker.socket 的 systemd 单元以找出 CRI 套接字的路径。

覆盖沙箱(暂停)镜像

cri-dockerd 适配器接受一个命令行参数,用于指定要用作 Pod 基础设施容器(“暂停镜像”)的容器镜像。要使用的命令行参数是 --pod-infra-container-image

下一步

除了容器运行时,您的集群还需要一个正常工作的网络插件

此页面上的项目引用了提供 Kubernetes 所需功能的第三方产品或项目。Kubernetes 项目作者不对这些第三方产品或项目负责。有关更多详细信息,请参阅 CNCF 网站指南

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

上次修改时间为太平洋标准时间 2024 年 8 月 30 日凌晨 12:05:删除对已关闭的 containerd issue 的引用 (0909e130d6)