2. 程式人生 > >Liveness和Readiness兩種Health Check手段在Kubernetes中的使用

Liveness和Readiness兩種Health Check手段在Kubernetes中的使用

阿新 • • 發佈：2018-11-16

一.概述

強大的自愈能力是Kubernetes這一類容器編排管理引擎的一個重要特性。通常情況下，Kubernetes通過重啟發生故障的容器來實現自愈。除此之外，我們還有其他方式來實現基於Kubernetes編排的容器的健康檢查嗎？Liveness和Readiness就是不錯的選擇。

二.實踐步驟

2.1 系統預設的健康檢查。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: healthcheck
  name: healthcheck
spec:
  restartPolicy: OnFailure
  containers:
  - name: healthcheck
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10;exit 1

建立一個內容如上所述的yaml檔案，命名為HealthCheck.yaml，apply：

[[email protected] health-check]# kubectl apply -f HealthCheck.yaml
pod/healthcheck created
[[email protected] health-check]# kubectl get pod
NAME          READY   STATUS             RESTARTS   AGE
healthcheck   0/1     CrashLoopBackOff   3          4m52s

我們可以看到，這個pod並未正常執行，重啟了3次。具體的重啟日誌我們可以通過describe命令來檢視，此處不再贅述。我們來執行一下以下命令：

[[email protected] health-check]# sh -c "sleep 2;exit 1"
[[email protected] health-check]# echo $?
1

我們可以看到，命令正常執行，返回值為1。預設情況下，Linux命令執行之後返回值為0說明命令執行成功。因為執行成功後的返回值不為0，Kubernetes預設為容器發生故障，不斷重啟。然而，也有不少情況是服務實際發生了故障，但是程序未退出。這種情況下，重啟往往是簡單而有效的手段。例如：訪問web服務時顯示500伺服器內部錯誤，很多原因會造成這樣的故障，重啟可能就能迅速修復故障。

2.2 在Kubernetes中，可以通過Liveness探測告訴kebernetes什麼時候實現重啟自愈。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthcheck;sleep 30; rm -rf /tmp/healthcheck;sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthcheck
      initialDelaySeconds: 10
      periodSeconds: 5

建立名為Liveness.yaml的檔案，建立Pod：

[[email protected] health-check]# kubectl apply -f Liveness.yaml
pod/liveness created
[[email protected] health-check]# kubectl get pod
NAME       READY   STATUS    RESTARTS   AGE
liveness   1/1     Running   1          5m50s

從yaml檔案中，我們可以看出，容器啟動後建立/tmp/healthcheck檔案，30s後刪除，刪除後sleep該程序600s。通過cat /tmp/healthcheck來探測容器是否發生故障。如果該檔案存在，則說明容器正常，該檔案不存在，則殺該容器並重啟。

initialDelaySeconds:10指定容器啟動10s之後執行探測。一般該值要大於容器的啟動時間。periodSeconds:5表示每5s執行一次探測，如果連續三次執行Liveness探測均失敗，那麼會殺死該容器並重啟。

2.3 Readiness則可以告訴Kubenentes什麼時候可以將容器加入到Service的負載均衡池中，對外提供服務。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness
  name: readiness
spec:
  restartPolicy: OnFailure
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthcheck;sleep 30; rm -rf /tmp/healthcheck;sleep 600
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/healthcheck
      initialDelaySeconds: 10
      periodSeconds: 5

apply該檔案：

[[email protected] health-check]# kubectl apply -f Readiness.yaml
pod/readiness created
[[email protected] health-check]# kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          84s
[[email protected] health-check]# kubectl get pod
NAME        READY   STATUS      RESTARTS   AGE
readiness   0/1     Completed   0          23m

從yaml檔案中我們可以看出，Readiness和Liveness兩種探測的配置基本是一樣的，只需稍加改動就可以套用。通過kubectl get pod我們發現這兩種Health Check主要不同在於輸出的第二列和第三列。Readiness第三列一直都是running，第二列一段時間後由1/1變為0/1。當第二列為0/1時，則說明容器不可用。具體可以通過以下命令來檢視一下：

[[email protected] health-check]# while true;do kubectl describe pod readiness;done

Liveness和Readiness是兩種Health Check機制，不互相依賴，可以同時使用。

三.拓展

3.1 Health Check在Scale Up中的應用。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: web
        image: httpd
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /health-check
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 8080
    targetPort: 80

通過以上yaml，建立了一個名為web-svc的服務和名為web的Deployment。

