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測試，新功能部署少一些的實例.