[kubernetes]-k8s1.22下docker运行时swap无法使用的原因

导语：分享下大佬分析1.22下docker运行时swap无法使用的原因。

随着裸金属服务器的OS版本不同，swap配置方案会反复横跳。中间也遇到一些问题，本文探讨合理通用配置方案。

目标

1. 分析历史不同配置方案的优劣势，以及为什么能生效
2. 结合k8s设计方向，给出通用的技术整合配置方案

非目标

1. 如何配置kubelet、linux-kernel的swap
2. 具体如何配置组合操作

基础知识

linux与cgroup

1. cgroup（control group）是 Linux 内核中的一个功能，用于对进程进行分组管理和资源限制。
2. 分为v1和v2版本，可通过 GRUB_CMDLINE_LINUX修改版本（增加kernel参数来调整）
3. container基于cgroup实现对linux资源的隔离与管理

systemd与cgroup

1. cgroup-v1需要通过外界直接系统调用 cgroup-v1-api来实现对cgroup的写需求
2. systemd抽象出slice的unit（–type=slice），管理cgroup-v2
3. 可以理解为slice完全管理cgroup-2, 外界需要针对cgroup-v2读写，直接调用systemd-slice的api

kubelet、runtime与cgroup

1. kubelet和runtime（这里指的是container-runtime）作为更高的抽像，需要支持不同OS和版本，支持对cgroup不同版本的读写
2. kubelet和runtime对cgroup的支持必须要一致
   1. 如果不一致，会导致pod级别（kubelet写入）的cgroup和 container级别的cgroup不一致
   2. 如果不一致，kubelet会强制无法启动

docker、containerd、runc、docker-shim、containerd-shim

名称	定义	解决的问题或主要功能	其他
kubelet	k8s中node的daemon程序。用来管理本地node资源。	忽略
docker-shim	kubelet的内部模块。用来启动docker相关	在docker火热且容器化无标准时期，k8s天然支持docker，可使k8s快速发展。
dockerd	docker中用来接受命令的进程。docker daemon	模块化的产物	docker内部架构上接收命令和实际运行容器是分离的，早期是一体的
containerd	容器的生命周期管理进程，兼容OCI的交互。将docker镜像转为oci镜像，并发起启动容器等操作	标准化 （image）	Docker 公司开发，并捐献了云原生计算基金会
runc	OCI的容器运行时实现	标准化 （运行时）	Docker 公司开发，并捐献了云原生计算基金会
containerd-shim	容器的daemon,用来上报状态和后续执行命令	容器进程崩溃或其他情况时，状态的及时上报。保持对容器进程操作的入口

CRI之前k8s的实现

过程：

1. kubelet内部通过grpc调用docker-shim（内部用grpc,说明当时设计者希望将docker-shim独立外部）
2. docker-shim接收到「启动容器」等请求时，将请求转换成dockerd能识别的请求，并通过http restful api发送至dockerd
3. dockerd接收到「启动容器」的请求后，通过grpc调用containerd。
4. containerd收到请求后，将 Docker 镜像转换为 OCI bundle，并让