[[email protected] health-check]# kubectl apply -f HealthCheck-web-deployment.yaml
deployment.apps/web unchanged
service/web-svc created
[[email protected] health-check]# kubectl get service web-svc
NAME      TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
web-svc   ClusterIP   10.101.1.6   <none>        8080/TCP   2m20s
[[email protected] health-check]# kubectl get deployment web
NAME   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
web    3         3         3            0           3m26s
[[email protected] health-check]# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
web-7d96585f7f-q5p4d   0/1     Running   0          3m35s
web-7d96585f7f-w6tqx   0/1     Running   0          3m35s
web-7d96585f7f-xrqwm   0/1     Running   0          3m35s

重點關注一下17-23行，第17行指出本案例中使用的Health Check機制為Readiness，探測方法為httpGet。Kubernetes對於該方法探測成功的判斷條件時http請求返回值在200-400之間。schema指定了協議，可以為http（預設）和https。path指定訪問路徑，port指定埠。

容器啟動10s後開始探測，如果 http://container_ip:8080/health-check 的返回值不是200-400,表示容器沒有準備就緒，不接收Service web-svc的請求。/health-check則是我們實現探測的程式碼。探測結果示例如下：

[[email protected] health-check]# kubectl describe pod web
Warning  Unhealthy  57s (x219 over 19m)  kubelet, k8s-n2    Readiness probe failed: Get http://10.244.2.61:8080/healthy: dial tcp 10.244.2.61:8080: connect: connection refused

3.2 Health Check在滾動更新（Rolling Update）中的應用。

預設情況下，在Rolling Update過程中，Kubernetes會認為容器已經準備就緒，進而會逐步替換舊副本。如果新版本的容器出現故障，那麼在版本更新完成之後可能導致整個應用無法處理請求，無法對外提供服務。此類事件若發生在生產環境中，後果會非常嚴重。正確配置了Health Check，只有通過了Readiness探測的新副本才能新增到Service，如果沒有通過探測，現有副本就不會唄替換，業務依然正常執行。

接下來，我們分別建立yaml檔案app.v1.yaml和app.v2.yaml:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 8
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10;touch /tmp/health-check;sleep 30000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/health-check
          initialDelaySeconds: 10
          periodSeconds: 5
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 8
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/health-check
          initialDelaySeconds: 10
          periodSeconds: 5

apply檔案app.v1.yaml:

[[email protected] health-check]# kubectl apply -f app.v1.yaml --record
deployment.apps/app created
[[email protected] health-check]# kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
app-844b9b5bf-9nnrb   1/1     Running   0          2m52s
app-844b9b5bf-b8tw2   1/1     Running   0          2m52s
app-844b9b5bf-j2n9c   1/1     Running   0          2m52s
app-844b9b5bf-ml8c5   1/1     Running   0          2m52s
app-844b9b5bf-mtgr9   1/1     Running   0          2m52s
app-844b9b5bf-n4dn8   1/1     Running   0          2m52s
app-844b9b5bf-ppzh6   1/1     Running   0          2m52s
app-844b9b5bf-z55d4   1/1     Running   0          2m52s

更新到app.v2.yaml:

[[email protected] health-check]# kubectl apply -f app.v2.yaml --record
deployment.apps/app configured
[[email protected] health-check]# kubectl get pod
NAME                  READY   STATUS              RESTARTS   AGE
app-844b9b5bf-9nnrb   1/1     Running             0          3m30s
app-844b9b5bf-b8tw2   1/1     Running             0          3m30s
app-844b9b5bf-j2n9c   1/1     Running             0          3m30s
app-844b9b5bf-ml8c5   1/1     Terminating         0          3m30s
app-844b9b5bf-mtgr9   1/1     Running             0          3m30s
app-844b9b5bf-n4dn8   1/1     Running             0          3m30s
app-844b9b5bf-ppzh6   1/1     Terminating         0          3m30s
app-844b9b5bf-z55d4   1/1     Running             0          3m30s
app-cd49b84-bxvtc     0/1     ContainerCreating   0          6s
app-cd49b84-gkkj8     0/1     ContainerCreating   0          6s
app-cd49b84-jfzcm     0/1     ContainerCreating   0          6s
app-cd49b84-xl8ws     0/1     ContainerCreating   0          6s

稍後再觀察：

[[email protected] health-check]# kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
app-844b9b5bf-9nnrb   1/1     Running   0          4m59s
app-844b9b5bf-b8tw2   1/1     Running   0          4m59s
app-844b9b5bf-j2n9c   1/1     Running   0          4m59s
app-844b9b5bf-mtgr9   1/1     Running   0          4m59s
app-844b9b5bf-n4dn8   1/1     Running   0          4m59s
app-844b9b5bf-z55d4   1/1     Running   0          4m59s
app-cd49b84-bxvtc     0/1     Running   0          95s
app-cd49b84-gkkj8     0/1     Running   0          95s
app-cd49b84-jfzcm     0/1     Running   0          95s
app-cd49b84-xl8ws     0/1     Running   0          95s

此刻狀態全部為running，但是依然有4個Pod的READY為0/1，再看一下：

