滚动更新

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