使用k3s-ansible部署K3s集群时遇到的etcd问题解析

问题背景

在使用k3s-ansible项目通过Vagrant部署K3s集群时，用户遇到了一个常见问题：在启动K3s服务时出现失败，错误信息显示"etcd disabled"。这个问题通常发生在多节点集群部署过程中，特别是当使用Vagrant并行启动多个节点时。

错误现象

部署过程中，Ansible任务"Enable and check K3s service"失败，具体错误为：

Job for k3s.service failed because the control process exited with error code

通过查看日志发现关键错误信息：

starting kubernetes: preparing server: etcd disabled

问题原因分析

这个问题的根本原因在于K3s集群的启动顺序和依赖关系：

1. 在K3s集群中，第一个服务器节点(server-0)需要首先完成初始化，因为它会启动etcd服务(如果使用嵌入式etcd)或连接到外部etcd。

2. 其他服务器节点(server-1、server-2等)启动时需要能够连接到第一个节点。

3. 当使用Vagrant默认的并行启动方式时，所有节点会同时启动，导致后续节点在第一个节点尚未完全准备好时就尝试连接，从而失败。

解决方案

针对这个问题，有以下几种解决方法：

方法一：启用顺序启动

修改Vagrantfile，取消以下行的注释：

ENV['VAGRANT_NO_PARALLEL'] = 'no'

这会强制Vagrant按顺序启动节点，确保第一个节点完全启动后再启动其他节点。

方法二：手动重试

即使Ansible部署过程中出现这个错误，集群通常仍然能够正常工作。因为K3s服务会自动重试连接。可以通过SSH登录到各个节点，检查K3s服务状态和集群状态：

sudo kubectl get pods -A

方法三：调整Ansible任务

对于生产环境，可以考虑修改Ansible playbook，增加对第一个节点完全就绪的检查，然后再继续部署其他节点。

深入理解

K3s作为轻量级Kubernetes发行版，其架构设计有一些特点：

1. 嵌入式etcd：K3s默认使用嵌入式etcd作为数据存储，第一个服务器节点会启动etcd服务。

2. 高可用模式：在多服务器部署中，后续节点需要连接到第一个节点的etcd服务。

3. 自动恢复：K3s服务设计有自动重试机制，即使初始连接失败，服务也会持续尝试直到成功。

最佳实践建议

1. 对于测试环境，可以接受这种初始错误，因为集群最终会恢复正常。

2. 对于生产环境或需要严格部署流程的场景，建议：

   • 使用顺序启动方式
   • 在Ansible中添加健康检查
   • 考虑使用外部etcd集群提高稳定性

3. 监控集群状态，确保所有节点最终都成功加入集群。

总结

在使用k3s-ansible部署K3s集群时遇到的etcd相关问题，主要是由于节点启动顺序导致的临时性问题。理解K3s的架构原理和启动流程后，可以通过多种方式解决或规避这个问题。根据实际需求选择合适的解决方案，可以确保集群部署的顺利进行。