公司上线了一个新功能，开发团队急着部署，但运维小李犯了难：直接停机更新？用户正在用，肯定要骂人。这时候，容器版本的滚动更新就派上用场了。
什么是滚动更新
滚动更新是一种逐步替换旧版本容器实例的方式。它不会一次性关停所有服务，而是按批次停止老容器、启动新容器，确保整个过程中始终有实例在处理请求。
比如你有个应用跑了5个副本，滚动更新会先关掉一个v1版本的容器，启动一个v2版本的，等新实例健康后，再继续下一个，直到全部换成新版本。
为什么用滚动更新
想象一下商场换季打折，如果直接关门清仓，顾客全被挡在外面。但如果是边营业边换货，顾客几乎感觉不到变化。滚动更新就是这个思路——服务不停，用户体验不受影响。
相比“先删后建”或“蓝绿部署”，滚动更新对资源消耗更友好，不需要双倍容量，适合大多数日常发布场景。
Kubernetes 中的实现
在 Kubernetes 里，滚动更新是 Deployment 的默认策略。只要修改 Pod 模板里的镜像版本，系统就会自动触发滚动过程。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 5
selector:
matchLabels:
app: my-app
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: app
image: my-app:v1.0 <!-- 改成 v2.0 触发更新 -->上面配置中，maxUnavailable 控制最多有几个实例不可用，maxSurge 决定最多额外启动几个新实例。设置为1，意味着每次只更新一个，最稳当。
查看更新状态
执行完更新后，可以用命令观察进度：
kubectl rollout status deployment/my-app如果中间发现新版本有问题，还能立刻回滚：
kubectl rollout undo deployment/my-app实际使用的小提醒
滚动更新虽好，但也得注意几点。新版本容器启动后，必须通过健康检查（readinessProbe），否则系统不会认为它可用，也不会继续下一批更新。
另外，数据库变更要特别小心。比如新加了个字段，老版本代码读不了，就算容器还在跑，也可能出错。建议先让代码兼容旧数据结构，再逐步过渡。
还有，别忘了设置合理的超时和重试机制。用户请求可能正好落在切换瞬间，短暂的延迟要能扛住。