《前端運維》五、k8s--3灰度釋出、滾動更新與探針

Zaking發表於2022-03-29

一、灰度釋出

　　灰度釋出是一種釋出方式，也叫金絲雀釋出，起源是礦工在下井之前會先放一隻金絲雀到井裡，如果金絲雀不叫了，就代表瓦斯濃度高。原因是金絲雀對瓦斯氣體很敏感。灰度釋出的做法是：會在現存舊應用的基礎上，啟動一個新版應用，但是新版應用並不會直接讓使用者訪問。而是先讓測試同學去進行測試。如果沒有問題，則可以將真正的使用者流量慢慢匯入到新版，在這中間，持續對新版本執行狀態做觀察，直到慢慢切換過去，這就是所謂的A/B測試。當然，你也可以招募一些灰度使用者，給他們設定獨有的灰度標示（Cookie，Header），來讓他們可以訪問到新版應用，當然，如果中間切換出現問題，也應該將流量迅速地切換到老應用上。

1）準備新版本的service

　　拷貝一份deployment檔案：

cp deployment-user-v1.yaml deployment-user-v2.yaml

　　修改之前寫過的內容：

apiVersion: apps/v1  #API 配置版本
kind: Deployment     #資源型別
metadata:
+  name: user-v2     #資源名稱
spec:
  selector:
    matchLabels:
+      app: user-v2 #告訴deployment根據規則匹配相應的Pod進行控制和管理，matchLabels欄位匹配Pod的label值
  replicas: 3 #宣告一個 Pod,副本的數量
  template:
    metadata:
      labels:
+        app: user-v2 #Pod的名稱
    spec:   #組內建立的 Pod 資訊
      containers:
      - name: nginx #容器的名稱
+        image: registry.cn-beijing.aliyuncs.com/zhangrenyang/nginx:user-v2
        ports:
        - containerPort: 80 #容器內對映的埠

　　然後service的檔案內容是這樣的：

apiVersion: v1
kind: Service
metadata:
+  name: service-user-v2
spec:
  selector:
+    app: user-v2
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort

　　啟動：

kubectl apply -f deployment-user-v2.yaml service-user-v2.yaml

2）根據cookie切分流量

　　基於 Cookie 切分流量。這種實現原理主要根據使用者請求中的 Cookie 是否存在灰度標示 Cookie去判斷是否為灰度使用者，再決定是否返回灰度版本服務

nginx.ingress.kubernetes.io/canary：可選值為 true / false 。代表是否開啟灰度功能
nginx.ingress.kubernetes.io/canary-by-cookie：灰度釋出 cookie 的 key。當 key 值等於 always 時，灰度觸發生效。等於其他值時，則不會走灰度環境 ingress-gray.yaml

　　我們建立一個ingress-gray.yaml檔案：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: user-canary
annotations:
  kubernetes.io/ingress.class: nginx
  nginx.ingress.kubernetes.io/rewrite-target: /
  nginx.ingress.kubernetes.io/canary: "true"
  nginx.ingress.kubernetes.io/canary-by-cookie: "vip_user"
spec:
rules:
- http:
    paths: 
     - backend:
        serviceName: service-user-v2
        servicePort: 80
backend:
   serviceName: service-user-v2
   servicePort: 80

　　使檔案生效：

kubectl apply -f ./ingress-gray.yaml

　　獲取外部介面：

kubectl -n ingress-nginx get svc

　　測試：

curl http://172.31.178.169:31234/user
curl http://118.190.156.138:31234/user
curl --cookie "vip_user=always"  http://172.31.178.169:31234/user

3）基於header切分流量

　　基於 Header 切分流量，這種實現原理主要根據使用者請求中的 header 是否存在灰度標示 header去判斷是否為灰度使用者，再決定是否返回灰度版本服務。

　　修改下上面的ingress-gray.yml檔案即可：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: user-canary
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/canary: "true"
+    nginx.ingress.kubernetes.io/canary-by-header: "name"
+    nginx.ingress.kubernetes.io/canary-by-header-value: "vip"
spec:
  rules:
  - http:
      paths: 
       - backend:
          serviceName: service-user-v2
          servicePort: 80
  backend:
     serviceName: service-user-v2
     servicePort: 80

　　同樣的：

