DaemonSet

Deployment 主要表达副本总数，DaemonSet 主要表达合格节点的覆盖范围，适合节点日志采集、网络代理和设备插件。新节点符合条件后会触发协调工作，不代表服务立刻运行或就绪。节点选择、调度容量、镜像拉取、初始化和节点故障，都可能延迟真正有用的覆盖；这些环节需要分别观察。 控制器根据共享模板创建并协调 Pod，通常以每个合格节点一个受管理 Pod 为期望，而不是依赖手工维护副本总数。期望覆盖与实际就绪是两种指标。还应独立定义运维希望覆盖的节点集合，避免选择器写错后，被排除的机器同时从期望数和审计视野中消失。 每节点一个、天生如此 控制器评估节点选择器与必要亲和条件，为每个合格节点创建定向 Pod，通常再由调度器绑定。节点加入和离开会改变期望集合。DaemonSet Pod 自动容忍 unschedulable 污点，因此只执行 cordon 不会排除它们。节点注册并不保证调度、镜像获取和初始化在同一时刻完成，也不保证每台机器已经具备可用日志采集能力。 优先级可以帮助重要守护进程抢占低优先级工作负载，却不会创造容量或消除冲突的放置条件。应按真实重要性和业务影响选择 PriorityClass 与资源请求。Pod 可能一直 Pending，也可能调度后启动失败；高优先级和容忍都不能证明已经就绪，更不意味着免受节点压力驱逐。 覆盖优先于数量 RollingUpdate 会按策略替换 Pod；OnDelete 则等待旧 Pod 被删除后，才使用更新模板创建替代者。maxSurge 为零时，maxUnavailable 为一允许某个节点在更新期间暂时不可用，并不保证每节点不断档。非零 maxSurge 可以让同一节点暂时同时运行新旧 Pod，需要额外资源。更新期间存在版本差异是正常现象，阻塞会使差异持续。kubectl rollout status ds/agent 报告控制器进度，不能证明日志交付连续。 选择器与亲和可以把异构节点分成有意定义的子集，GPU 设备插件与边缘日志转发器不一定使用同一个 DaemonSet。检查各子集真正应该包含哪些节点，区分有意排除与预期代理缺席。跨池比较前还要确认标签来源可靠，不能把一个看起来合理的标签直接当成硬件或运行能力证明。 跟着节点生命周期走 控制器会自动添加文档规定的容忍，包括 not-ready、unreachable、若干压力污点及 unschedulable。控制平面或硬件自定义污点仍可能需要显式容忍。容忍只是允许跨过匹配污点，不会主动选择节点，也不保证满足其他约束。标签变化可能改变成员集合；应观察实际协调结果，不能假定不同守护集合之间是原子交接。 ...