同步近期 containerd 的高频问题
最近 Issue 8698 有用户说容器启动和清理都偏慢,尤其多个 Pod 同时启动时现象特别明显。之前有过类似的问题: containerd 启动容器前,它需要临时挂载 rootfs 来读取 uid/gid 信息。因为挂载的是可写属性的 overlayfs,卸载时内核会强制刷盘。当系统大量的脏页数据需要回写时,这个刷盘动作容易造成系统卡顿。 oci: use readonly mount to read user/group info 已经解决读取 uid/gid 的性能问题了,但这一次是 Pod Init-container 带来的 。 Init-container rootfs 大部分都是可写模式的 overlayfs,如果 Init-container 是做数据预下载的话,那么 containerd 在删除 Init-container 时,内核一定会刷盘。在大部分场景下,同一个节点上的 Pod 共享同一块数据盘,这种不预期的刷盘很容易把系统打崩。还有 Issue 8647 用户说,他的系统一开始还好好的,跑几天就不稳定了。后来查看他提供的日志,发现有几个 Pod 一直启动失败,相当于每隔几秒都要去刷盘,导致整个系统不稳定。 这个问题的最佳解决方案应该是做好 Pod 的存储隔离,但显然这成本确要高不少。然而 Kubernetes 场景下的容器并不会重启,即使在「失败后无限重启」的策略下,kubelet 依然是删除重建,这也意味着容器 rootfs 并不需要持久化。个人觉得,成本最低的解决方案应该是使用 overlayfs-volatile-mount,它需要 Linux Kernel ≥ 5.10。以下是个人目前了解到的情况,大部分云厂家都支持了 overlayfs-volatile。 Azure Ubuntu 22.04 LTS - Kernel 5.15 (GA) AWS Kubernetes ≥ 1....