daemonset是kubernetes中确保每个节点运行一个pod副本的控制器，用于日志收集、监控代理、网络插件等节点级守护进程场景，区别于deployment的任意副本数和pod级调度。
守护进程配置同步，核心在于让分布在不同节点上的服务实例，使用同一套配置、保持行为一致、响应变更及时。它不是简单复制文件，而是建立一套可感知、可推送、可验证的联动机制。
明确配置源与分发路径
必须指定唯一可信的配置源头，比如配置中心（Disconf/Tars）、Git仓库或专用存储（如Consul KV）。所有节点的守护进程不再从本地读取静态配置，而是启动时拉取、运行中监听变更。例如Tars配置中心通过主从复制+增量同步，确保跨区域节点在数秒内获取相同配置；Disconf则依赖ZooKeeper的Watcher机制触发实时通知。
统一身份与权限控制
多个节点上的守护进程需具备一致的身份标识和访问权限，否则同步会因认证失败中断：
- 使用统一的服务账号（如rsync_backup）配合secrets file管理凭据，避免硬编码密码
- SSH免密互信要双向打通（A→B 和 B→A），尤其在双向rsync场景中缺一不可
- 文件权限需匹配守护进程运行用户（如uid/gid设为rsync，则/data/sync_share必须chown -R rsync:rsync）
状态感知与自动重载
配置变了，服务不能还用旧参数跑。守护进程需支持热重载或受控重启：
- inotify-tools + rsync脚本可监听目录变化，触发同步动作；但需配合systemd的Restart=on-failure保障进程存活
- Disconf和Tars客户端内置回调接口（如IDisconfUpdate），配置更新后自动调用业务逻辑重载
- 若采用容器化部署，可通过ConfigMap挂载+livenessProbe探测配置生效状态，必要时触发pod重建
一致性校验与异常兜底
网络抖动、节点宕机、时钟偏差都可能造成短暂不一致，必须有兜底手段：
- 启用配置版本号（如Disconf的version字段、Tars的revision），节点启动时校验本地缓存是否过期
- 设置心跳检测与差异告警（如定期比对MD5或SHA256摘要），发现偏离立即通知运维
- K3s等集群环境需先确保节点时间同步（systemd-timesyncd或chrony），避免因时钟漂移导致证书失效或etcd租约异常
