Kube-Hetzner项目中Kured重启机制问题分析与解决方案

问题背景

在Kube-Hetzner项目中，Kured作为Kubernetes节点自动重启守护程序，负责在系统需要重启时安全地重启节点。近期从v2.7.2升级到v2.11.7/v2.11.8版本后，用户发现节点不再按预期在配置的时间范围内自动重启。

问题分析

Sentinel文件路径问题

Kured通过检查特定的sentinel文件(通常为/var/run/reboot-required)来判断节点是否需要重启。然而在Kube-Hetzner项目中，主机的/var/run目录被挂载到Pod内的/sentinel路径下，导致Kured无法正确检测到sentinel文件。

事务性更新行为差异

用户还发现，直接执行transactional-update命令与通过systemd服务执行会产生不同的行为：

1. 通过systemd服务执行会创建/var/run/reboot-required文件
2. 直接执行命令则会创建/var/run/reboot-needed文件

这种差异源于systemd服务加载了/etc/transactional-update.conf配置文件，其中设置了REBOOT_METHOD=kured参数，而直接执行命令时未加载这些配置。

解决方案

修正Kured配置

在kured_options中添加正确的sentinel文件路径配置：

kured_options = {
  "reboot-sentinel": "/sentinel/reboot-required"
}

正确执行事务性更新

为确保一致性，建议始终通过systemd服务执行事务性更新：

systemctl start transactional-update.service

技术细节

Kured挂载配置

Kured Pod的挂载配置如下：

• 主机路径：/var/run
• Pod内挂载点：/sentinel
• 只读模式：是

事务性更新服务配置

系统服务文件(/usr/lib/systemd/system/transactional-update.service)关键配置：

• 加载环境文件：/etc/transactional-update.conf
• 执行命令：/usr/sbin/transactional-update
• 服务类型：oneshot

最佳实践建议

1. 升级到最新版本后，务必检查并配置正确的sentinel文件路径
2. 避免直接执行transactional-update命令，应通过systemd服务调用
3. 定期验证Kured日志，确保重启机制正常工作
4. 在非生产环境测试配置变更后再应用到生产集群

通过以上调整，可以确保Kured在Kube-Hetzner项目中正常工作，按预期执行节点重启操作。