kubectl apply -f ingress-gray.yaml
curl --header "name:vip"  http://172.31.178.169:31234/user

4）基於權重切分流量

　　這種實現原理主要是根據使用者請求，通過根據灰度百分比決定是否轉發到灰度服務環境中

nginx.ingress.kubernetes.io/canary-weight：值是字串，為 0-100 的數字，代表灰度環境命中概率。如果值為 0，則表示不會走灰度。值越大命中概率越大。當值 = 100 時，代表全走灰度。

　　一樣一樣的，修改下配置引數罷了：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: user-canary
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/canary: "true"
+   nginx.ingress.kubernetes.io/canary-weight: "50"
spec:
  rules:
  - http:
      paths: 
       - backend:
          serviceName: service-user-v2
          servicePort: 80
  backend:
     serviceName: service-user-v2
     servicePort: 80

　　測試下：

kubectl apply -f ingress-gray.yaml
for ((i=1; i<=10; i++)); do curl http://172.31.178.169:31234/user; done

　　k8s 會優先去匹配 header ，如果未匹配則去匹配 cookie ，最後是 weight。

二、滾動釋出

　　滾動釋出，則是我們一般所說的無當機發布。其釋出方式如同名稱一樣，一次取出一臺/多臺伺服器（看策略配置）進行新版本更新。當取出的伺服器新版確保無問題後，接著採用同等方式更新後面的伺服器。k8s建立副本應用程式的最佳方法就是部署(Deployment)，部署自動建立副本集(ReplicaSet)，副本集可以精確地控制每次替換的Pod數量，從而可以很好的實現滾動更新。k8s每次使用一個新的副本控制器(replication controller)來替換已存在的副本控制器，從而始終使用一個新的Pod模板來替換舊的pod模板

建立一個新的replication controller
增加或減少pod副本數量，直到滿足當前批次期望的數量
刪除舊的replication controller

　　滾動釋出的優缺點如下：

優點
- 不需要停機更新，無感知平滑更新。
- 版本更新成本小,不需要新舊版本共存
缺點
- 更新時間長：每次只更新一個/多個映象，需要頻繁連續等待服務啟動緩衝
- 舊版本環境無法得到備份：始終只有一個環境存在
- 回滾版本異常痛苦：如果滾動釋出到一半出了問題，回滾時需要使用同樣的滾動策略回滾舊版本

　　我們下面來嘗試下，先擴容為10個副本：

kubectl get deploy
kubectl scale deployment user-v1  --replicas=10

　　修改deployment-user-v1.yaml檔案：

apiVersion: apps/v1  #API 配置版本
kind: Deployment     #資源型別
metadata:
  name: user-v1     #資源名稱
spec:
  minReadySeconds: 1
+ strategy:
+   type: RollingUpdate
+   rollingUpdate:
+     maxSurge: 1
+     maxUnavailable: 0
+ selector:
+   matchLabels:
+     app: user-v1 #告訴deployment根據規則匹配相應的Pod進行控制和管理，matchLabels欄位匹配Pod的label值
  replicas: 10 #宣告一個 Pod,副本的數量
  template:
    metadata:
      labels:
        app: user-v1 #Pod的名稱
    spec:   #組內建立的 Pod 資訊
      containers:
      - name: nginx #容器的名稱
+       image: registry.cn-beijing.aliyuncs.com/zhangrenyang/nginx:user-v3 #使用哪個映象
        ports:
        - containerPort: 80 #容器內對映的埠

引數	含義
minReadySeconds	容器接受流量延緩時間：單位為秒，預設為0。如果沒有設定的話，k8s會認為容器啟動成功後就可以用了。設定該值可以延緩容器流量切分
strategy.type = RollingUpdate	ReplicaSet 釋出型別，宣告為滾動釋出，預設也為滾動釋出
strategy.rollingUpdate.maxSurge	最多Pod數量：為數字型別/百分比。如果 maxSurge 設定為1，replicas 設定為10，則在釋出過程中pod數量最多為10 + 1個（多出來的為舊版本pod，平滑期不可用狀態）。maxUnavailable 為 0 時，該值也不能設定為0
strategy.rollingUpdate.maxUnavailable	升級中最多不可用pod的數量：為數字型別/百分比。當 maxSurge 為 0 時，該值也不能設定為0

　　啟動：

