容器运行时

你需要在集群内每个节点上安装一个 容器运行时 以使 Pod 可以运行在上面。本文概述了所涉及的内容并描述了与节点设置相关的任务。

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

有关详细信息,请参阅 CRI 版本支持。 本页简要介绍在 Kubernetes 中几个常见的容器运行时的用法。

安装和配置先决条件

默认情况下,Linux 内核不允许 IPv4 数据包在接口之间路由。 大多数 Kubernetes 集群网络实现都会更改此设置(如果需要),但有些人可能希望管理员为他们执行此操作。 (有些人可能还期望设置其他 sysctl 参数、加载内核模块等;请参阅你的特定网络实施的文档。)

启用 IPv4 数据包转发

手动启用 IPv4 数据包转发:

# 设置所需的 sysctl 参数,参数在重新启动后保持不变
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF

# 应用 sysctl 参数而不重新启动
sudo sysctl --system

使用以下命令验证 net.ipv4.ip_forward 是否设置为 1:

sysctl net.ipv4.ip_forward

cgroup 驱动

在 Linux 上,控制组(CGroup)用于限制分配给进程的资源。

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

当某个 Linux 系统发行版使用 systemd 作为其初始化系统时,初始化进程会生成并使用一个 root 控制组(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 从 1.26 版本开始仅适用于 v1 版本的容器运行时(CRI)API。早期版本默认为 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 驱动

结合 runc 使用 systemd cgroup 驱动,在 /etc/containerd/config.toml 中设置:

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

重载沙箱(pause)镜像

在你的 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"

你还应该注意当使用 CRI-O 时,并且 CRI-O 的 cgroup 设置为 cgroupfs 时,必须将 conmon_cgroup 设置为值 pod。 通常需要保持 kubelet 的 cgroup 驱动配置(通常通过 kubeadm 完成)和 CRI-O 同步。

在 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.6"

这一设置选项支持动态配置重加载来应用所做变更:systemctl reload crio。 也可以通过向 crio 进程发送 SIGHUP 信号来实现。

Docker Engine

  1. 在你的每个节点上,遵循安装 Docker Engine 指南为你的 Linux 发行版安装 Docker。
  1. 请按照文档中的安装部分指示来安装 cri-dockerd

对于 cri-dockerd,默认情况下,CRI 套接字是 /run/cri-dockerd.sock

Mirantis 容器运行时

Mirantis Container Runtime (MCR) 是一种商用容器运行时,以前称为 Docker 企业版。 你可以使用 MCR 中包含的开源 cri-dockerd 组件将 Mirantis Container Runtime 与 Kubernetes 一起使用。

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

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

重载沙箱(pause)镜像

cri-dockerd 适配器能够接受指定用作 Pod 的基础容器的容器镜像(“pause 镜像”)作为命令行参数。 要使用的命令行参数是 --pod-infra-container-image

接下来

除了容器运行时,你的集群还需要有效的网络插件

本页面中的条目引用了第三方产品或项目,这些产品(项目)提供了 Kubernetes 所需的功能。Kubernetes 项目的开发人员不对这些第三方产品(项目)负责。请参阅CNCF 网站指南了解更多细节。

在提交更改建议,向本页添加新的第三方链接之前,你应该先阅读内容指南。

最后修改 December 15, 2024 at 6:24 PM PST: Merge pull request #49087 from Arhell/es-link (2c4497f)