k8s 中的 deployment，statefulset，daemonset 控制器的区别

发布于：2025-07-26 ⋅ 阅读:(17) ⋅ 点赞:(0)

1. Deployment：无状态应用的守护者

核心目标：管理无状态应用的 Pod 副本，提供滚动更新、回滚和扩缩容能力。
关键特性：

  • 副本管理：确保指定数量（replicas）的 Pod 始终运行。

  • 滚动更新：逐步替换 Pod，实现零停机更新。

  • 回滚能力：一键回滚到历史版本。

  • 随机 Pod：Pod 名称和 IP 不固定（如 nginx-deploy-5d89bdfb54-7xqkz）。

  • 存储共享：所有 Pod 挂载相同的存储（PVC），无数据绑定关系。

适用场景：
✅ Web 服务器（Nginx、Apache）
✅ API 微服务
✅ 无状态计算任务（Worker）

示例YAML：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3  # 维持 3 个 Pod 副本
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25

2. StatefulSet：有状态应用的基石

核心目标：管理有状态应用（如数据库、消息队列），提供稳定的网络标识、持久化存储和有序部署。
关键特性：

  • 稳定标识：Pod 名称固定（如 mysql-0、mysql-1），DNS 记录唯一（mysql-0.mysql-svc）。

  • 独立存储：每个 Pod 绑定专属 PVC（数据与 Pod 生命周期解耦）。

  • 有序操作：

    • 部署/扩容：按序号升序（0→1→2）启动 Pod。

    • 删除/缩容：按序号降序（2→1→0）终止 Pod。

    • 更新：逆序（2→1→0）滚动更新。

  • 需配合 Headless Service：用于生成稳定的 DNS 记录。

有状态应用的典型场景包括：
✅ 数据库集群（MySQL、MongoDB）
✅ 消息系统（Kafka、RabbitMQ）
✅ 协调服务（ZooKeeper、etcd）
✅ 分布式存储（Ceph、MinIO）
✅ AI 训练/服务（模型检查点、分布式训练）
✅ 传统企业应用（SAP、Oracle）

一、数据库系统

1. 关系型数据库集群

  • 场景：高可用、读写分离、数据分片

  • 案例：

    • MySQL：主从复制（mysql-0 为主节点，mysql-1/mysql-2 为从节点）

    • PostgreSQL：流复制集群（通过 Patroni 管理）

  • 状态需求：

    • 每个节点有独立数据目录（PVC）

    • 从节点通过固定 DNS（如 mysql-1.mysql-svc）连接主节点

2. NoSQL 数据库

  • 场景：分布式存储、水平扩展

  • 案例：

    • MongoDB：副本集（Replica Set）或分片集群（Sharded Cluster）

    • Cassandra：多节点环状拓扑（需种子节点 cassandra-0 初始化集群）

  • 状态需求：

    • 节点通过唯一标识加入集群（如 cassandra-0.cassandra-svc）

    • 每个节点存储局部数据（分片或副本）

二、消息队列与流处理平台

1. 消息队列

  • 场景：解耦服务、异步通信、流量削峰

  • 案例：

    • Kafka：Broker 集群（每个 Broker 有独立日志存储）

    • RabbitMQ：镜像队列（Mirrored Queues）

  • 状态需求：

    • Broker 需绑定专属存储（如 Kafka 的 log.dirs 目录）

    • 客户端通过固定地址连接特定 Broker（如 kafka-1.kafka-svc:9092）

2. 流处理引擎

  • 场景：实时数据分析、事件驱动架构

  • 案例：

    • Apache Flink：JobManager + TaskManager 集群

    • Spark Structured Streaming：需持久化检查点（Checkpoint）

  • 状态需求：

    • 检查点/状态后端存储（如 RocksDB 数据目录）

    • 主节点（JobManager）需稳定网络标识 

三、分布式协调与配置服务

1. 协调服务

  • 场景：服务发现、分布式锁、领导者选举

  • 案例：

    • ZooKeeper：奇数节点集群（如 3/5 节点）

    • etcd：Kubernetes 的键值存储后端

  • 状态需求：

    • 节点有序启动（zk-0 先启动初始化集群）

    • 每个节点存储事务日志（WAL）和快照

2. 配置中心

  • 场景：集中管理微服务配置

  • 案例：

    • Consul：服务网格控制平面

    • Nacos：动态配置管理

  • 状态需求：

    • 配置数据持久化（如 Raft 日志）

    • 集群节点间通过固定 DNS 通信

四、分布式存储系统

1. 块/文件存储

  • 场景：云原生存储解决方案

  • 案例：

    • Ceph：OSD（对象存储守护进程）集群

    • MinIO：分布式对象存储

  • 状态需求：

    • 每个存储节点管理本地磁盘（PVC）

    • OSD 节点需唯一标识（如 ceph-osd-0）