kubectl apply -f ./deployment-user-v1.yaml
deployment.apps/user-v1 configured

　　然後檢視狀態：

kubectl rollout status deployment/user-v1

三、服務可用性探針

　　當 Pod 的狀態為 Running 時，該 Pod 就可以被分配流量(可以訪問到)了。一個後端容器啟動成功，不一定不代表服務啟動成功。

3.2.1 存活探針 LivenessProbe

　　第一種是存活探針。存活探針是對執行中的容器檢測的。如果想檢測你的服務在執行中有沒有發生崩潰，服務有沒有中途退出或無響應，可以使用這個探針。如果探針探測到錯誤， Kubernetes 就會殺掉這個 Pod；否則就不會進行處理。如果預設沒有配置這個探針， Pod 不會被殺死。

3.2.2 可用探針 ReadinessProbe

　　第二種是可用探針。作用是用來檢測 Pod 是否允許被訪問到（是否準備好接受流量）。如果你的服務載入很多資料，或者有其他需求要求在特定情況下不被分配到流量，那麼可以用這個探針。如果探針檢測失敗，流量就不會分配給該 Pod。在沒有配置該探針的情況下，會一直將流量分配給 Pod。當然，探針檢測失敗，Pod 不會被殺死。

3.2.3 啟動探針 StartupProbe

　　第三種是啟動探針。作用是用來檢測 Pod 是否已經啟動成功。如果你的服務啟動需要一些載入時長（例如初始化日誌，等待其他呼叫的服務啟動成功）才代表服務啟動成功，則可以用這個探針。如果探針檢測失敗，該 Pod 就會被殺死重啟。在沒有配置該探針的情況下，預設不會殺死 Pod 。在啟動探針執行時，其他所有的探針檢測都會失效。

探針名稱	在哪個環節觸發	作用	檢測失敗對Pod的反應
啟動探針	Pod 執行時	檢測服務是否啟動成功	殺死 Pod 並重啟
存活探針	Pod 執行時	檢測服務是否崩潰，是否需要重啟服務	殺死 Pod 並重啟
可用探針	Pod 執行時	檢測服務是不是允許被訪問到	停止Pod的訪問排程，不會被殺死重啟

檢測方式

1、ExecAction

　　通過在 Pod 的容器內執行預定的 Shell 指令碼命令。如果執行的命令沒有報錯退出（返回值為0），代表容器狀態健康。否則就是有問題的

　　我們來新建一個檔案,vi shell-probe.yaml，內容如下：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: shell-probe
  name: shell-probe
spec:
  containers:
  - name: shell-probe
    image: registry.aliyuncs.com/google_containers/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

　　然後執行下面的命令，檢視情況：

kubectl apply -f liveness.yaml 
kubectl get pods | grep liveness-exec
kubectl describe pods liveness-exec

2、TCPSocketAction

　　這種方式是使用 TCP 套接字檢測。 Kubernetes 會嘗試在 Pod 內與指定的埠進行連線。如果能建立連線（Pod的埠開啟了），這個容器就代表是健康的，如果不能，則代表這個 Pod 就是有問題的。

　　建立檔案如下，tcp-probe.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: tcp-probe
  labels:
    app: tcp-probe
spec:
  containers:
  - name: tcp-probe
    image: nginx
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

　　類似的：

kubectl apply -f tcp-probe.yaml 
kubectl get pods | grep tcp-probe
kubectl describe pods tcp-probe

　　進入到容器內部：

kubectl exec -it tcp-probe  -- /bin/sh

　　更新apt-get並安裝vim：

apt-get update
apt-get install vim -y
vi  /etc/nginx/conf.d/default.conf

　　修改nginx檔案配置，把80埠修改為8080，然後過載一下nginx：

nginx -s reload

　　看一下狀態：

kubectl describe pod tcp-probe

3、HTTPGetAction

　　這種方式是使用 HTTP GET 請求。Kubernetes 會嘗試訪問 Pod 內指定的API路徑。如果返回200，代表容器就是健康的。如果不能，代表這個 Pod 是有問題的。

　　新增http-probe.yaml檔案：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: http-probe
  name: http-probe
