Kubernetes 更新策略
·
在 Kubernetes 中,应用的更新是日常运维中最常见的操作之一。为了保证服务的稳定性与可用性,Kubernetes 提供了多种 更新策略(Update Strategy),允许我们根据业务特点选择合适的方式来进行 Pod 的滚动更新或替换。本文将系统地梳理 Kubernetes 常用的更新策略,并结合实际场景给出示例。
一、为什么需要更新策略?
在容器化部署中,业务的快速迭代往往需要频繁更新应用。如果更新操作不当,可能会带来以下问题:
- 服务中断:更新过程中 Pod 全部被删除,新 Pod 尚未就绪,导致业务短暂不可用。
- 资源抖动:一次性拉起过多新 Pod,造成节点资源不足。
- 版本不一致:部分 Pod 已经是新版本,部分仍然是旧版本,可能导致兼容性问题。
因此,合理的更新策略至关重要。
二、Kubernetes 中的更新策略类型
1. Deployment 更新策略
Deployment 主要有两种更新方式:
(1)RollingUpdate(滚动更新,默认)
-
特点:逐步替换旧的 Pod,保证应用在更新过程中的高可用性。
-
常用配置参数:
maxUnavailable:更新过程中最多不可用的 Pod 数量(绝对值或百分比)。maxSurge:更新过程中最多额外创建的 Pod 数量(绝对值或百分比)。
示例:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 2
template:
spec:
containers:
- name: app
image: my-app:v2
解释:
- 在更新时,最多有 1 个 Pod 不可用;
- 最多可以临时多创建 2 个 Pod,加快更新速度。
(2)Recreate(重新创建)
- 特点:更新时先删除所有旧 Pod,再启动新 Pod。
- 适用场景:不支持版本共存的应用,例如数据库或有状态应用。
- 风险:更新期间服务会中断。
示例:
strategy:
type: Recreate
2. StatefulSet 更新策略
StatefulSet 用于管理有状态应用,其更新策略更细致:
(1)RollingUpdate(默认)
- Pod 会按照顺序(一般是从最高序号开始)依次更新。
- 支持 分区更新(Partition):指定从哪个 Pod 开始更新,之前的 Pod 保持旧版本。
示例:
updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 2
解释:序号大于等于 2 的 Pod 会更新到新版本,序号 0 和 1 的 Pod 保持旧版本。
适合灰度发布和分批验证。
(2)OnDelete
- 只有在手动删除 Pod 后才会启动新版本的 Pod。
- 更新完全由用户控制,适合对稳定性要求极高的应用。
3. DaemonSet 更新策略
DaemonSet 确保每个节点上都有一个 Pod。其更新策略包括:
(1)RollingUpdate(默认)
- 按节点逐个更新 Pod,避免同时影响所有节点上的 Pod。
- 可通过
maxUnavailable控制并行更新的数量。
示例:
updateStrategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 2
表示在更新过程中,最多允许 2 个节点上的 Pod 不可用。
(2)OnDelete
- 和 StatefulSet 一样,需要手动删除 Pod 才会更新。
- 多用于关键系统组件的升级。
四、注意事项
- 探针配置:确保
livenessProbe和readinessProbe配置合理,否则可能导致更新过程中 Pod 未准备好就被当作可用。 - 版本兼容性:滚动更新时新旧版本可能共存,需保证向后兼容。
- 资源预留:设置
maxSurge时注意节点资源是否足够,否则可能调度失败。 - 回滚机制:Deployment 支持回滚,可以通过
kubectl rollout undo快速恢复到上一个版本。
五、总结
Kubernetes 提供了灵活的更新策略,以适应不同类型应用的需求。常见策略总结如下:
- Deployment:
RollingUpdate(推荐,大多数场景) /Recreate - StatefulSet:
RollingUpdate(支持分区灰度) /OnDelete - DaemonSet:
RollingUpdate/OnDelete
更多推荐


所有评论(0)