2. 时序数据库

  • 场景：监控指标存储（如 Prometheus 长期存储）

  • 案例：

    • VictoriaMetrics：集群模式

    • InfluxDB：企业版集群

  • 状态需求：

    • 分片数据本地存储

    • 节点通过 DNS 发现彼此

五、有状态中间件与业务系统

1. 业务中间件

  • 场景：会话保持、用户状态管理

  • 案例：

    • Redis Sentinel/Cluster：主从节点数据持久化

    • Memcached：需一致性哈希分片（非必须但有状态部署更稳定）

2. 传统企业应用

  • 场景：ERP、CRM 等系统容器化

  • 案例：

    • SAP HANA：内存数据库集群

    • Oracle RAC：需共享存储（通过 CSI 驱动挂载）

  • 状态需求：

    • 许可证绑定固定节点

    • 事务日志持久化

六、AI/机器学习平台

1. 分布式训练

  • 场景：大模型训练（如 PyTorch DDP）

  • 案例：

    • GPU 集群管理：每个 Worker 保存训练检查点

  • 状态需求：

    • Checkpoint 存储到 PVC（防止训练中断丢失进度）

    • Worker 通过固定 IP 通信（加速 RDMA 网络）

2. 模型服务

  • 场景：大型模型加载（如 LLM）

  • 案例：

    • TensorFlow Serving：每个实例加载独立模型

  • 状态需求：

    • 模型文件持久化（单个模型可达 100GB+）

    • 服务实例需稳定地址（避免重复加载模型）

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql-svc  # 关联 Headless Service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:   # 每个 Pod 创建独立 PVC
  - metadata:
      name: data
    spec:
      storageClassName: ssd
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 20Gi

为什么这些场景必须用 StatefulSet？

需求 Deployment 不足 StatefulSet 解决方案
稳定网络标识 Pod IP/名称变化导致集群分裂 固定 DNS (<pod>.<svc>)
独立持久化存储 所有 Pod 共享相同数据（导致混乱） 每个 Pod 绑定专属 PVC (data-pod-0)
有序启停/扩缩容 并行操作引发竞争（如脑裂） 按序号顺序操作（0→1→2 启动）
集群初始化依赖 无协调机制 序号 0 的 Pod 优先初始化集群配置

 

 3. DaemonSet：节点级服务的管家

核心目标：确保每个 Node 节点（或满足条件的节点）上都运行一个指定的 Pod。
关键特性：

  • 节点全覆盖：新节点加入时自动部署 Pod，节点移除时自动删除 Pod。

  • 特殊节点约束：可通过 nodeSelector 或污点容忍（tolerations）控制部署范围。

  • 无副本数概念：Pod 数量等于匹配的节点数量。

  • Pod 命名规则：名称包含节点名（如 fluentd-5xqkz）。

适用场景：
✅ 节点监控代理（Prometheus Node Exporter）
✅ 日志收集器（Fluentd、Filebeat）
✅ 网络插件（Calico、Cilium）
✅ 存储守护进程（GlusterFS）

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-logs
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master  # 允许部署到 Master 节点
        effect: NoSchedule
      containers:
      - name: fluentd
        image: fluentd:latest
      nodeSelector:
        logging: "true"  # 仅部署到带此标签的节点

三者的核心区别总结

特性 Deployment StatefulSet DaemonSet
设计目标 管理无状态应用副本 管理有状态应用集群 每个节点部署一个系统级 Pod
Pod 名称 随机（如 web-5d89bdfb54-7xqkz） 稳定有序（如 redis-0） 随机但含节点信息（如 fluentd-xyz）
网络标识 通过 Service 负载均衡 唯一 DNS（pod-name.svc-name） 无特殊网络标识
存储 所有 Pod 共享相同存储 每个 Pod 独立 PVC 通常使用 HostPath 或独立 PVC
扩缩容 直接调整 replicas，无序创建/删除 按顺序扩缩（升序创建/降序删除） 随节点数量自动变化
更新策略 滚动更新（并行替换） 有序滚动更新（逆序更新） 滚动更新（默认并行）
典型场景 Web 服务、API 服务 数据库、消息队列 日志收集、节点监控、网络插件

选择指南

  • 需要运行无状态服务，且需灵活扩缩容/更新？ → Deployment

  • 需要运行有状态集群（如数据库），要求稳定网络/存储？ → StatefulSet

  • 需要在每个节点上运行系统级守护进程（如日志代理）？ → DaemonSet

网站公告

今日签到

点亮在社区的每一天
去签到

热门文章

最新发布