当前位置：首页 > news >正文

详细介绍：【k8s】Deployment、StatefulSet、DaemonSet

news 2026/5/11 18:33:44

详细介绍：【k8s】Deployment、StatefulSet、DaemonSet

请你讲一下 Kubernetes 中 Deployment、StatefulSet、DaemonSet 的区别／适用场景，并说明它们和 Pod 的关系。

回答：首先，在 Kubernetes 中 Pod 是最基本的运行单元，一个 Pod 封装一个或多个容器。但在生产环境中我们几乎不会直接创建单个 Pod 来部署服务，因为这样 Pod 崩溃后不会自动恢复，也无法滚动更新或扩缩容，而是通过控制器（controller）来管理 Pod 的生命周期、数量、更新、扩缩等，以实现声明式管理、自动修复等能力。常见的工作负载控制器包括 Deployment、StatefulSet 和 DaemonSet。

Deployment 适用于无状态应用最通用的选择。例如：用户服务、前端、后端微服务、API，能快速水平扩缩容并拥护无缝滚动更新就是（stateless）。使用 Deployment 时，你定义 replicas （期望副本数）、Pod 模板、更新策略等，环境会保证始终有指定数量的这些 Pod 运行、自动替换失败的 Pod 、支持滚动更新和回滚。因为 Pod 之间没有固定身份、可以互换、也不依赖于本地存储，因而 Deployment
StatefulSet 适用于有状态应用（stateful）：这些应用每个实例可能都有固定身份（例如数据库主从、Kafka broker 等）、需要稳定网络标识（hostname、DNS 名）和持久化存储。StatefulSet 为每个 Pod 提供稳定的 ordinal 索引（例如 app-0、app-1）、稳定主机名、各自的 PersistentVolumeClaim 、并且帮助按序创建与销毁。因为这些特性，StatefulSet 比 Deployment 更适合那类需要状态和身份的服务。例如：想部署一个数据库集群（Postgres、MySQL）、消息队列（Kafka）、分布式存储（Etcd、Cassandra）——— 得稳定 ID、稳定存储、顺序启动/下线。
DaemonSet的用途则不同：它保证在集群中每个（或符合条件的）节点上都运行一个 Pod 副本。换句话说，当你要求在每一台节点上统一部署一个节点代理、日志收集器、监控 agent 、网络插件等时，就用 DaemonSet。加入新的节点时，DaemonSet 会自动在该节点上创建 Pod；节点移除时，Pod 也自动回收。例如：想在每一台节点安装日志收集或监控 agent，用 DaemonSet。

总结一下它们与 Pod 的关系：我们通过控制器指定 Pod 模板与期望状态，控制器负责 Pod 的实际创建、删除、更新、调度逻辑，从而让 Pod 不再是孤立管理。选择哪一个控制器，取决于你的 Pod 是否需要固定身份／持久存储／节点级别部署。

通过deployment部署服务，如何保证零宕机的更新？

回答：在生产环境中，大家一般借助Deployment 的滚动更新（RollingUpdate）策略实现零宕机。
通常配置 maxSurge=1、maxUnavailable=0，保证更新时先启动一个新 Pod，待其通过 readinessProbe后才删除旧 Pod，整个过程中副本数始终不变。

readinessProbe控制流量接入，确保服务依赖加载、初始化搞定后才接收请求；
preStop 钩子 和 terminationGracePeriodSeconds 实现优雅下线，让旧 Pod 在退出前处理完正在执行的请求；
多副本（replicas≥2）和PodDisruptionBudget则保证即使节点维护或批量更新，也不会影响整体可用性。

实际上线大家常采用分批滚动（系统不会一次性替换所有 Pod，而是按批次逐步替换）或金丝雀发布（先小部分 Pod + 少量流量，逐步扩大），通过监控指标（如 QPS、错误率、延迟）判断稳定后再继续推广，如有异常可敏捷rollout undo 回滚。

整个过程中新 Pod 就绪后接流量，旧 Pod 结束请求后退出，对外请求无感知，从而实现真正的零宕机更新。

那 readinessProbe 是怎么影响 Service 流量的？

回答：readinessProbe 的核心作用是控制 Pod 是否接收流量。
探针未通过，Pod 状态变为 NotReady，Service 控制器就会自动将该 Pod 从 endpoints 中移除，新的请求不会再打到它。就是Kubernetes 的 kubelet 会根据 readinessProbe 的结果更新 Pod 的就绪状态，要

当探针恢复通过后，Pod 会重新加入到 endpoints 列表，开始接收流量。
此种机制让大家在滚动更新、新版本上线或服务初始化期间能够优雅地控制流量分配，实现真正的零宕机更新。

生产环境中，readinessProbe 通常会配合 preStop 钩子、terminationGracePeriodSeconds 一起使用，确保旧实例优雅退出、新实例准备就绪后再接入流量。