Kubernetes Dockershim

Kubernetes的dockershim组件曾经使得Docker可以作为Kubernetes的容器运行时。这个组件的功能被硬编码到了Kubernetes中，随着容器化成为行业标准，Kubernetes项目增加了对其他运行时的支持，最终实现了容器运行时接口（CRI），让系统组件（如kubelet）以标准化的方式与容器运行时通信。然而，在Kubernetes v1.24版本中，这个内建组件dockershim被移除。

本教程将讲解集群把 Docker 用作容器运行时的运作机制， 并提供使用 dockershim 时，它所扮演角色的详细信息， 继而展示了一组操作，可用来检查移除 dockershim 对工作负载是否有影响。

一、检查应用

即使是通过 Docker 创建的应用容器，也不妨碍在其他任何容器运行时上运行这些容器。 这种使用 Docker 的方式并不构成对 Docker 作为一个容器运行时的依赖。

当用了别的容器运行时之后，Docker 命令可能不工作，或者产生意外的输出。 下面是判定是否依赖于 Docker 的方法。

1、确认没有特权 Pod 执行 Docker 命令（如 docker ps）、重新启动 Docker 服务（如 systemctl restart docker.service）或修改 Docker 配置文件 /etc/docker/daemon.json。

2、检查 Docker 配置文件（如 /etc/docker/daemon.json）中容器镜像仓库的镜像（mirror）站点设置。 这些配置通常需要针对不同容器运行时来重新设置。

3、检查确保在 Kubernetes 基础设施之外的节点上运行的脚本和应用程序没有执行 Docker 命令。 可能的情况有：

• SSH 到节点排查故障；
• 节点启动脚本；
• 直接安装在节点上的监控和安全代理。

4、检查执行上述特权操作的第三方工具。

5、确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响应用。 一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报， 或者在故障排查指令的一个环节中搜索特定的日志信息。 如果有此类配置的工具，需要在迁移之前，在测试集群上测试这类行为。

二、Docker依赖详解

容器运行时是一个软件， 用来运行组成 Kubernetes Pod 的容器。 Kubernetes 负责编排和调度 Pod；在每一个节点上，kubelet 使用抽象的容器运行时接口，所以可以任意选用兼容的容器运行时。

在早期版本中，Kubernetes 提供的兼容性支持一个容器运行时：Docker。 在 Kubernetes 后来的发展历史中，集群运营人员希望采用别的容器运行时。 于是 CRI 被设计出来满足这类灵活性需求 – 而 kubelet 亦开始支持 CRI。 然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件 dockershim。 dockershim 适配器允许 kubelet 与 Docker 交互，就好像 Docker 是一个 CRI 兼容的运行时一样。

切换到 Containerd 容器运行时可以消除掉中间环节。 所有相同的容器都可由 Containerd 这类容器运行时来运行。 但是现在，由于直接用容器运行时调度容器，它们对 Docker 是不可见的。 因此，以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。

注意：

• 不能再使用 docker ps 或 docker inspect 命令来获取容器信息。 由于不能列出容器，因此不能获取日志、停止容器，甚至不能通过 docker exec 在容器中执行命令；
• 如果在用 Kubernetes 运行工作负载，最好通过 Kubernetes API 停止容器， 而不是通过容器运行时来停止它们（此建议适用于所有容器运行时，不仅仅是针对 Docker）。

仍然可以下载镜像，或者用 docker build 命令创建它们。 但用 Docker 创建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。 为了在 Kubernetes 中使用，需要把镜像推送（push）到某镜像仓库。

三、已知问题

1、一些文件系统指标缺失并且指标格式不同

Kubelet /metrics/cadvisor 端点提供 Prometheus 指标。如果安装了一个依赖该端点的指标收集器，可能会看到以下问题：

Docker 节点上的指标格式为 k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>， 但其他运行时的格式不同。例如，在 containerd 节点上它是 <container-id>。

一些文件系统指标缺失，如下所示：

container_fs_inodes_free
container_fs_inodes_total
container_fs_io_current
container_fs_io_time_seconds_total
container_fs_io_time_weighted_seconds_total
container_fs_limit_bytes
container_fs_read_seconds_total
container_fs_reads_merged_total
container_fs_sector_reads_total
container_fs_sector_writes_total
container_fs_usage_bytes
container_fs_write_seconds_total
container_fs_writes_merged_total

2、解决方法

可以通过使用 cAdvisor 作为一个独立的守护程序来缓解这个问题。

• 找到名称格式为 vX.Y.Z-containerd-cri 的最新 cAdvisor 版本（例如 v0.42.0-containerd-cri）；
• 按照 cAdvisor Kubernetes Daemonset 中的步骤来创建守护进程；
• 将已安装的指标收集器指向使用 cAdvisor 的 /metrics 端点。 该端点提供了全套的 Prometheus 容器指标。

替代方案：

• 使用替代的第三方指标收集解决方案；
• 从 Kubelet 摘要 API 收集指标，该 API 在 /stats/summary 提供服务。