spec:
  containers:
  - name: http-probe
    image: registry.cn-beijing.aliyuncs.com/zhangrenyang/http-probe:1.0.0
    livenessProbe:
      httpGet:
        path: /liveness
        port: 80
        httpHeaders:
        - name: source
          value: probe
      initialDelaySeconds: 3
      periodSeconds: 3

　　然後，執行並檢視狀態：

kubectl apply -f ./http-probe.yaml
kubectl describe pods http-probe
kubectl replace --force -f http-probe.yaml

　　Dockerfile內容如下：

FROM node
COPY ./app /app
WORKDIR /app
EXPOSE 3000
CMD node index.js

　　node服務檔案如下：

let http = require('http');
let start = Date.now();
http.createServer(function(req,res){
  if(req.url === '/liveness'){
    let value = req.headers['source'];
    if(value === 'probe'){
     let duration = Date.now()-start;
      if(duration>10*1000){
          res.statusCode=500;
          res.end('error');
      }else{
          res.statusCode=200;
          res.end('success');
      }
    }else{
     res.statusCode=200;
     res.end('liveness');
    }
  }else{
     res.statusCode=200;
     res.end('liveness');
  }
}).listen(3000,function(){console.log("http server started on 3000")});

　　好了今天的內容就到這裡了。

微服務部署之藍綠髮布、滾動釋出、灰度釋出區別與特點
2021-11-03
微服務
灰度部署、滾動部署與藍綠部署
2019-04-14
雲端計算運維與傳統運維的探討
2013-09-20
運維
《前端運維》五、k8s--1安裝與基本配置
2022-03-28
前端運維K8S
Vue + Webpack 灰度釋出控制
2018-03-11
VueWeb
F5與Openshift整合，實現灰度釋出
2018-08-03
回首五年運維，運維需要思考
2020-12-18
運維
ONE有引力釋出會精彩回顧 | 更強-探針支援3層架構，20W+探針同時接入
2023-04-27
架構
阿里雲釋出ECS運維體系，提供原生運維能力
2018-08-14
阿里運維
開源自動化運維平臺 BigOps 1.0.0 釋出
2019-07-17
運維Go
分散式全鏈路灰度釋出的探索與實踐
2021-01-11
分散式
淺談前端線上部署與運維
2017-11-20
前端運維
一鍵實現自動化部署（灰度釋出）實踐
2019-08-27
如何實現灰度釋出輕量化？
2023-01-31
阿里雲釋出ECS自動化運維套件，幫助企業實現自動化運維轉型
2021-02-03
阿里運維套件
銳捷釋出智慧運維平臺，讓IT運維“樂享其成”
2022-04-20
運維
IT運維和自動化運維以及運維開發有啥不同？能解釋下嗎？
2021-09-23
運維
PHP探針
2017-08-27
PHP
一文搞懂灰度釋出與 AB Test 的聯絡與區別
2022-09-22
《前端運維》三、Docker--1映象與容器
2022-03-25
前端運維Docker
nginx 實現實用的灰度釋出
2019-10-29
Nginx
nginx+lua+redis實現灰度釋出
2023-12-18
NginxRedis
nginx 根據IP 進行灰度釋出
2017-11-13
Nginx
五分鐘 k8s 實戰-應用探針
2023-11-27
K8S
IT運維之自動化運維
2021-03-30
運維
基於Nodejs的前端灰度釋出方案_20190228
2019-02-28
NodeJS前端
乾貨分享｜使用 Istio 實現灰度釋出
2022-09-20
灰度釋出的一種技術實踐
2022-09-19
關於灰度釋出，你得知道這些......
2023-03-08
一體化運營門戶 BeyondBSM自動化運維釋出V3.1版本
2020-03-09
運維
美國財政部針對區塊鏈專案釋出五項提示
2018-03-22
區塊鏈
大規模微服務場景下灰度釋出與流量染色實踐
2022-12-08
微服務
CODING DevOps + Nginx-ingress 實現自動化灰度釋出
2020-07-23
devNginx
Knativa 基於流量的灰度釋出和自動彈性實踐
2021-03-26
tkinter中text文字與scroll滾動條控制元件（五）
2018-04-10
控制元件
WIFI探針技術
2017-09-24
WiFi
五分鐘搞定Bash功能與使用技巧，運維速收！
2018-12-11
運維
Liunx運維(五)-資訊顯示與搜尋檔案命令
2020-12-20
運維