k8s之健康檢查(Health Check)

強(qiáng)大的自愈能力是 Kubernetes 這類(lèi)容器編排引擎的一個(gè)重要特性。自愈的默認(rèn)實(shí)現(xiàn)方式是自動(dòng)重啟發(fā)生故障的容器。除此之外，用戶還可以利用 Liveness 和 Readiness 探測(cè)機(jī)制設(shè)置更精細(xì)的健康檢查，進(jìn)而實(shí)現(xiàn)如下需求：

1. 零停機(jī)部署。
2. 避免部署無(wú)效的鏡像。
3. 更加安全的滾動(dòng)升級(jí)。

下面通過(guò)實(shí)踐學(xué)習(xí) Kubernetes 的 Health Check 功能。

默認(rèn)的健康檢查

我們首先學(xué)習(xí) Kubernetes 默認(rèn)的健康檢查機(jī)制：

每個(gè)容器啟動(dòng)時(shí)都會(huì)執(zhí)行一個(gè)進(jìn)程，此進(jìn)程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果進(jìn)程退出時(shí)返回碼非零，則認(rèn)為容器發(fā)生故障，Kubernetes 就會(huì)根據(jù) restartPolicy 重啟容器。

下面我們模擬一個(gè)容器發(fā)生故障的場(chǎng)景，Pod 配置文件如下：

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

Pod 的 restartPolicy 設(shè)置為 OnFailure，默認(rèn)為 Always。

sleep 10; exit 1 模擬容器啟動(dòng) 10 秒后發(fā)生故障。

執(zhí)行 kubectl apply 創(chuàng)建 Pod，命名為 healthcheck。

# kubectl apply -f healthcheck.yml
pod/healthcheck created

過(guò)幾分鐘查看 Pod 的狀態(tài)：

# kubectl get pod healthcheck 
NAME          READY   STATUS             RESTARTS   AGE
healthcheck   0/1     CrashLoopBackOff   4          3m39s

可看到容器當(dāng)前已經(jīng)重啟了 4 次。

在上面的例子中，容器進(jìn)程返回值非零，Kubernetes 則認(rèn)為容器發(fā)生故障，需要重啟。但有不少情況是發(fā)生了故障，但進(jìn)程并不會(huì)退出。比如訪問(wèn) Web 服務(wù)器時(shí)顯示 500 內(nèi)部錯(cuò)誤，可能是系統(tǒng)超載，也可能是資源死鎖，此時(shí) httpd 進(jìn)程并沒(méi)有異常退出，在這種情況下重啟容器可能是最直接最有效的解決方案，那我們?nèi)绾卫?Health Check 機(jī)制來(lái)處理這類(lèi)場(chǎng)景呢？

答案就是 Liveness 探測(cè)，我們下一節(jié)學(xué)習(xí)。

Liveness 探測(cè)讓用戶可以自定義判斷容器是否健康的條件。如果探測(cè)失敗，Kubernetes 就會(huì)重啟容器。

還是舉例說(shuō)明，創(chuàng)建如下 Pod：

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

啟動(dòng)進(jìn)程首先創(chuàng)建文件 /tmp/healthy，30 秒后刪除，在我們的設(shè)定中，如果 /tmp/healthy 文件存在，則認(rèn)為容器處于正常狀態(tài)，反正則發(fā)生故障。

livenessProbe 部分定義如何執(zhí)行 Liveness 探測(cè)：

1. 探測(cè)的方法是：通過(guò) cat 命令檢查 /tmp/healthy 文件是否存在。如果命令執(zhí)行成功，返回值為零，Kubernetes 則認(rèn)為本次 Liveness 探測(cè)成功；如果命令返回值非零，本次 Liveness 探測(cè)失敗。
2. initialDelaySeconds: 10 指定容器啟動(dòng) 10 之后開(kāi)始執(zhí)行 Liveness 探測(cè)，我們一般會(huì)根據(jù)應(yīng)用啟動(dòng)的準(zhǔn)備時(shí)間來(lái)設(shè)置。比如某個(gè)應(yīng)用正常啟動(dòng)要花 30 秒，那么 initialDelaySeconds 的值就應(yīng)該大于 30。
3. periodSeconds: 5 指定每 5 秒執(zhí)行一次 Liveness 探測(cè)。Kubernetes 如果連續(xù)執(zhí)行 3 次 Liveness 探測(cè)均失敗，則會(huì)殺掉并重啟容器。

