Liveness探測

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

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

1、探測的方法是：通過 cat 命令檢查 /tmp/healthy 文件是否存在。如果命令執(zhí)行成功，返回值為零，Kubernetes 則認為本次 Liveness 探測成功；如果命令返回值非零，本次 Liveness 探測失敗。

2、initialDelaySeconds: 10 指定容器啟動 10 之后開始執(zhí)行 Liveness 探測，我們一般會根據(jù)應用啟動的準備時間來設置。比如某個應用正常啟動要花 30 秒，那么 initialDelaySeconds 的值就應該大于 30。

3、periodSeconds: 5 指定每 5 秒執(zhí)行一次 Liveness 探測。Kubernetes 如果連續(xù)執(zhí)行 3 次 Liveness 探測均失敗，則會殺掉并重啟容器。

Readiness探測

Readiness 探測的配置語法與 Liveness 探測完全一樣，只是將配置文件中的 livenessProbe 替換為了 readinessProbe

Liveness 探測和 Readiness 探測比較

1、Liveness 探測和 Readiness 探測是兩種 Health Check 機制，如果不特意配置，Kubernetes 將對兩種探測采取相同的默認行為，即通過判斷容器啟動進程的返回值是否為零來判斷探測是否成功。

2、兩種探測的配置方法完全一樣，支持的配置參數(shù)也一樣。不同之處在于探測失敗后的行為：Liveness 探測是重啟容器；Readiness 探測則是將容器設置為不可用，不接收 Service 轉(zhuǎn)發(fā)的請求。

3、Liveness 探測和 Readiness 探測是獨立執(zhí)行的，二者之間沒有依賴，所以可以單獨使用，也可以同時使用。用 Liveness 探測判斷容器是否需要重啟以實現(xiàn)自愈；用 Readiness 探測判斷容器是否已經(jīng)準備好對外提供服務。

health check在Scale Up中的應用，示例配置文件：

這里我們使用了不同于 exec 的另一種探測方法 -- httpGet。Kubernetes 對于該方法探測成功的判斷條件是 http 請求的返回代碼在 200-400 之間。

schema 指定協(xié)議，支持 HTTP（默認值）和 HTTPS。

path 指定訪問路徑。

port 指定端口。

上面配置的作用是：

1、容器啟動 10 秒之后開始探測。

2、如果 http://[container_ip]:8080/healthy 返回代碼不是 200-400，表示容器沒有就緒，不接收 Service web-svc 的請求。

3、每隔 5 秒再探測一次。

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

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

health check 在滾動更新中的應用

maxSurge

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

maxUnavailable

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