Kured 1.15.1 版本在K3s集群中的自动重启问题分析与解决方案

问题背景

Kured（Kubernetes Reboot Daemon）是一个用于Kubernetes集群节点自动重启的开源工具。在K3s v1.29.2集群（基于Alma Linux 9）中部署Kured v1.15.1版本后，发现其自动重启功能未能按预期工作。该集群采用高可用架构，包含3个控制平面节点和1个工作节点。

配置详情

Kured的配置参数如下：

• 使用/sentinel/reboot-required作为重启信号文件
• 设置了详细的操作消息模板
• 允许每天任何时间重启（--reboot-days=sun,mon,tue,wed,thu,fri,sat）
• 重启延迟设置为90秒
• 重启时间窗口为晚上10点至凌晨1点（美国芝加哥时区）

问题现象

测试过程中，在控制平面节点和工作节点上创建了/var/run/reboot-required文件，但观察到以下异常情况：

1. 工作节点（abal-kuber04）尝试驱逐Pod时遇到PDB（Pod Disruption Budget）限制，导致节点被标记为不可调度但未能完成重启
2. 控制平面节点（abal-kuber03）检测到需要重启，但因工作节点持有锁而无法继续
3. 系统未能在PDB阻止后自动恢复工作节点的调度状态

技术分析

PDB限制的影响

Kubernetes的PDB机制旨在确保关键工作负载的可用性。当Kured尝试驱逐受PDB保护的Pod时，系统会拒绝驱逐请求。默认情况下，Kured会持续重试而不会超时或放弃，这可能导致节点长时间处于不可调度状态。

锁机制行为

Kured使用分布式锁来协调集群中的重启操作。在观察到的工作节点持有锁的情况下，其他节点（包括控制平面节点）无法获取锁进行重启，即使工作节点因PDB限制而无法完成重启流程。

时间窗口配置

虽然配置允许全天任何时间重启，但实际重启操作被限制在指定的时间窗口内（晚上10点至凌晨1点）。这可能导致在测试时间外检测到的重启需求被延迟处理。

解决方案

强制重启选项

对于受PDB限制的环境，可以考虑启用--force-reboot=true参数。此选项会使Kured忽略PDB限制强制重启节点，但需谨慎评估对业务连续性的影响。

超时与回退机制

当前版本中，Kured缺乏对PDB限制情况的智能处理。理想情况下，应实现以下改进：

1. 为驱逐操作设置超时机制
2. 在遇到不可解决的PDB冲突时自动放弃并恢复节点状态
3. 实现优先级机制，允许其他节点在持有锁节点受阻时接管重启任务

测试建议

在生产环境实施前，建议：

1. 临时禁用非关键工作负载的PDB进行测试
2. 验证--force-reboot参数的实际效果
3. 监控重启过程中关键指标的异常情况

最佳实践

对于类似架构的K3s集群，推荐以下Kured配置策略：

1. 为控制平面和工作节点分别配置不同的重启策略
2. 设置合理的重启时间窗口，避开业务高峰
3. 为关键工作负载配置适当的PDB值，平衡可用性与可维护性需求
4. 考虑实现自定义的预处理脚本处理特殊Pod的优雅终止

通过以上分析和调整，可以显著提高Kured在复杂Kubernetes环境中的可靠性和实用性。