下面創(chuàng)建 Pod liveness：

# kubectl apply -f liveness.yaml
pod/liveness created

從配置文件可知，最開(kāi)始的 30 秒，/tmp/healthy 存在，cat 命令返回 0，Liveness 探測(cè)成功，這段時(shí)間 kubectl describe pod liveness 的 Events部分會(huì)顯示正常的日志。

# kubectl describe pod liveness 

Events:
  Type    Reason     Age   From                Message
  ----    ------     ----  ----                -------
  Normal  Scheduled  31s   default-scheduler   Successfully assigned default/liveness to k8s-node2
  Normal  Pulling    30s   kubelet, k8s-node2  Pulling image "busybox"
  Normal  Pulled     30s   kubelet, k8s-node2  Successfully pulled image "busybox"
  Normal  Created    30s   kubelet, k8s-node2  Created container liveness
  Normal  Started    29s   kubelet, k8s-node2  Started container liveness

35 秒之后，日志會(huì)顯示 /tmp/healthy 已經(jīng)不存在，Liveness 探測(cè)失敗。再過(guò)幾十秒，幾次探測(cè)都失敗后，容器會(huì)被重啟。

Events:
  Type     Reason     Age               From                Message
  ----     ------     ----              ----                -------
  Normal   Scheduled  47s               default-scheduler   Successfully assigned default/liveness to k8s-node2
  Normal   Pulling    46s               kubelet, k8s-node2  Pulling image "busybox"
  Normal   Pulled     46s               kubelet, k8s-node2  Successfully pulled image "busybox"
  Normal   Created    46s               kubelet, k8s-node2  Created container liveness
  Normal   Started    45s               kubelet, k8s-node2  Started container liveness
  Warning  Unhealthy  3s (x3 over 13s)  kubelet, k8s-node2  Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
  Normal   Killing    3s                kubelet, k8s-node2  Container liveness failed liveness probe, will be restarted

# kubectl get pod liveness 
NAME       READY   STATUS    RESTARTS   AGE
liveness   1/1     Running   1          76s

除了 Liveness 探測(cè)，Kubernetes Health Check 機(jī)制還包括 Readiness 探測(cè)。

用戶通過(guò) Liveness 探測(cè)可以告訴 Kubernetes 什么時(shí)候通過(guò)重啟容器實(shí)現(xiàn)自愈；Readiness 探測(cè)則是告訴 Kubernetes 什么時(shí)候可以將容器加入到 Service 負(fù)載均衡池中，對(duì)外提供服務(wù)。

Readiness 探測(cè)的配置語(yǔ)法與 Liveness 探測(cè)完全一樣，下面是個(gè)例子：

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

這個(gè)配置文件只是將前面例子中的 liveness 替換為了 readiness，我們看看有什么不同的效果。

