滚动更新
滚动更新是一种自动化程度较高的发布方式、用户体验比较平滑、是目前成熟型技术组织采用的主流发布方式,一次滚动发布一般有若干发布批次组成,每批的数量一般都是可配置的,可通过发布模板定义,例如第一批10%,第二批30%,第三批60%,第四批40%。每个批次之间保留观察间隔,通过手工验证或监控反馈确保没有问题再发下一批次。所以总体上滚动发布的过程是比较缓慢的。
默认的更新策略 maxSurge: 25% maxUnavailable: 25%
vi deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-v1
spec:
replicas: 10
selector:
matchLabels:
app: myapp
version: v1
template:
metadata:
labels:
app: myapp
version: v1
spec:
containers:
- name: myapp
image: 172.16.80.140/myapp/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80


将yaml中的版本修改为v2,重新应用,会发现生成一个新的rs,按照滚动策略进行更新pod,最终所有的pod都跟更新为新的版本,老的rs停用

查看新的pod,请求的结果与之前版本不同,说明已经更新为新的版本

查看历史版本
kubectl rollout history deployment myapp-v1

版本回滚,pod又恢复成v1版本
kubectl rollout history undo deployment/myapp-v1 --to-revision=1

自定义更新策略
yaml中配置maxSurge和maxUnavailable的值,两者不能同时为0
maxSurge==1 maxUnavailable 增加一个删除一个,速度较慢
也可以通过patch更新:
kubectl patch deployment myapp-v1 -p '{"spec":{"strategy":{"rollingUpdate": {"maxSurge":1,"maxUnavailable":1}}}}'

kubectl describe deployment myapp-v1 | grep RollingUpdateStrategy

更新策略默认是RollingUpdate,还有一种Recreata,把所有的pod都删掉重新创建,如下图,如果没有红框内容,默认RollingUpdate更新策略,如果有红框内容,更新策略改为Recreate
