Kubernetes 笔记 / 入门 / 生产环境 / 容器运行时

目录、参考文献

---

自 1.24 版起，Kubernetes 项目移除了 Dockershim
详见Dockershim 移除的常见问题

为了让 Pod 能够运行，需要在集群的每个节点上安装一个容器运行时

Kubernetes 1.24 要求使用符合容器运行时接口（Container Runtime Interface (CRI)）的运行时

详见 CRI 版本支持

在 Kubernetes 中几个常见的容器运行时：

• containerd
• CRI-O
• Docker Engine
• Mirantis Container Runtime

说明：
v1.24 前的 Kubernetes 发行版包括一个与 Docker Engine 的直接集成
使用一个名为 dockershim 的组件
这种特殊的直接整合不再是 Kubernetes 的一部分 （作为 v1.20 发行版的一部分，被宣布移除）
检查是否受到移除 dockershim 的影响描述了该移除可能会如何影响你
从 dockershim 迁移描述了如何从 dockershim 迁移出来

如果正在运行 v1.24 之外的 Kubernetes 版本，请检查对应版本的文档

安装与配置的前提条件

以下步骤是 Linux 上的 Kubernetes 节点的通用配置

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

更多信息见网络插件要求或特定容器运行时的文档

转发 IPv4 并让 iptables 看到桥接流量

通过 lsmod | grep br_netfilter 命令查看是否加载了 br_netfilter 模块

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

为了让 Linux 节点的 iptables 能够正确查看桥接流量
需要确认 sysctl 配置中的 net.bridge.bridge-nf-call-iptables 是否设置为了 1：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf overlay br_netfilter EOF

sudo modprobe overlay
sudo modprobe br_netfilter

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

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

cgroup 驱动程序

在 Linux 上，控制组（control group）用来限制分配给进程的资源

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

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

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

注意：
更改已加入集群的节点的 cgroup 驱动是一项敏感的操作
如果 kubelet 已经使用某 cgroup 驱动的语义创建了 Pod
此时再改变运行时让其使用其它的 cgroup 驱动
当为这些 Pod 重新创建 Pod 沙箱时会产生错误
重启 kubelet 可能也无法解决此类问题

如果有切实可行的自动化方案，可以用其它已更新配置的节点来替换该节点
或使用自动化方案来重新安装节点

cgroup 版本 2

cgroup v2 是 cgroup Linux API 的下一个版本
与 cgroup v1 不同的是，cgroup v2 只有一个层次结构
而不是每个控制器一个不同的层次结构

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

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

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

如果 systemd 默认没有使用 cgroup v2
可以通过在内核命令行中添加 systemd.unified_cgroup_hierarchy=1 来配置

# 此示例适用于使用 DNF 包管理器的 Linux 操作系统
# 你的系统可能使用不同的方法来设置 Linux 内核使用的命令行
sudo dnf install -y grubby && \
  sudo grubby \
  --update-kernel=ALL \
  --args="systemd.unified_cgroup_hierarchy=1"

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

切换到 cgroup v2 后，用户体验没有明显差异
除非用户直接在节点上或在容器内访问 cgroup 文件系统

为了使用它，CRI 运行时也必须支持 cgroup v2

在 kubeadm 管理的集群中迁移到 systemd

配置一个 cgroup 驱动描述了如何将现有的由 kubeadm 管理的集群迁移到 systemdcgroup 驱动

CRI 版本支持

容器运行时至少需要支持容器运行时接口 v1alpha2

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

容器运行时

说明：
本部分按字母顺序列出了提供 Kubernetes 所需功能的三方项目
Kubernetes 项目的作者不为这些项目负责
想要在列表中添加项目，请在提交变更前阅读内容指南
CNCF website guidelines

containerd

本节概述了使用 containerd 作为 CRI 运行时的必要步骤

用下边的命令在系统上安装 containerd

按照开始使用 containerd 的指示进行操作
创建好有效的配置文件 config.toml 之后，返回此步骤

系统	配置文件路径
Linux	/etc/containerd/config.toml
Windows	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 中配置 runc 使用 systemdcgroup 驱动

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

注意：
如果是通过软件包（如 RPM 或 .deb）来安装的 containerd
CRI 集成插件可能被默认禁用了

要在 Kubernetes 集群中使用 containerd 就需要启用 CRI 支持
要确保 /etc/containerd/config.toml 文件的 disabled_plugins 列表中没有 cri
更改了这个文件后需要重启 containerd

变更配置文件后，通过下边的命令重启 containerd

sudo systemctl restart containerd

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

重载沙箱（pause）镜像

在 containerd 配置中，可以通过设置以下选项重载沙箱镜像

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

更新配置文件后重启 containerd：systemctl restart containerd

CRI-O

本节描述了安装 CRI-O 作为容器运行时的必要步骤

安装 CRI-O 的步骤见 CRI-O 安装说明

cgroup 驱动

CRI-O 默认使用 systemdcgroup 驱动
要切换到 cgroupfscgroup 驱动，需要编辑 /etc/crio/crio.conf
或在 /etc/crio/crio.conf.d/02-cgroup-manager.conf 中放置一个插入式配置：

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

如上所示，conmon_cgroup 也被更改了
当使用 CRI-O 和 cgroupfs 时，必须将其设置为 pod
通常需要保持 kubelet 的 cgroup 驱动（通常通过 kubeadm 完成）与 CRI-O 同步

对于 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

说明：
以下操作假设用 [cri-dockerd](https://github.com/Mirantis/cri-dockerd) 适配器来将 Docker Engine 与 Kubernetes 集成

1. 在每个节点上，遵循安装 Docker Engine 为 Linux 发行版安装 Docker
2. 按照源码仓库中的说明安装 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)

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

重载沙箱（pause）镜像

cri-dockerd 适配器接收一个命令行参数来指定作为 Pod 基础设施容器（“pause image”）的容器镜像，命令行参数是 --pod-infra-container-image

Mirantis 容器运行时

Mirantis 容器运行时（Mirantis Container Runtime (MCR)）是一个商用的容器运行时
以前被称为 Docker 企业版

可以通过 MCR 中包含的开源 [cri-dockerd](https://github.com/Mirantis/cri-dockerd) 组件让 Mirantis 容器运行时与 Kubernetes 一起使用

要了解有关如何安装 Mirantis 容器运行时的更多信息，请查看 MCR 部署指南

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

重载沙箱（pause）镜像

cri-dockerd 适配器接收一个命令行参数来指定作为 Pod 基础设施容器（“pause image”）的容器镜像，命令行参数是 --pod-infra-container-image

下一步

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

---

目录、参考文献