K8s Pod调度基础——2
目录
一、Deployment
一、Deployment 原理
二、核心特性
三、意义与场景
四、示例与逐行解释
五、总结
StatefulSet
一、StatefulSet 原理
二、核心特性
三、意义与场景
四、示例与逐行解释
五、总结
彼此的区别
一、本质区别
二、核心特性对比
1. Pod 标识与网络
2. 存储管理
3. 扩缩容与更新
4. 服务发现
三、运维约束对比
四、强制使用 StatefulSet 的场景
五、总结
一、Deployment
一、Deployment 原理
-
核心功能:
- 管理 无状态应用 的 Pod 副本集(通过控制 ReplicaSet 实现),支持声明式更新、滚动升级和回滚。
- 通过 控制器模式 监听集群状态,确保实际 Pod 数量与期望值一致。
-
工作流程:
- 版本控制:每次更新会创建新的 ReplicaSet,逐步替换旧 Pod(滚动更新)或直接全量替换(重建更新)。
- 回滚机制:记录历史版本,可快速回退到任意修订版本。
二、核心特性
特性 | 说明 |
---|---|
多副本管理 | 通过 replicas 字段维持指定数量的 Pod,自动扩缩容。 |
滚动更新 | 支持逐步替换旧 Pod(可配置 maxUnavailable 和 maxSurge )。 |
版本回滚 | 使用 kubectl rollout undo 回退到历史版本。 |
健康检查 | 集成 Liveness/Readiness 探针,确保服务可用性。 |
暂停与恢复 | 暂停更新(kubectl rollout pause )以手动调试。 |
三、意义与场景
- 意义:
- 实现应用发布的零停机更新,提升 DevOps 效率。
- 为微服务提供高可用、自愈的底层支撑。
- 典型场景:Web 服务、API 后端、无状态计算任务等。
四、示例与逐行解释
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginxspec:replicas: 3selector:matchLabels:app: nginxstrategy:type: RollingUpdaterollingUpdate:maxUnavailable: 1maxSurge: 1template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.19ports:- containerPort: 80livenessProbe:httpGet:path: /port: 80initialDelaySeconds: 5periodSeconds: 10
逐行解释:
apiVersion: apps/v1
:使用apps
组的 API 版本。kind: Deployment
:声明资源类型为 Deployment。replicas: 3
:维持 3 个 Pod 副本。selector.matchLabels
:选择标签为app=nginx
的 Pod 管理。strategy
:定义滚动更新策略,最多允许 1 个 Pod 不可用(maxUnavailable
)和 1 个临时超额 Pod(maxSurge
)。template
:Pod 模板,包含容器配置(Nginx 1.19 镜像)和健康检查(每 10 秒检测 80 端口)。
五、总结
Deployment 是 Kubernetes 管理无状态应用的核心控制器,通过自动化副本管理、滚动更新和回滚机制,显著提升应用部署的可靠性和灵活性。
StatefulSet
一、StatefulSet 原理
-
核心功能:
- 管理有状态应用(如数据库、消息队列),为每个 Pod 提供稳定的唯一标识(有序编号、持久化存储、固定网络标识)。
- 通过 Headless Service 为每个 Pod 分配唯一的 DNS 记录(如
pod-name.svc-name.namespace.svc.cluster.local
)。
-
工作流程:
- 有序部署/扩缩容:Pod 按顺序创建(从 0 到 N-1)或删除(从 N-1 到 0),确保依赖关系(如主从数据库)。
- 持久化存储:通过
volumeClaimTemplates
为每个 Pod 动态绑定独立的 PersistentVolume(PV)。
二、核心特性
特性 | 说明 |
---|---|
稳定标识 | Pod 名称(如 web-0 、web-1 )和 DNS 记录在生命周期内保持不变。 |
有序管理 | 支持顺序启停(OrderedReady )或并行(Parallel )策略。 |
持久化存储 | 每个 Pod 绑定独立的 PV,数据不受 Pod 重建影响。 |
网络稳定性 | 通过 Headless Service 提供固定网络端点。 |
三、意义与场景
- 意义:
- 解决有状态应用的数据持久性和拓扑稳定性问题,填补 Deployment 的不足。
- 典型场景:MySQL 集群、MongoDB 副本集、ZooKeeper 等分布式系统。
四、示例与逐行解释
apiVersion: apps/v1
kind: StatefulSet
metadata:name: mysql
spec:serviceName: mysql-headlessreplicas: 3selector:matchLabels:app: mysqltemplate:metadata:labels:app: mysqlspec: containers:- name: mysqlimage: mysql:5.7ports:- containerPort: 3306volumeMounts:- name: mysql-datamountPath: /var/lib/mysqlvolumeClaimTemplates:- metadata:name: mysql-dataspec:accessModes: ["ReadWriteOnce"]resources:requests:storage: 10Gi
逐行解释:
apiVersion: apps/v1
:使用apps
组 API。kind: StatefulSet
:声明资源类型。serviceName: mysql-headless
:关联的 Headless Service 名称。replicas: 3
:创建 3 个有序 Pod(mysql-0
、mysql-1
、mysql-2
)。volumeMounts
:将名为mysql-data
的卷挂载到容器路径/var/lib/mysql
。volumeClaimTemplates
:为每个 Pod 动态创建 10Gi 的 PVC(名称格式为mysql-data-mysql-X
)。
五、总结
StatefulSet 是 Kubernetes 管理有状态应用的核心控制器,通过唯一标识、有序管理和持久化存储,为分布式系统提供稳定运行环境。
彼此的区别
一、本质区别
维度 | Deployment | StatefulSet |
---|---|---|
设计目标 | 管理无状态应用(Pod 可任意替换) | 管理有状态应用(Pod 需唯一标识与持久存储) |
典型场景 | Web 服务、API 后端、无状态计算任务 | 数据库(MySQL/MongoDB)、消息队列(Kafka) |
二、核心特性对比
1. Pod 标识与网络
- Deployment:
- Pod 名称随机生成(如
nginx-5f76c6cb6d-hx8vp
),重启后改变。 - 通过 Service 负载均衡访问,无固定网络端点。
- Pod 名称随机生成(如
- StatefulSet:
- Pod 名称有序固定(如
mysql-0
、mysql-1
),生命周期内不变。 - 每个 Pod 有独立 DNS 记录(
pod-name.service-name.namespace.svc.cluster.local
)。
- Pod 名称有序固定(如
2. 存储管理
- Deployment:
- Pod 共享存储卷或无持久化存储,数据随 Pod 销毁丢失。
- StatefulSet:
- 通过
volumeClaimTemplates
为每个 Pod 动态绑定独立 PV,数据持久化。 - 存储与 Pod 严格绑定,重建后自动关联原数据。
- 通过
3. 扩缩容与更新
- Deployment:
- 并行扩缩容,无顺序限制。
- 支持滚动更新(RollingUpdate),可配置
maxSurge
/maxUnavailable
。
- StatefulSet:
- 顺序操作:扩容从 0→N-1,缩容从 N-1→0。
- 滚动更新默认逐个替换 Pod,保障数据一致性。
4. 服务发现
- Deployment:
- 通过 ClusterIP Service 实现负载均衡。
- StatefulSet:
- 依赖 Headless Service(无 ClusterIP),直接暴露 Pod DNS。
三、运维约束对比
特性 | Deployment | StatefulSet |
---|---|---|
Pod 唯一性 | ❌ | ✅(固定名称/DNS) |
持久化存储独占性 | ❌ | ✅(每 Pod 独立 PVC) |
有序启停 | ❌ | ✅(顺序保障) |
复杂度 | 低 | 高(需配置 Headless Service + PVC) |
四、强制使用 StatefulSet 的场景
- 需稳定网络标识:如数据库主从节点需固定域名通信。
- 独立持久化存储:每个 Pod 需专属数据卷(如 MySQL 主备数据分离)。
- 依赖启动顺序:集群初始化需严格按序(如 ZooKeeper 选举)。
💡 例外:若仅需共享存储(非独占),可使用 Deployment + 共享 PVC。
五、总结
- 无状态服务选 Deployment:强调弹性伸缩、简易运维(如 Web 服务)。
- 有状态服务选 StatefulSet:需稳定标识、持久存储、顺序保障(如数据库集群)。
- 慎用 StatefulSet:若非必要,优先用 Deployment(简化架构)。
通过此对比,可根据应用特性精准选择控制器,避免过度设计或功能缺失。