Kubernetes中选择Deployment而非DaemonSet的适用场景有哪些

两者的核心定位差异决定了适用场景完全不同，Deployment 更适合以下几类场景：

• 不需要全节点部署的普通无状态业务
  比如对外提供服务的Web接口、前端静态资源服务、业务逻辑微服务，这类服务只需要总副本数满足流量承载要求即可，不需要每个集群节点都运行一个实例。用Deployment可以灵活调整副本数量，避免DaemonSet强制每个节点跑一个实例造成的资源浪费，比如集群有200个节点，业务峰值只需要30个副本就能扛住流量，用DaemonSet会额外产生170个无效实例，白白占用算力和内存资源。
• 需要按业务负载弹性伸缩的服务
  Deployment 天然支持配合HPA（水平Pod自动扩缩容），可以根据CPU、内存使用率，或者QPS、消息队列堆积量等自定义业务指标，自动调整副本数量，完美匹配流量波动，比如大促时段自动扩容到100副本，低峰期自动缩容到10个副本。而DaemonSet的副本数和集群节点数强绑定，无法根据业务负载单独调整，完全不支持这类弹性需求。
• 对单节点副本部署数量无强制限制的业务
  很多业务没有「同节点不能部署多个同服务Pod」的强制要求，甚至同节点部署多副本还能提升节点资源利用率，比如轻量的定时任务调度服务、内部工具类接口，用Deployment调度时可以把多个副本调度到资源富余的节点，不需要强制打散到所有节点，资源分配的灵活性更高。
• 对发布策略有灵活要求的迭代类业务
  虽然DaemonSet也支持滚动更新，但Deployment的发布能力更丰富，支持自定义maxSurge、maxUnavailable参数控制发布速度，还能配合流量治理组件实现灰度放量、按比例切分流量，版本回滚的粒度也更精细，更适合需要频繁迭代的对外服务。DaemonSet的更新逻辑和节点绑定，很难做到按比例放量新版本，发布风险更高。
• 有自定义调度规则的业务
  如果业务只需要运行在部分特定节点上，比如GPU计算任务只需要跑在带GPU标签的节点，用Deployment可以配合nodeSelector、节点亲和/反亲和规则灵活选择调度范围，只要副本数满足需求即可，不需要强制覆盖所有符合条件的节点，调度规则的灵活性远高于DaemonSet。

内容的提问来源于stack exchange，提问作者Maguro