滚动更新
滚动更新是一种自动化程度较高的发布方式、用户体验比较平滑、是目前成熟型技术组织采用的主流发布方式，一次滚动发布一般有若干发布批次组成，每批的数量一般都是可配置的，可通过发布模板定义，例如第一批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
