===
一、引言
滚动升级(Rolling Update)是Kubernetes实现零停机部署的核心策略,通过逐步替换旧版本Pod确保服务持续可用。与传统的全量替换方式不同,滚动升级允许在更新过程中保持部分旧Pod运行,从而最大限度减少服务中断风险。本文作为Kubernetes管理实战系列的第八部分,将深入讲解滚动升级的工作原理、配置方法、实战操作及最佳实践,适用于Kubernetes v1.28+环境。
二、滚动升级核心原理
2.1 工作流程
滚动升级通过以下步骤实现无缝更新:
- 创建新版本ReplicaSet:基于更新后的Pod模板创建新的ReplicaSet
- 逐步扩容新ReplicaSet :根据
maxSurge
参数创建额外的新Pod - 验证新Pod就绪状态:等待新Pod通过就绪探针(Readiness Probe)检查
- 逐步缩容旧ReplicaSet :根据
maxUnavailable
参数终止旧Pod - 循环替换过程:重复步骤2-4直至所有旧Pod被替换
2.2 关键控制参数
滚动升级的行为由两个核心参数控制,通过spec.strategy.rollingUpdate
字段定义:
参数
含义
默认值
取值范围
maxSurge
更新过程中允许超出期望副本数的最大Pod数量
25%
0~100%或绝对数值
maxUnavailable
更新过程中允许不可用的最大Pod数量
25%
0~100%或绝对数值
参数作用机制:
maxSurge=25%
:对于10个副本的Deployment,最多可创建13个Pod(10 + 10×25%)maxUnavailable=25%
:更新期间至少保持7个Pod可用(10 - 10×25%)
三、基础配置与环境准备
3.1 标准Deployment配置
以下是支持滚动升级的Deployment基础配置文件(nginx-deployment.yaml
):
yaml
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 10 # 期望副本数
selector:
matchLabels:
app: nginx
strategy:
type: RollingUpdate # 指定滚动升级策略
rollingUpdate:
maxSurge: 25% # 允许超出25%的副本数
maxUnavailable: 25% # 允许25%的副本不可用
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.17.9 # 初始镜像版本
ports:
- containerPort: 80
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
readinessProbe: # 就绪探针配置(关键)
httpGet:
path: /health
port: 80
initialDelaySeconds: 5 # 容器启动后延迟5秒开始检查
periodSeconds: 5 # 每5秒检查一次
successThreshold: 1 # 连续1次成功视为就绪
3.2 初始部署与验证
执行部署并验证初始状态:
bash
csharp
# 应用部署配置
kubectl apply -f nginx-deployment.yaml
# 查看Deployment状态
kubectl get deployments nginx-deployment -o wide
# 验证Pod副本分布
kubectl get pods -l app=nginx -o wide
成功部署后将显示10个运行中的nginx Pod,均使用nginx:1.17.9
镜像版本。
四、实战操作步骤
4.1 触发滚动升级
Kubernetes支持多种方式触发滚动升级,选择最适合你的工作流:
方法1:修改YAML文件更新
yaml
yaml
# nginx-deployment-v2.yaml(仅展示变更部分)
spec:
template:
spec:
containers:
- name: nginx
image: nginx:1.18.0 # 更新为目标版本
应用更新:
bash
kubectl apply -f nginx-deployment-v2.yaml
方法2:使用kubectl set image直接更新
bash
arduino
# 语法:kubectl set image deployment/[部署名] [容器名]=[镜像名:版本]
kubectl set image deployment/nginx-deployment nginx=nginx:1.18.0 --record
--record参数 :记录当前命令到Deployment注解,用于后续版本追踪(
kubectl rollout history
)
4.2 监控升级进度
实时状态监控
bash
bash
# 查看滚动更新进度
kubectl rollout status deployment/nginx-deployment
# 预期输出:
# Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 10 new replicas have been updated...
# deployment "nginx-deployment" successfully rolled out
详细过程观察
使用以下命令实时观察Pod替换过程:
bash
ini
# 实时监控Pod状态变化
kubectl get pods -l app=nginx -w
# 查看ReplicaSet版本变化
kubectl get rs -l app=nginx
典型的Pod状态变化序列:
plaintext
sql
nginx-deployment-5f76d7c6b4-xxxx 1/1 Running 0 10m
nginx-deployment-789f567d4c-yyyy 0/1 Pending 0 0s
nginx-deployment-789f567d4c-yyyy 0/1 ContainerCreating 0 2s
nginx-deployment-789f567d4c-yyyy 1/1 Running 0 8s
nginx-deployment-5f76d7c6b4-xxxx 1/1 Terminating 0 10m
4.3 版本回滚操作
当新版本出现问题时,可快速回滚到历史稳定版本:
查看版本历史
bash
bash
# 查看所有更新历史
kubectl rollout history deployment/nginx-deployment
# 查看特定版本详情
kubectl rollout history deployment/nginx-deployment --revision=2
执行回滚
bash
bash
# 回滚到上一版本
kubectl rollout undo deployment/nginx-deployment
# 回滚到指定版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2
五、高级配置与优化
5.1 精细化升级策略
根据业务需求选择合适的升级策略,以下是三种典型场景配置:
场景1:稳定性优先(生产环境)
yaml
yaml
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 每次只增加1个Pod
maxUnavailable: 0 # 不允许任何Pod不可用
场景2:速度优先(测试环境)
yaml
yaml
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 50% # 最多可增加50%的Pod
maxUnavailable: 50% # 允许50%的Pod不可用
场景3:资源受限环境
yaml
yaml
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 0 # 不允许超出副本数(避免资源耗尽)
maxUnavailable: 1 # 每次只替换1个Pod
5.2 优雅终止与流量控制
配置PreStop Hook
确保旧Pod在终止前完成当前请求处理:
yaml
yaml
spec:
template:
spec:
containers:
- name: nginx
image: nginx:1.18.0
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 30; nginx -s quit"]
terminationGracePeriodSeconds: 60 # 优雅终止宽限期(默认30秒)
就绪探针优化
yaml
yaml
readinessProbe:
httpGet:
path: /health # 使用专用健康检查端点
port: 8080
initialDelaySeconds: 10 # 应用启动时间较长时增加延迟
periodSeconds: 3
failureThreshold: 3 # 连续3次失败才视为未就绪
六、故障排除与常见问题
6.1 升级停滞问题排查
现象
可能原因
排查方法
升级卡在"Waiting for pods to become ready"
新Pod未通过就绪探针
kubectl describe pod <pod-name>
查看事件
kubectl logs <pod-name> -c <container-name>
查看应用日志
旧Pod无法终止
PreStop Hook执行超时
检查terminationGracePeriodSeconds
设置
验证PreStop命令是否阻塞
升级超时(ProgressDeadlineExceeded)
新Pod启动时间过长
调整progressDeadlineSeconds
(默认600秒)
优化应用启动速度
6.2 典型故障修复案例
案例1:新Pod镜像拉取失败
bash
bash
# 查看Pod事件
kubectl describe pod nginx-deployment-789f567d4c-yyyy
# 事件中发现:Failed to pull image "nginx:1.18.0": rpc error: code = Unknown desc = Error response from daemon: manifest for nginx:1.18.0 not found
# 修复方法:使用正确镜像版本
kubectl set image deployment/nginx-deployment nginx=nginx:1.18.0-alpine
案例2:就绪探针失败导致升级暂停
bash
bash
# 查看具体探针失败原因
kubectl logs nginx-deployment-789f567d4c-yyyy -c nginx
# 发现应用健康检查端点返回503错误
# 修复应用健康检查逻辑后重新触发升级
kubectl set image deployment/nginx-deployment nginx=nginx:1.18.0-fixed
七、与其他部署策略对比
部署策略
实现方式
优势
劣势
适用场景
滚动升级
逐步替换Pod
零停机、资源占用低
版本共存需兼容、更新速度较慢
生产环境常规更新
蓝绿部署
切换Service Selector
瞬间切换、回滚简单
双倍资源消耗、配置复杂
关键业务重大更新
金丝雀发布
流量比例分配
风险可控、可测试
需要服务网格支持、配置复杂
新版本灰度验证
八、生产环境最佳实践
8.1 参数配置建议
环境类型
maxSurge
maxUnavailable
备注
开发/测试环境
50%
50%
快速迭代,容忍短暂不稳定
预发环境
30%
20%
接近生产配置,验证稳定性
生产环境(核心服务)
1~2
0~1
优先保证可用性
生产环境(非核心服务)
25%
25%
平衡可用性与更新速度
8.2 操作流程规范
-
升级前检查
bash
csharp# 检查Deployment健康状态 kubectl get deployment nginx-deployment -o jsonpath='{.status.conditions}' | jq # 备份当前配置 kubectl get deployment nginx-deployment -o yaml > backup-$(date +%F).yaml
-
分阶段更新策略
bash
bash# 1. 暂停滚动更新 kubectl rollout pause deployment/nginx-deployment # 2. 修改配置并应用(仅更新1个Pod) kubectl set image deployment/nginx-deployment nginx=nginx:1.18.0 # 3. 验证少量新Pod工作正常后恢复更新 kubectl rollout resume deployment/nginx-deployment
-
自动化集成建议
- 在CI/CD流水线中集成
kubectl rollout status
确保更新完成 - 配置Prometheus告警监控
kube_deployment_status_replicas_unavailable
指标 - 使用ArgoCD/Flux等工具实现声明式部署与自动回滚
- 在CI/CD流水线中集成
九、总结与扩展学习
滚动升级作为Kubernetes的核心特性,通过精细化控制Pod替换过程,实现了应用的零停机更新。关键成功因素包括:
- 合理配置
maxSurge
和maxUnavailable
参数 - 正确设置就绪探针和优雅终止机制
- 建立完善的监控和回滚预案
扩展学习资源
通过本文学习,您应该能够掌握滚动升级的配置方法和实战技巧,为Kubernetes环境中的应用更新提供稳定可靠的技术保障。