Kubekey 部署集群时containerd模式下cri-dockerd报错问题分析

问题背景

在使用Kubekey工具部署Kubernetes集群时，用户报告了一个与容器运行时相关的问题。当在配置文件中明确指定使用containerd作为容器运行时(containerManager: containerd)时，部署过程中仍然会触发与cri-dockerd相关的错误。

问题现象

用户在使用Kubekey v3.1.0-alpha版本部署Kubernetes v1.26.13集群时，配置文件中指定了containerManager为containerd，但部署过程中出现了以下错误信息：

get KubeBinary key cri-dockerd by pipeline cache failed
sync cri-dockerd binaries failed

类似的问题在其他用户环境中也有报告，包括使用Kubekey v3.1.0-rc版本部署Kubernetes v1.28.16集群时也出现了相同的错误。

问题原因分析

经过分析，这个问题源于Kubekey的代码逻辑缺陷。在当前的实现中，无论用户选择的是containerd还是docker作为容器运行时，InstallCriDockerdModule模块都会被默认执行，而该模块缺少必要的跳过逻辑。

具体来说，InstallCriDockerdModule模块没有实现IsSkip()方法，导致即使在使用containerd的情况下，Kubekey仍然会尝试同步cri-dockerd的二进制文件，从而引发错误。

解决方案

针对这个问题，社区在Kubekey v3.1.0-rc.1版本中进行了修复。修复的核心是为InstallCriDockerdModule模块添加了IsSkip()方法，使其能够根据配置正确判断是否需要跳过cri-dockerd的安装。

修复代码示例如下：

func (p *InstallCriDockerdModule) IsSkip() bool {
    return p.Skip
}

技术背景知识

1. 容器运行时接口(CRI)：Kubernetes通过CRI与容器运行时交互，containerd和docker(通过cri-dockerd)都实现了CRI接口。

2. cri-dockerd的作用：当使用较新版本的Kubernetes(>=1.24)时，dockershim已被移除，如果仍要使用docker作为运行时，需要通过cri-dockerd这个适配器。

3. Kubekey的模块化设计：Kubekey采用模块化设计，每个功能模块通过实现IsSkip()方法来确定是否需要执行，这使得部署过程更加灵活。

最佳实践建议

1. 对于新部署的集群，建议直接使用containerd作为容器运行时，这是Kubernetes社区推荐的做法。

2. 如果确实需要使用docker作为运行时，确保:

   • 使用Kubekey v3.1.0-rc.1或更高版本
   • 在配置文件中明确指定containerManager为docker

3. 在升级Kubekey版本时，建议先在小规模测试环境中验证，确保兼容性。

总结

这个问题展示了基础设施工具链中配置项与实现逻辑一致性的重要性。Kubekey团队通过添加适当的跳过逻辑，解决了containerd模式下不必要的cri-dockerd安装尝试，提高了工具的健壮性和用户体验。对于用户来说，保持工具版本更新是避免此类问题的有效方法。