[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          10s
[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   1/1     Running   0          20s
[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   1/1     Running   0          35s
[root@k8s-master ~]# kubectl get pod readiness 
NAME        READY   STATUS    RESTARTS   AGE
readiness   0/1     Running   0          61s
[root@k8s-master ~]# kubectl describe pod readiness 

Pod readiness 的 READY 狀態(tài)經(jīng)歷了如下變化：

1. 剛被創(chuàng)建時(shí)，READY 狀態(tài)為不可用。
2. 15 秒后（initialDelaySeconds + periodSeconds），第一次進(jìn)行 Readiness 探測(cè)并成功返回，設(shè)置 READY 為可用。
3. 30 秒后，/tmp/healthy 被刪除，連續(xù) 3 次 Readiness 探測(cè)均失敗后，READY 被設(shè)置為不可用。

通過(guò) kubectl describe pod readiness 也可以看到 Readiness 探測(cè)失敗的日志。

Events:
  Type     Reason     Age                From                Message
  ----     ------     ----               ----                -------
  Normal   Scheduled  95s                default-scheduler   Successfully assigned default/readiness to k8s-node2
  Normal   Pulling    94s                kubelet, k8s-node2  Pulling image "busybox"
  Normal   Pulled     94s                kubelet, k8s-node2  Successfully pulled image "busybox"
  Normal   Created    93s                kubelet, k8s-node2  Created container readiness
  Normal   Started    93s                kubelet, k8s-node2  Started container readiness
  Warning  Unhealthy  4s (x12 over 59s)  kubelet, k8s-node2  Readiness probe failed: cat: can't open '/tmp/healthy': No such file or directory

下面對(duì) Liveness 探測(cè)和 Readiness 探測(cè)做個(gè)比較：

1. Liveness 探測(cè)和 Readiness 探測(cè)是兩種 Health Check 機(jī)制，如果不特意配置，Kubernetes 將對(duì)兩種探測(cè)采取相同的默認(rèn)行為，即通過(guò)判斷容器啟動(dòng)進(jìn)程的返回值是否為零來(lái)判斷探測(cè)是否成功。
2. 兩種探測(cè)的配置方法完全一樣，支持的配置參數(shù)也一樣。不同之處在于探測(cè)失敗后的行為：Liveness 探測(cè)是重啟容器；Readiness 探測(cè)則是將容器設(shè)置為不可用，不接收 Service 轉(zhuǎn)發(fā)的請(qǐng)求。
3. Liveness 探測(cè)和 Readiness 探測(cè)是獨(dú)立執(zhí)行的，二者之間沒(méi)有依賴，所以可以單獨(dú)使用，也可以同時(shí)使用。用 Liveness 探測(cè)判斷容器是否需要重啟以實(shí)現(xiàn)自愈；用 Readiness 探測(cè)判斷容器是否已經(jīng)準(zhǔn)備好對(duì)外提供服務(wù)。

在業(yè)務(wù)場(chǎng)景中使用 Health Check。

對(duì)于多副本應(yīng)用，當(dāng)執(zhí)行 Scale Up 操作時(shí)，新副本會(huì)作為 backend 被添加到 Service 的負(fù)載均衡中，與已有副本一起處理客戶的請(qǐng)求?？紤]到應(yīng)用啟動(dòng)通常都需要一個(gè)準(zhǔn)備階段，比如加載緩存數(shù)據(jù)，連接數(shù)據(jù)庫(kù)等，從容器啟動(dòng)到正真能夠提供服務(wù)是需要一段時(shí)間的。我們可以通過(guò) Readiness 探測(cè)判斷容器是否就緒，避免將請(qǐng)求發(fā)送到還沒(méi)有 ready 的 backend。

下面是示例應(yīng)用的配置文件。

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: web
        image: myhttpd
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /healthy
            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

重點(diǎn)關(guān)注 readinessProbe 部分。這里我們使用了不同于 exec 的另一種探測(cè)方法 -- httpGet。Kubernetes 對(duì)于該方法探測(cè)成功的判斷條件是 http 請(qǐng)求的返回代碼在 200-400 之間。

schema 指定協(xié)議，支持 HTTP（默認(rèn)值）和 HTTPS。
path 指定訪問(wèn)路徑。
port 指定端口。

上面配置的作用是：

容器啟動(dòng) 10 秒之后開(kāi)始探測(cè)。

如果 http://[container_ip]:8080/healthy 返回代碼不是 200-400，表示容器沒(méi)有就緒，不接收 Service web-svc 的請(qǐng)求。

每隔 5 秒再探測(cè)一次。

直到返回代碼為 200-400，表明容器已經(jīng)就緒，然后將其加入到 web-svc 的負(fù)責(zé)均衡中，開(kāi)始處理客戶請(qǐng)求。

探測(cè)會(huì)繼續(xù)以 5 秒的間隔執(zhí)行，如果連續(xù)發(fā)生 3 次失敗，容器又會(huì)從負(fù)載均衡中移除，直到下次探測(cè)成功重新加入。

對(duì)于 http://[container_ip]:8080/healthy，應(yīng)用則可以實(shí)現(xiàn)自己的判斷邏輯，比如檢查所依賴的數(shù)據(jù)庫(kù)是否就緒，示例代碼如下：

① 定義 /healthy 的處理函數(shù)。

② 連接數(shù)據(jù)庫(kù)并執(zhí)行測(cè)試 SQL。

③ 測(cè)試成功，正常返回，代碼 200。

④ 測(cè)試失敗，返回錯(cuò)誤代碼 503。

⑤ 在 8080 端口監(jiān)聽(tīng)。

對(duì)于生產(chǎn)環(huán)境中重要的應(yīng)用都建議配置 Health Check，保證處理客戶請(qǐng)求的容器都是準(zhǔn)備就緒的 Service backend。

在 Rolling Update 中如果應(yīng)用。

上一節(jié)討論了 Health Check 在 Scale Up 中的應(yīng)用，Health Check 另一個(gè)重要的應(yīng)用場(chǎng)景是 Rolling Update。試想一下下面的情況：

現(xiàn)有一個(gè)正常運(yùn)行的多副本應(yīng)用，接下來(lái)對(duì)應(yīng)用進(jìn)行更新（比如使用更高版本的 image），Kubernetes 會(huì)啟動(dòng)新副本，然后發(fā)生了如下事件：

1. 正常情況下新副本需要 10 秒鐘完成準(zhǔn)備工作，在此之前無(wú)法響應(yīng)業(yè)務(wù)請(qǐng)求。
2. 但由于人為配置錯(cuò)誤，副本始終無(wú)法完成準(zhǔn)備工作（比如無(wú)法連接后端數(shù)據(jù)庫(kù)）。

思考問(wèn)題：如果沒(méi)有配置 Health Check，會(huì)出現(xiàn)怎樣的情況？

因?yàn)樾赂北颈旧頉](méi)有異常退出，默認(rèn)的 Health Check 機(jī)制會(huì)認(rèn)為容器已經(jīng)就緒，進(jìn)而會(huì)逐步用新副本替換現(xiàn)有副本，其結(jié)果就是：當(dāng)所有舊副本都被替換后，整個(gè)應(yīng)用將無(wú)法處理請(qǐng)求，無(wú)法對(duì)外提供服務(wù)。如果這是發(fā)生在重要的生產(chǎn)系統(tǒng)上，后果會(huì)非常嚴(yán)重。

