containerd做为k8s的容器运行时配置先决条件
v1.24 之前的 Kubernetes 版本直接集成了 Docker Engine 的一个组件,名为。这种特殊的直接整合不再是 Kubernetes 的一部分 (这次删除被作为 v1.20 发行版本的一部分你可以阅读以了解此删除可能会如何影响你。要了解如何使用 dockershim 进行迁移, 请参阅。如果你正在运行 v1.27 以外的 Kubernetes 版本,查看对应版本的文档。
说明:
v1.24 之前的 Kubernetes 版本直接集成了 Docker Engine 的一个组件,名为 dockershim。 这种特殊的直接整合不再是 Kubernetes 的一部分 (这次删除被作为 v1.20 发行版本的一部分宣布)。
你可以阅读检查 Dockershim 移除是否会影响你以了解此删除可能会如何影响你。 要了解如何使用 dockershim 进行迁移, 请参阅从 dockershim 迁移。
如果你正在运行 v1.27 以外的 Kubernetes 版本,查看对应版本的文档
安装和配置先决条件
以下步骤将通用设置应用于 Linux 上的 Kubernetes 节点。
如果你确定不需要某个特定设置,则可以跳过它。
有关更多信息,请参阅网络插件要求或特定容器运行时的文档。
转发 IPv4 并让 iptables 看到桥接流量
执行下述指令:
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
通过运行以下指令确认 br_netfilter
和 overlay
模块被加载:
lsmod | grep br_netfilter
lsmod | grep overlay
通过运行以下指令确认 net.bridge.bridge-nf-call-iptables
、net.bridge.bridge-nf-call-ip6tables
和 net.ipv4.ip_forward
系统变量在你的 sysctl
配置中被设置为 1:
sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables 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 驱动,需编辑 KubeletConfiguration 的 cgroupDriver
选项,并将其设置为 systemd(一般Linux默认就是systemd可以不需要更改)
。例如:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
说明:
从 v1.22 开始,在使用 kubeadm 创建集群时,如果用户没有在 KubeletConfiguration
下设置 cgroupDriver
字段,kubeadm 默认使用 systemd
。
配置systemd为cgroup驱动程序
kubelet和底层容器运行时(containerd)都需要对接控制组来强制执行为 Pod 和容器管理资源并为诸如 CPU、内存这类资源设置请求和限制。若要对接控制组,kubelet 和容器运行时需要使用一个cgroup 驱动。 关键的一点是 kubelet 和容器运行时需使用相同的 cgroup 驱动并且采用相同的配置。
kubeadm把kubelet视为一个系统服务来管理,所以对基于kubeadm的安装,推荐使用systemd作为cgroup 驱动。
配置 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
说明:
如果你从软件包(例如,RPM 或者 .deb
)中安装 containerd,你可能会发现其中默认禁止了 CRI 集成插件。
你需要启用 CRI 支持才能在 Kubernetes 集群中使用 containerd。 要确保 cri
没有出现在 /etc/containerd/config.toml
文件中 disabled_plugins
列表内。如果你更改了这个文件,也请记得要重启 containerd
。
如果你在初次安装集群后或安装 CNI 后遇到容器崩溃循环,则随软件包提供的 containerd 配置可能包含不兼容的配置参数。考虑按照 getting-started.md 中指定的 containerd config default > /etc/containerd/config.toml
重置 containerd 配置,然后相应地设置上述配置参数。
重载沙箱(pause)镜像
在你的 containerd 配置中, 你可以通过设置以下选项重载沙箱镜像:
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.2"
一般国内设置为阿里的镜像源:
sandbox_image = "registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.6"
一旦你更新了这个配置文件,可能就同样需要重启 containerd
:systemctl restart containerd
。
请注意,声明匹配的 pod-infra-container-image
是 kubelet 的最佳实践。 如果未配置,kubelet 可能会尝试对 pause
镜像进行垃圾回收。 containerd 固定 pause 镜像的工作正在进行中, 将不再需要在 kubelet 上进行此设置。
更多推荐
所有评论(0)