负载

Deployment 在意总数，DaemonSet 在意覆盖面：新节点一进池子，同一个服务立刻就在那里。节点级关切——发日志、暴露硬件指标、跑网络 fabric、执行策略——必须处处有，不然等于处处没有。用逐节点脚本或每个 Pod 塞 sidecar 去凑合，立刻就烂：新节点漏掉、版本漂移，没人答得出"哪些节点跑着 agent"而不审计。 DaemonSet 控制器用声明式覆盖弥合这个缝。你把守护进程描述一次，控制器永远把现实收敛到每合格节点一个 Pod，扩集群自动扩守护舰队。覆盖从 runbook 条目变成系统维护的不变量。 每节点一个、天生如此 你把守护进程描述一次，控制器就给每个节点都挂一份副本，这正是节点级日志、指标 agent 与 kube-proxy 这类流量的天然归属。没有需要手工调大小的伸缩旋钮。没有旋钮是特性：副本数一经手压就会从意图漂走，而"每合格节点一个"不会漂——它按节点列表持续重算。新节点注册时 gain Pod，离场释放，被 cordon 的除非 drain 都留着。 因为放置按节点不按容量，DaemonSet Pod 一般要优先级和抢占 headroom，才能在满节点上活下来。给高 PriorityClass、诚实而克制的资源 requests：节点再满它们也必须调度上去，因为过载节点上缺席的监控 agent，恰在最需要 visibility 时致盲。没有需要手工调大小的伸缩旋钮，但调度要做对。 覆盖优先于数量 因为期望副本数本就隐含，一次滚动更新会触及每个成员：往池子里加一个节点，守护进程不用额外动作就自动出现。这是任何逐节点脚本都拼不过的保证。更新用 maxUnavailable 限 disruption 在舰队铺开——设 1 就逐节点刷新，舰队永不断覆盖。节点脚本的慢性病版本漂移，在结构上不可能：控制器把每节点收敛到同一模板，kubectl rollout status ds/agent 告诉你收敛何时完成。 ...

普通 init container 在 Pod 的应用容器启动之前执行准备工作。它有自己的命令、镜像和文件系统视图，也可以挂载应用稍后读取的共享卷。这让前置步骤与主进程分开，但不意味着任意初始化操作都会自动安全，也不意味着重试默认存在固定次数上限。应根据真实重试方式及产物生命周期设计这个步骤，而不是把启动顺序当成完整容错机制。 顺序约束只属于一个 Pod Kubelet 按声明顺序运行普通初始化容器。每一步必须成功结束，下一步才开始，应用容器则等待整个序列完成。检查 initContainerStatuses，才能区分正在等待的步骤、运行中的步骤和已经终止的某次尝试。仅查看 Pod 的阶段，无法说明哪条命令失败，也无法说明新的尝试是否正在进行；排查需要结合具体容器状态和日志。 共享存储需要显式挂载。emptyDir 可以在初始化容器与应用容器之间传递生成文件，并在同一 Pod 内的容器重启期间保留，但会随着 Pod 消失。不同容器不会自动共享镜像根文件系统，只写在初始化容器可写层中的文件，不会自然出现在应用容器里面。产物的写入位置和读取位置必须通过真实卷定义对应起来。 普通初始化容器需要运行到完成。Kubernetes 也支持在 initContainers 中通过容器级 restartPolicy Always 表示可重启边车，它们具有不同生命周期。因此，不能仅因为某个条目位于这个字段，就认定它必须退出后应用才能继续。本例只使用普通初始化容器，不把持续运行的边车混进顺序完成模型。 坏掉的样子 非零退出并不总会让整个 Pod 立即失败。在普通应用 Pod 采用 Always 策略时，失败的普通初始化容器会继续重试，直到成功；已经成功的初始化步骤则不会因为应用仍在运行就不断重启。退避会放慢连续尝试，却不是固定的重试次数限制。如果 Pod 的 restartPolicy 为 Never，初始化失败会使该 Pod 进入失败状态，恢复方式需要另行安排。 准备脚本应能够安全面对前一次留下的内容。中断的下载可能留下半个文件，emptyDir 中的标记也可能在失败进程退出后继续存在。应验证完整产物，再明确交付给消费者。下面用于记录次数的计数器只是诊断数据，不能作为生产逻辑，推断某个外部依赖在第二次尝试时就必然可用。真实条件必须由对应检查来判断。 ...