如果正確配置了 Health Check，新副本只有通過(guò)了 Readiness 探測(cè)，才會(huì)被添加到 Service；如果沒(méi)有通過(guò)探測(cè)，現(xiàn)有副本不會(huì)被全部替換，業(yè)務(wù)仍然正常進(jìn)行。

下面通過(guò)例子來(lái)實(shí)踐 Health Check 在 Rolling Update 中的應(yīng)用。

用如下配置文件 app.v1.yml 模擬一個(gè) 10 副本的應(yīng)用：

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

10 秒后副本能夠通過(guò) Readiness 探測(cè)。

# kubectl get deployments. app
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    0/10    10           0           8s

# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-6dd7f876c4-575v5   1/1     Running   0          25s
app-6dd7f876c4-9kwk9   1/1     Running   0          25s
app-6dd7f876c4-bx4pf   1/1     Running   0          25s
app-6dd7f876c4-f6qf2   1/1     Running   0          25s
app-6dd7f876c4-fxp2m   1/1     Running   0          25s
app-6dd7f876c4-k76mr   1/1     Running   0          25s
app-6dd7f876c4-mfqsq   1/1     Running   0          25s
app-6dd7f876c4-whkc7   1/1     Running   0          25s
app-6dd7f876c4-x9q87   1/1     Running   0          25s
app-6dd7f876c4-xf8dv   1/1     Running   0          25s