[[email protected] health-check]# kubectl get deployment app
NAME   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
app    8         10        4            6           7m20s

DESIRED表示期待的副本數為8，CURRENT表示當前副本數為10，UP-TO-DATE表示升級了的副本數為4，AVAILABLE表示可用的副本數為6。如果不進行更改，該狀態將一直保持下去。在此，需要注意的是，Rolling Update中刪除了2箇舊副本，建立建了4個新副本。這裡留到最後再討論。

版本回滾到v1：

[[email protected] health-check]# kubectl rollout history deployment app
deployment.extensions/app
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=app.v1.yaml --record=true
2         kubectl apply --filename=app.v2.yaml --record=true

[[email protected] health-check]# kubectl rollout undo deployment app --to-revision=1
deployment.extensions/app
[[email protected] health-check]# kubectl get pod
NAME                  READY   STATUS    RESTARTS   AGE
app-844b9b5bf-8qqhk   1/1     Running   0          2m37s
app-844b9b5bf-9nnrb   1/1     Running   0          18m
app-844b9b5bf-b8tw2   1/1     Running   0          18m
app-844b9b5bf-j2n9c   1/1     Running   0          18m
app-844b9b5bf-mtgr9   1/1     Running   0          18m
app-844b9b5bf-n4dn8   1/1     Running   0          18m
app-844b9b5bf-pqpm5   1/1     Running   0          2m37s
app-844b9b5bf-z55d4   1/1     Running   0          18m

四.總結

4.1 Liveness和Readiness是Kubernetes中兩種不同的Health Check方式，他們非常類似，但又有區別。可以兩者同時使用，也可以單獨使用。具體差異在上文已經提及。

4.2 在上一篇關於Rolling Update的文章中，我曾經提到滾動更新過程中的替換規則。在本文中我們依然使用了預設方式進行更新。maxSurge和maxUnavailable兩個引數決定了更新過程中各個狀態下的副本個數，這兩個引數的預設值都是25%。更新後，總副本數=8+8*0.25=10；可用副本數：8-8*0.25=6。此過程中，銷燬了2個副本，建立了4個新副本。

4.3 在一般生產環境上線時，儘量使用Health Check來確保業務不受影響。這個過程的實現手段多樣化，需要根據實際情況進行總結和選用。

五.參考資料

5.1 官方文件：關於Liveness和Readiness

5.2 官方文件：關於maxSurge和maxUnavailable

5.3 文中涉及到的程式碼

相關推薦

Liveness和Readiness兩種Health Check手段在Kubernetes中的使用

一.概述 強大的自愈能力是Kubernetes這一類容器編排管理引擎的一個重要特性。通常情況下，Kubernetes通過重啟發生故障的容器來實現自愈。除此之外，我們還有其他方式來實現基於Kubernetes編排的容器的健康檢查嗎？Liveness和Readiness就是不錯的選擇。 二.實踐步驟 2.1

C#將Word轉換成PDF方法總結(基於Office和WPS兩種方案)

path ebs htm soft off ros exc 標題 總結 　有時候，我們需要在線上預覽word文檔，當然我們可以用NPOI抽出Word中的文字和表格，然後顯示到網頁上面，但是這樣會丟失掉Word中原有的格式和圖片。一個比較好的辦法就是將word轉換成pdf，然

CSS3實現五子棋Web小遊戲，Canvas畫布和DOM兩種實現，並且具有悔棋和撤銷悔棋功能。

posit oct padding 角色 sar pac osi fse ech 用Canvas實現五子棋的思路： 1、點擊棋盤，獲取坐標x，y，計算出棋子的二維數組坐標i和j， 2、棋子的實現，先arc一個圓，再填充漸變色。 3、下完一步棋後切換畫筆和角色。 4、贏法算法

跨域問題相關知識詳解（原生js和jquery兩種方法實現jsonp跨域）

syn con 加載 developer 兩種方法 ray exe 編寫 分組 1、同源策略 同源策略（Same origin policy），它是由Netscape提出的一個著名的安全策略。同源策略是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，則瀏覽

django-將數據庫數據轉換成JSON格式（ORM和SQL兩種情況）

user 展示 blog serialize 進行 項目開發 不管怎麽說 語句 spa 最近打算搞一個自動化運維平臺，所以在看Django的知識。 在實際項目開發中，遇到一個小問題：前後端發生數據交互主流采用的是JSON。前端傳數據到服務器端比較簡單，稍微麻煩的是服務器端傳

form表單中get和post兩種提交方式的區別

name bsp inpu get div post input 普通 表單 一、form表單中get和post兩種提交方式的區別？ 　　1.get提交表單中的內容在鏈接處是可見的。post不可見 　　2.post相比於get是安全的 　　3.post不收限制大小，get有

