Kubernetes常见部署方案--滚动更新、从新建立、蓝绿、金丝雀

常见的部署方案：

• 滚动更新：服务不会中止，可是整个pod会有新旧并存的状况。
• 从新建立：先中止旧的pod，而后再建立新的pod，这个过程服务是会间断的。
• 蓝绿部署：无需停机，风险较小。部署v1的应用（一开始的状态）全部外部请求的流量都打到这个版本上。部署版本2的应用版本2的代码与版本1不一样(新功能、Bug修复等)。将流量从版本1切换到版本2。如版本2测试正常，就删除版本1正在使用的资源（例如实例），今后正式用版本2。
• 金丝雀部署：金丝雀发布通常先发 1 台，或者一个小比例，例如 2% 的服务器，主要作流量验证用，也称为金丝雀 (Canary) 测试（国内常称灰度测试）。之前旷工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀可否活下来，金丝雀发布由此得名。简单的金丝雀测试通常经过手工测试验证，复杂的金丝雀测试 须要比较完善的监控基础设施配合，经过监控指标反馈，观察金丝雀的健康情况，做为后续发布或回退的依据。若是金丝测试经过，则把剩余的 V1 版本所有升级为 V2 版本。若是金丝雀测试失败，则直接回退金丝雀，发布失败。

滚动更新：

　　建立 rollingupdate.yaml 文件：

　　maxUnavailable：最大无效pod数。
　　maxSurge：最大激增pod数。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rollingupdate
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: rollingupdate
  replicas: 4
  template:
    metadata:
      labels:
        app: rollingupdate
    spec:
      containers:
      - name: rollingupdate
        image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
        ports:
        - containerPort: 8080  
---
apiVersion: v1
kind: Service
metadata:
  name: rollingupdate
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: rollingupdate
  type: ClusterIP

　　kubectl apply -f rollingupdate.yaml
　　kubectl get pods
　　kubectl get svc
　　curl svc r-ip/dockerfile

 　　修改rollingupdate.yaml文件，将镜像修改为v2.0

# 在w1上，不断地访问观察输出 
while sleep 0.2;do curl cluster-ip/dockerfile;echo "";done
# 在w2上，监控pod 
kubectl get pods -w
# 使得更改生效
kubectl apply -f rollingupdate.yaml
kubectl get pods

　　发现新旧pod是会共存的，而且能够访问测试看一下

从新建立：

　　建立 recreate.yaml 文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: recreate
  replicas: 4
  template:
    metadata:
      labels:
        app: recreate
    spec:
      containers:
      - name: recreate
        image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
        ports:
        - containerPort: 8080
        livenessProbe:
          tcpSocket:
            port: 8080

　　kubectl apply -f recreate.yaml

　　kubectl get pods

　　修改recreate.yaml文件 改为 v2.0,执行kubectl apply -f recreate.yaml使其生效。同时在w2上进行观察  kubectl get pods -w   。发现pod是先中止，而后再建立新的

　　Have a try

kubectl rollout pause deploy/deploy-name #暂停资源
kubectl rollout resume deploy/rollingupdate #回复暂停资源
kubectl rollout undo deploy/rollingupdate --to-revision=2   # 回到上一个版本

蓝绿部署：

　　建立 bluegreen.yaml ：

#deploy
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue
spec:
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  selector:
    matchLabels:
      app: bluegreen
  replicas: 4
  template:
    metadata:
      labels:
        app: bluegreen
        version: v1.0
    spec:
      containers:
      - name: bluegreen
        image: registry.cn-hangzhou.aliyuncs.com/wuzz-docker/test-docker-image:v1.0
        ports:
        - containerPort: 8080

　　kubectl apply -f bluegreen.yaml

　　kubectl get pods

　　建立 bluegreen-service.yaml ：

apiVersion: v1
kind: Service
metadata:
  name: bluegreen
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: bluegreen
    version: v1.0
  type: ClusterIP

　　kubectl apply -f bluegreen-service.yaml

　　kubectl get svc

　　在w1上不断访问观察  while sleep 0.3;do curl cluster-ip/dockerfile;echo "";done　　

　　修改bluegreen.yaml

01-deployment-name:blue   --->  green
02-image:v1.0--->  v2.0
03-version:v1.0   --->  v2.0

　　kubectl apply -f bluegreen.yaml

　　kubectl get pods

　　同时观察刚才访问的地址有没有变化，能够发现，两个版本就共存了，而且以前访问的地址没有变化

　　修改bluegreen-service.yaml ：

# 也就是把流量切到2.0的版本中
selector:
 app: bluegreen
 version: v2.0

　　kubectl apply -f bluegreen-service.yaml

　　kubectl get svc

　　同时观察刚才访问的地址有没有变化。发现流量已经彻底切到了v2.0的版本上

金丝雀部署/灰度发布/AB测试：

　　修改上述 bluegreen-service.yaml

selector:
app: bluegreen
version: v2.0   # 把version删除掉，只是根据bluegreen进行选择

　　kubectl apply -f bluegreen-service.yaml

　　同时观察刚才访问的地址有没有变化，此时新旧版本可以同时被访问到，AB测试，新功能部署少一些的实例.