DaemonSet适合什么场景？节点级服务部署实践

在Kubernetes中，并不是所有工作负载都适合按业务副本数部署。有些组件的目标不是“运行3个副本”，而是“每台节点都运行一个”。例如日志采集Agent需要读取本节点容器日志，监控Agent需要采集本节点指标，网络插件需要参与节点网络配置，存储插件节点组件需要处理本机挂载。这类场景正是DaemonSet的核心价值。

DaemonSet会根据选择的节点集合，为每个符合条件的节点创建一个Pod。当新节点加入集群时，DaemonSet会自动补齐；当节点移除时，对应Pod也会消失。理解DaemonSet适合什么场景，可以避免把节点级服务错误地做成Deployment，也能减少基础组件覆盖不全带来的监控盲区和运维风险。相关容器运行机制可结合Docker容器探索一起理解。

什么时候应该使用DaemonSet

判断是否使用DaemonSet，可以看服务是否与节点一一关联。只要服务必须贴近宿主机、需要访问本地路径、需要采集本节点信息，或必须在每个节点上提供基础能力，就适合DaemonSet。

典型场景包括：

• 日志采集：如采集/var/log/containers下的容器日志。
• 监控Agent：采集节点CPU、内存、磁盘、网络和容器运行状态。
• 网络组件：CNI插件、网络策略代理、节点隧道组件。
• 存储节点插件：CSI Node负责本机卷挂载与卸载。
• 安全代理：运行时安全、合规扫描、节点基线检查。

不适合使用DaemonSet的场景也很清楚：普通Web服务、API服务、后台消费者、需要按流量弹性扩缩容的业务组件，通常更适合Deployment。DaemonSet追求的是节点覆盖，不是业务容量弹性。

DaemonSet如何选择节点

DaemonSet默认会在所有可调度节点上创建Pod，但生产环境通常需要更精确控制。例如GPU节点只部署GPU监控组件，边缘节点只部署边缘代理，控制平面节点是否部署日志Agent也要单独评估。

常用控制方式包括nodeSelector、节点亲和性、污点与容忍。一个简化配置如下：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-agent
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: node-agent
  template:
    metadata:
      labels:
        app: node-agent
    spec:
      nodeSelector:
        node-role.kubernetes.io/worker: "true"
      tolerations:
        - operator: Exists
      containers:
        - name: agent
          image: example/node-agent:v1.0.0
          volumeMounts:
            - name: varlog
              mountPath: /var/log
      volumes:
        - name: varlog
          hostPath:
            path: /var/log

hostPath要谨慎使用，因为它让容器访问宿主机目录。日志和监控类组件经常需要它，但应限制挂载路径、权限和容器能力，避免把节点级服务变成安全风险。

与Deployment的关键差异

Deployment关注副本数和发布策略，DaemonSet关注节点覆盖。Deployment可以根据HPA扩容到更多副本，也可以把多个副本调度到同一节点；DaemonSet通常每个目标节点一个Pod，节点数量决定副本数量。

还有一个差异是排障视角。Deployment异常时，常看副本数、滚动发布和服务端点；DaemonSet异常时，要重点看哪些节点没有对应Pod、是否被节点标签、污点、资源不足或调度约束排除。对于基础设施组件，某一台节点缺少DaemonSet Pod，可能意味着这台节点日志不可见、监控缺失或存储挂载失败。

升级DaemonSet要注意什么

节点级服务升级比普通业务更敏感，因为它可能影响整台节点的观测、网络或存储能力。DaemonSet支持滚动更新，可以通过maxUnavailable控制同时不可用的Pod数量。

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 10%

如果集群规模较小，maxUnavailable: 1更直观；如果集群规模较大，百分比可以提高升级效率。关键基础组件升级前，应确认镜像可拉取、配置兼容、资源请求合理，并准备回滚版本。网络插件、存储节点插件和安全代理升级还应先在测试节点或灰度节点验证。

常见问题与排查路径

如果DaemonSet期望节点数与实际可用数不一致，先查看DaemonSet状态：

kubectl get ds -A
kubectl describe ds node-agent -n kube-system
kubectl get pods -n kube-system -l app=node-agent -o wide

若某些节点没有Pod，检查节点是否带有不匹配的标签，是否存在未被容忍的污点，是否资源不足，或是否被亲和性规则排除。若Pod在节点上反复重启，查看容器日志、宿主机路径权限、内核模块、配置文件和依赖服务。若升级卡住，则检查新版本Pod是否通过就绪探针，以及maxUnavailable是否过小导致无法继续推进。

在多租户集群中，还要避免业务团队随意创建高权限DaemonSet。平台侧应通过命名空间、准入控制、Pod安全标准和镜像白名单限制节点级权限，确保只有可信基础组件能够访问宿主机关键路径。

生产实践建议

第一，为节点级服务建立统一命名和命名空间规范，通常放在系统命名空间或平台命名空间。第二，明确每个DaemonSet的节点覆盖目标，使用标签和容忍表达规则，不要依赖口头约定。第三，为关键DaemonSet设置资源请求，避免在节点压力下被优先驱逐。第四，把DaemonSet覆盖率纳入监控，例如目标节点数、就绪Pod数、不可用节点列表。

第五，升级要有灰度策略。可以通过节点标签先让少量节点匹配新版本，验证通过后再扩大范围。对于网络、存储、安全这类强依赖节点能力的组件，升级窗口、回滚镜像、配置兼容性和告警静默都要提前规划。更多容器平台治理思路可参考容器网络和Kubernetes相关实践内容。

小结

DaemonSet适合什么场景？答案是节点级服务场景。只要组件需要在每台目标节点上运行、访问本地资源、提供节点基础能力或采集本节点数据，就应优先考虑DaemonSet。它不是Deployment的替代品，而是为日志、监控、网络、存储和安全等基础设施组件设计的工作负载控制器。用好DaemonSet的关键，不只是创建对象，而是明确节点选择、权限边界、升级策略和覆盖率监控。