容器运行时

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

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

    说明：

    提示：v1.24 之前的 Kubernetes 版本包括与 Docker Engine 的直接集成，使用名为 dockershim 的组件。 这种特殊的直接整合不再是 Kubernetes 的一部分 （这次删除被作为 v1.20 发行版本的一部分）。 你可以阅读检查 Dockershim 弃用是否会影响你 以了解此删除可能会如何影响你。 要了解如何使用 dockershim 进行迁移，请参阅。

    如果你正在运行 v1.24 以外的 Kubernetes 版本，检查该版本的文档。

    以下步骤将通用设置应用于 Linux 上的 Kubernetes 节点。

    如果你确定不需要某个特定设置，则可以跳过它。

    有关更多信息，请参阅网络插件要求 或特定容器运行时的文档。

    通过运行 lsmod | grep br_netfilter 来验证 br_netfilter 模块是否已加载。

    若要显式加载此模块，请运行 sudo modprobe br_netfilter。

    为了让 Linux 节点的 iptables 能够正确查看桥接流量，请确认 sysctl 配置中的 net.bridge.bridge-nf-call-iptables 设置为 1。 例如：

    在 Linux 上，用于限制分配给进程的资源。

    当某个 Linux 系统发行版使用 systemd 作为其初始化系统时，初始化进程会生成并使用一个 root 控制组（cgroup），并充当 cgroup 管理器。 Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup。 你也可以配置容器运行时和 kubelet 使用 cgroupfs。 连同 systemd 一起使用 cgroupfs 意味着将有两个不同的 cgroup 管理器。

    单个 cgroup 管理器将简化分配资源的视图，并且默认情况下将对可用资源和使用 中的资源具有更一致的视图。 当有两个管理器共存于一个系统中时，最终将对这些资源产生两种视图。 在此领域人们已经报告过一些案例，某些节点配置让 kubelet 和 docker 使用 cgroupfs，而节点上运行的其余进程则使用 systemd; 这类节点在资源压力下 会变得不稳定。

    更改设置，令容器运行时和 kubelet 使用 作为 cgroup 驱动，以此使系统更为稳定。 对于 Docker, 设置 native.cgroupdriver=systemd 选项。

    注意：更改已加入集群的节点的 cgroup 驱动是一项敏感的操作。 如果 kubelet 已经使用某 cgroup 驱动的语义创建了 pod，更改运行时以使用 别的 cgroup 驱动，当为现有 Pods 重新创建 PodSandbox 时会产生错误。 重启 kubelet 也可能无法解决此类问题。 如果你有切实可行的自动化方案，使用其他已更新配置的节点来替换该节点， 或者使用自动化方案来重新安装。

    Cgroup v2

    新版本对 cgroup v1 进行了多项改进，其中一些改进是：

    • 更简洁、更易于使用的 API
    • 可将安全子树委派给容器
    • 更新的功能，如压力失速信息（Pressure Stall Information）

    尽管内核支持混合配置，即其中一些控制器由 cgroup v1 管理，另一些由 cgroup v2 管理， Kubernetes 仅支持使用同一 cgroup 版本来管理所有控制器。

    如果 systemd 默认不使用 cgroup v2，你可以通过在内核命令行中添加 systemd.unified_cgroup_hierarchy=1 来配置系统去使用它。

    如果更改内核的命令行，则必须重新启动节点才能使更改生效。

    切换到 cgroup v2 时，用户体验不应有任何明显差异， 除非用户直接在节点上或在容器内访问 cgroup 文件系统。 为了使用它，CRI 运行时也必须支持 cgroup v2。

    如果你希望将现有的由 kubeadm 管理的集群迁移到 systemd cgroup 驱动程序， 请按照配置 cgroup 驱动程序操作。

    你的容器运行时必须至少支持容器运行时接口的 v1alpha2。

    Kubernetes 1.24 默认使用 v1 的 CRI API。如果容器运行时不支持 v1 API， 则 kubelet 会回退到使用（已弃用的）v1alpha2 API。

    说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

    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 使用 cgroup 驱动，在 /etc/containerd/config.toml 中设置

    当使用 kubeadm 时，请手动配置 kubelet 的 cgroup 驱动.

    本节包含安装 CRI-O 作为容器运行时的必要步骤。

    要安装 CRI-O，请按照 执行操作。

    cgroup 驱动程序

    CRI-O 默认使用 systemd cgroup 驱动程序，这对你来说可能工作得很好。要切换到 cgroupfs cgroup 驱动程序， 请编辑 /etc/crio/crio.conf 或在 /etc/crio/crio.conf.d/02-cgroup-manager.conf 中放置一个插入式配置 ，例如：

    你还应该注意到 conmon_cgroup 被更改，当使用 CRI-O 和 cgroupfs 时，必须将其设置为值 pod。 通常需要保持 kubelet 的 cgroup 驱动配置（通常通过 kubeadm 完成）和 CRI-O 同步。

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

    Docker Engine

    说明： 以下操作假设你使用 cri-dockerd 适配器来将 Docker Engine 与 Kubernetes 集成。

    1. 按照源代码仓库中的说明安装 。

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

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

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

    检查名为 的 systemd 单元以找出 CRI 套接字的路径。

    除了容器运行时，你的集群还需要有效的。

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

    在提交更改建议，向本页添加新的第三方链接之前，你应该先阅读