接下來(lái)滾動(dòng)更新應(yīng)用，配置文件 app.v2.yml 如下：

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

很顯然，由于新副本中不存在 /tmp/healthy，是無(wú)法通過(guò) Readiness 探測(cè)的。驗(yàn)證如下：

# kubectl apply -f app.yml --record 
deployment.apps/app configured
[root@k8s-master ~]# kubectl get deployments. app
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    8/10    5            8           80s

# kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-6dd7f876c4-575v5   1/1     Running   0          2m3s
app-6dd7f876c4-9kwk9   1/1     Running   0          2m3s
app-6dd7f876c4-f6qf2   1/1     Running   0          2m3s
app-6dd7f876c4-fxp2m   1/1     Running   0          2m3s
app-6dd7f876c4-k76mr   1/1     Running   0          2m3s
app-6dd7f876c4-whkc7   1/1     Running   0          2m3s
app-6dd7f876c4-x9q87   1/1     Running   0          2m3s
app-6dd7f876c4-xf8dv   1/1     Running   0          2m3s
app-7d7559dd99-6w2kn   0/1     Running   0          49s
app-7d7559dd99-jnbxg   0/1     Running   0          49s
app-7d7559dd99-mxbwg   0/1     Running   0          49s
app-7d7559dd99-n59vq   0/1     Running   0          49s
app-7d7559dd99-t49cp   0/1     Running   0          49s

這個(gè)截圖包含了大量的信息，值得我們?cè)敿?xì)分析。

先關(guān)注 kubectl get pod 輸出：

1. 從 Pod 的 AGE 欄可判斷，最后 5 個(gè) Pod 是新副本，目前處于 NOT READY 狀態(tài)。
2. 舊副本從最初 10 個(gè)減少到 8 個(gè)。

再來(lái)看 kubectl get deployment app 的輸出：

1. DESIRED 10 表示期望的狀態(tài)是 10 個(gè) READY 的副本。
2. CURRENT 13 表示當(dāng)前副本的總數(shù)：即 8 個(gè)舊副本 + 5 個(gè)新副本。
3. UP-TO-DATE 5 表示當(dāng)前已經(jīng)完成更新的副本數(shù)：即 5 個(gè)新副本。
4. AVAILABLE 8 表示當(dāng)前處于 READY 狀態(tài)的副本數(shù)：即 8個(gè)舊副本。

在我們的設(shè)定中，新副本始終都無(wú)法通過(guò) Readiness 探測(cè)，所以這個(gè)狀態(tài)會(huì)一直保持下去。

上面我們模擬了一個(gè)滾動(dòng)更新失敗的場(chǎng)景。不過(guò)幸運(yùn)的是：Health Check 幫我們屏蔽了有缺陷的副本，同時(shí)保留了大部分舊副本，業(yè)務(wù)沒(méi)有因更新失敗受到影響。

接下來(lái)我們要回答：為什么新創(chuàng)建的副本數(shù)是 5 個(gè)，同時(shí)只銷(xiāo)毀了 2 個(gè)舊副本？

原因是：滾動(dòng)更新通過(guò)參數(shù) maxSurge 和 maxUnavailable 來(lái)控制副本替換的數(shù)量。

此參數(shù)控制滾動(dòng)更新過(guò)程中副本總數(shù)的超過(guò) DESIRED 的上限。maxSurge 可以是具體的整數(shù)（比如 3），也可以是百分百，向上取整。maxSurge 默認(rèn)值為 25%。

在上面的例子中，DESIRED 為 10，那么副本總數(shù)的最大值為：
roundUp(10 + 10 * 25%) = 13

所以我們看到 CURRENT 就是 13。

此參數(shù)控制滾動(dòng)更新過(guò)程中，不可用的副本相占 DESIRED 的最大比例。 maxUnavailable 可以是具體的整數(shù)（比如 3），也可以是百分百，向下取整。maxUnavailable 默認(rèn)值為 25%。

