Kubespray在ZFS文件系统上部署Kubernetes集群的问题分析与解决方案

问题背景

在使用Kubespray部署Kubernetes集群时，如果将containerd的数据目录(/var/lib/containerd)放在ZFS文件系统上，特别是在Linux 5.x内核环境下，会遇到一系列特殊问题。这是由于ZFS与overlayfs在Linux 5.x内核中的兼容性问题导致的，需要专门使用ZFS快照驱动(zfs snapshotter)来替代默认的overlayfs驱动。

核心问题表现

在部署过程中，主要出现了三个关键问题：

1. kubeadm join失败：节点加入集群时无法连接到本地的API服务器(127.0.0.1:6443)，因为nginx静态Pod没有正常运行。

2. 容器镜像拉取失败：使用ctr命令拉取镜像时出现快照创建错误，提示"missing parent"和"bucket not found"，这是因为没有正确指定ZFS快照驱动。

3. kubelet启动失败：kubelet服务无法启动，报错缺少/etc/kubernetes/ssl/ca.crt文件。

问题根源分析

经过深入排查，发现这些问题的主要根源在于：

1. 快照驱动配置不一致：虽然containerd的配置文件(/etc/containerd/config.toml)中指定了使用zfs快照驱动，但nerdctl和ctr工具在拉取镜像时没有自动继承这一配置，导致仍然尝试使用默认的overlayfs驱动。

2. 引导顺序问题：kubeadm需要先与API服务器通信才能完成引导，但API服务器的代理(nginx)又依赖于kubelet启动静态Pod，而kubelet又需要kubeadm先完成配置，形成了一个循环依赖。

3. 证书文件缺失：在节点加入过程中，某些关键证书文件没有在正确的时间点生成或复制到指定位置。

解决方案

针对这些问题，我们采取了以下解决方案：

1. 统一快照驱动配置：

   • 修改nerdctl的配置文件，确保使用与containerd一致的zfs快照驱动
   • 在所有容器镜像操作命令中显式指定--snapshotter=zfs参数

2. 手动引导流程：

   • 在kubeadm运行前，手动启动一个临时的nginx代理容器，打破循环依赖
   • 确保所有必要的镜像都使用正确的快照驱动预先拉取

3. 清理和重试机制：

   • 在部署前彻底清理节点上的残留配置和文件
   • 确保/etc/containerd/config.toml配置正确且完整

最佳实践建议

基于这次经验，我们总结出在ZFS文件系统上使用Kubespray部署Kubernetes的最佳实践：

1. 统一工具链：考虑在整个部署流程中使用crictl替代nerdctl和ctr，因为crictl作为CRI工具能更好地与Kubernetes生态集成。

2. 预处理检查：在部署前增加对文件系统的检查，如果检测到ZFS，自动调整相关配置。

3. 分阶段验证：将部署过程分为几个可验证的阶段，确保每个阶段的关键组件都正常运行后再继续下一步。

4. 日志收集：增强日志收集机制，特别是在初始引导阶段，便于快速定位问题。

总结

在ZFS文件系统上部署Kubernetes集群确实会遇到一些特殊挑战，但通过深入理解容器运行时的工作原理和Kubernetes的引导流程，这些问题都是可以解决的。关键在于确保整个工具链中快照驱动配置的一致性，以及处理好各个组件之间的启动依赖关系。

这次经验也提醒我们，在生产环境中使用非标准配置时，需要进行更全面的测试和验证。同时，考虑将这些经验反馈到上游项目，帮助完善Kubespray对各种存储后端的支持。