Java中的ReentrantLock和synchronized兩種鎖定機制的對比

優化 實現 維護 pla 所有 投票 明顯 拋出異常 數據 多線程和並發性並不是什麽新內容，但是 Java 語言設計中的創新之一就是，它是第一個直接把跨平臺線程模型和正規的內存模型集成到語言中的主流語言。核心類庫包含一個 Thread 類，可以用它來構建、啟動和操縱線程，J

GET和POST兩種基本請求方法的區別

完整性 總結 優化 返回 們的 傳遞參數 src 本質 大成 GET和POST是HTTP請求的兩種基本方法，要說它們的區別，接觸過WEB開發的人都能說出一二。 最直觀的區別就是GET把參數包含在URL中，POST通過request body傳遞參數。 你可能自己寫過

Redis的持久化機制包括RBD和AOF兩種，對於這兩種持久化方式各有優勢

plain 同步數據 pen toc 默認 ocl 好的 dfs 操作系統 RDB機制的策略 RDB持久化是指在指定的時間間隔內將內存中的數據和操作通過快照的方式保存到redis bin目錄下的一個默認名為 dump.rdb的文件，可以通過配置設置自動的快照持久化的

Docker的bridge和macvlan兩種網絡模式

附加 訪問 實現 網段 網上 技術分享 容器 interface 技術 項目上部署的Docker集群創建的容器網絡遇到問題，借機會學習了一下docker的網絡模式，其他類型我們用的不多，這裏只列舉我們常用的bridge和macvlan兩種，下面的描述和截圖有一些是直接從網上

Android以JSONOject和GSON兩種方式解析json

length pre ray oid 字符 CA clas img name json文件如下： 將獲取到的json數據轉化為String形式 OkHttpClient client = new OkHttpClient(); R

JDBC中Oracle的SID和ServiceName兩種方式的連接字符串格式

bottom none color bubuko div nbsp rac 字符串 padding SID格式： jdbc:oracle:thin:@<host>:<port>:<SID> 如: jdbc:oracle:thin:@19

9.10 路由控制之反向解析--【別名】html和views兩種方式實現

com 反向 技術分享 http mage login gin bsp 分享圖片 1. 在html裏反向解析 給路徑起別名，修改路徑時，不用每個地方都修改。 {% url ‘Log‘ %} : 就會去找別名為Log的URL,找到 "login/"後把"logi

julia開發環境安裝——VS code擴充套件和JuliaPro兩種方式

VS code擴充套件方式 首先，下載安裝julia1.0.0：我的上一篇文章 完成後，配置系統環境變數： 控制面板\所有控制面板項\系統–>高階系統設定 高階欄下點選系統變數~ 如圖： 在path下新增你的julia/bin路徑如（圖）：G:\Julia-1.0.0

numpy transpose 和 swapaxes兩種轉置方法

轉自：https://blog.csdn.net/caca95/article/details/81428673 transpose: 已3維舉例， 0 代表 x 軸，1 代表 y 軸，2 代表 z 軸， transpose(0,1,2)  可以理解維 tanspose(

GET和POST兩種請求方法的區別（RFC翻譯）

　　GET和POST方法是HTTP協議規定的。查了HTTP1.1的RFC，原文的專業性極強。下面是白話翻譯，歡迎補充和指錯。 　　GET方法就是檢索（以實體的形式）由請求uri所指定的資源。如果請求的uri指向資料產生的過程,應該把產生的資料應作為實體在響應中返回而不是源文字,除非原始檔指向輸出過

js中定時器setTimeout和setInterval兩種定時器

專案中，經常會用到定時器來實現資料實時更新、時間等，簡單總結一下： Javascript中的定時器有兩種，setInterval和setTimeout，而定時器的作用就是延遲執行。 一、定時器的寫法 setInterval(expression,milliseconds)；

spring的@Autowired 和 @Resource 兩種註解的區別

      在面試的時候，面試官問我@Autowired 和 @Resource 兩種註解的區別，當時懵逼了，雖然是經常用，但具體區別還真是不知道。然後搜百度記錄下。。。 一、相同點     1. 都是用來裝配 Bean，都可以

HTTP請求協議中GET和POST兩種基本請求方法的區別

GET在瀏覽器回退時是無害的，而POST會再次提交請求。   GET產生的URL地址可以被Bookmark，而POST不可以。   GET請求會被瀏覽器主動cache，而POST不會，除非手動設定。   GET請求只能進行url編碼

關於NPOI匯出excel檔案(xls和xlsx兩種格式)提示格式不符的問題

這兩天在做匯出excel檔案的時候遇到這個問題 本來我匯出的格式是xlsx格式的,但是下載得到的檔案格式變成了xls, 一開始以為是返回的contenttype設定錯了   return File(ms, "application/vnd.ms-excel", "新車型匯入模板檔案.xls