在上面的例子中，DESIRED 為 10，那么可用的副本數(shù)至少要為：
10 - roundDown(10 * 25%) = 8

所以我們看到 AVAILABLE 就是 8。

maxSurge 值越大，初始創(chuàng)建的新副本數(shù)量就越多；maxUnavailable 值越大，初始銷(xiāo)毀的舊副本數(shù)量就越多。

理想情況下，我們這個(gè)案例滾動(dòng)更新的過(guò)程應(yīng)該是這樣的：

1. 首先創(chuàng)建 3 個(gè)新副本使副本總數(shù)達(dá)到 13 個(gè)。
2. 然后銷(xiāo)毀 2 個(gè)舊副本使可用的副本數(shù)降到 8 個(gè)。
3. 當(dāng)這 2 個(gè)舊副本成功銷(xiāo)毀后，可再創(chuàng)建 2 個(gè)新副本，使副本總數(shù)保持為 13 個(gè)。
4. 當(dāng)新副本通過(guò) Readiness 探測(cè)后，會(huì)使可用副本數(shù)增加，超過(guò) 8。
5. 進(jìn)而可以繼續(xù)銷(xiāo)毀更多的舊副本，使可用副本數(shù)回到 8。
6. 舊副本的銷(xiāo)毀使副本總數(shù)低于 13，這樣就允許創(chuàng)建更多的新副本。
7. 這個(gè)過(guò)程會(huì)持續(xù)進(jìn)行，最終所有的舊副本都會(huì)被新副本替換，滾動(dòng)更新完成。
   而我們的實(shí)際情況是在第 4 步就卡住了，新副本無(wú)法通過(guò) Readiness 探測(cè)。這個(gè)過(guò)程可以在 kubectl describe deployment app 的日志部分查看。

Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  11m   deployment-controller  Scaled up replica set app-6dd7f876c4 to 10
  Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set app-7d7559dd99 to 3
  Normal  ScalingReplicaSet  10m   deployment-controller  Scaled down replica set app-6dd7f876c4 to 8
  Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set app-7d7559dd99 to 5

如果滾動(dòng)更新失敗，可以通過(guò) kubectl rollout undo 回滾到上一個(gè)版本。

# kubectl rollout history deployment app
deployment.extensions/app 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=app.yml --record=true
2         kubectl apply --filename=app.yml --record=true

# kubectl get deployments. app
NAME   READY   UP-TO-DATE   AVAILABLE   AGE
app    8/10    5            8           14m

 kubectl get pod
NAME                   READY   STATUS    RESTARTS   AGE
app-6dd7f876c4-575v5   1/1     Running   0          14m
app-6dd7f876c4-9kwk9   1/1     Running   0          14m
app-6dd7f876c4-f6qf2   1/1     Running   0          14m
app-6dd7f876c4-fxp2m   1/1     Running   0          14m
app-6dd7f876c4-k76mr   1/1     Running   0          14m
app-6dd7f876c4-whkc7   1/1     Running   0          14m
app-6dd7f876c4-x9q87   1/1     Running   0          14m
app-6dd7f876c4-xf8dv   1/1     Running   0          14m
app-7d7559dd99-6w2kn   0/1     Running   0          13m
app-7d7559dd99-jnbxg   0/1     Running   0          13m
app-7d7559dd99-mxbwg   0/1     Running   0          13m
app-7d7559dd99-n59vq   0/1     Running   0          13m
app-7d7559dd99-t49cp   0/1     Running   0          13m

如果要定制 maxSurge 和 maxUnavailable，可以如下配置：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 35%
      maxUnavailable: 35%
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

小結(jié)
本章討論了 Kubernetes 健康檢查的兩種機(jī)制：Liveness 探測(cè)和 Readiness 探測(cè)，并實(shí)踐了健康檢查在 Scale Up 和 Rolling Update 場(chǎng)景中的應(yīng)用。