蓝绿发布和金丝雀发布

【滚动发布】

在了解蓝绿发布和金丝雀发布前，先了解滚动更新的方式，当一个控制器的版本更新的时候，会创建一个新的replisaset控制器然后创建一个新的pod，在逐渐递减旧的pod，如下图

 

这样可以通过设置控制器更新策略里的MaxSurage和MaxUnavailable来规定可以由多少个额外的pod和可以忍受多少个pod无法提供服务。

【金丝雀发布】

金丝雀发布又称灰度发布，金丝雀发布在更新的过程当中，会先创建一个新的replicaset，然后启动一个新的pod，等待这个新的pod运行一段时间，发现pod没有出现问题后，才对其他的pod进行更新，如果出现错误，则回滚到原来的版本。

 

【蓝绿发布】

原本旧版的所有控制器对接着server连接外部的负载均衡器，供给外部访问，更新的时候准备多一份yaml，进行修改为新的版本，然后创建一个新的服务集群，最后直接将server的服务接口全部换为v2的即可。

 

【金丝雀发布测试】

1，先创建一个deployment控制器设置副本数量为10，这样在更新的过程中更加直观。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollout-test
spec:
  selector:
    matchLabels:
      app: rollout
  replicas: 10
  strategy:
    type: RollingUpdate                     #设置滚动更新策略
    rollingUpdate:
      maxSurge: 1                           #设置滚动更新最多的多出的副本      
      maxUnavailable: 1                     #设置滚动更新最多不可用的副本
  template:
    metadata:
      name: rollout-test-pod
      labels:
        app: rollout
    spec:
      containers:
        - name: rollout-container
          image: httpd:2.2.31
          imagePullPolicy: IfNotPresent

然后现在需要将image的版本更新为2.2.32，使用金丝雀发布方式。

2，然后现在执行下面的命令，更新控制器镜像然后暂停更新，这样让更新完成的pod数量保持一个（也可以少量），用于测试是否可以运行。

kubectl set image deployment/rollout-test rollout-container=httpd:2.2.32 && kubectl rollout pause deployment/rollout-test

然后查看replicaset控制器和pod

已经创建了少量新的pod，现在运行一段时间，检查服务是否有问题

3，如果有问题就执行，就恢复控制器然后回滚上一次的版本，因为暂停的控制器无法进行回滚，也是两个命令一起执行

kubectl rollout resume deployment/rollout-test && kubectl rollout undo deployment/rollout-test

等待回滚完成即可。

4，如果没有问题则恢复控制器的更新进程，完全更新。

这就是金丝雀发布

 

【蓝绿发布测试】

提前将pvc创建好，然后v1的网页文件更改为v1，v2的网页文件改为v2

先创建一个模拟旧版的deployment控制器v1

apiVersion: apps/v1
kind: Deployment
metadata:
  name: v1-deployment
spec:
  selector:
    matchLabels:
      app: v1
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      name: v1-pod
      labels:
        app: v1
    spec:
      volumes:
        - name: nfs-pvc
          persistentVolumeClaim:
            claimName: pvc-v1
      containers:
        - name: v1-container
          image: nginx:latest
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: nfs-pvc
              mountPath: /usr/share/nginx/html

然后再创建一个模拟新版本的deployment控制器v2，（这里的镜像没有改变，这里只是模拟一个替换过程，所以没有改变镜像版本，实际情况下需要升级）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: v2-deployment
spec:
  selector:
    matchLabels:
      app: v2
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      name: v2-pod
      labels:
        app: v2
    spec:
      volumes:
        - name: nfs-pvc
          persistentVolumeClaim:
            claimName: pvc-v2
      containers:
        - name: v2-container
          image: nginx:latest
          imagePullPolicy: IfNotPresent
          volumeMounts:
            - name: nfs-pvc
              mountPath: /usr/share/nginx/html

然后最后在创建一个service供给v1控制器的外部接口

apiVersion: v1
kind: Service
metadata:
  name: service
spec:
  type: NodePort
  ports:
    - port: 80
      nodePort: 32000
  selector:
    app: v1

现在用外部访问一下接口

发现v1现在正常使用，service正在给v1提供接口

然后现在只需要将service的标签更改为v2的标签，就可以有v1更新为v2，直接给v2提供接口。

然后更新

然后访问发现无缝衔接v2版本。

蓝绿部署完成