Readiness 探測 - 天天5分鐘玩轉 Docker 容器技術（144）

除了 Liveness 探測，Kubernetes Health Check 機制還包括 Readiness 探測。

用戶經過 Liveness 探測能夠告訴 Kubernetes 何時經過重啓容器實現自愈；Readiness 探測則是告訴 Kubernetes 何時能夠將容器加入到 Service 負載均衡池中，對外提供服務。

Readiness 探測的配置語法與 Liveness 探測徹底同樣，下面是個例子：

這個配置文件只是將前面例子中的 liveness 替換爲了 readiness，咱們看看有什麼不一樣的效果。

Pod readiness 的 READY 狀態經歷了以下變化：

1. 剛被建立時，READY 狀態爲不可用。

2. 15 秒後（initialDelaySeconds + periodSeconds），第一次進行 Readiness 探測併成功返回，設置 READY 爲可用。

3. 30 秒後，/tmp/healthy 被刪除，連續 3 次 Readiness 探測均失敗後，READY 被設置爲不可用。

經過 kubectl describe pod readiness 也能夠看到 Readiness 探測失敗的日誌。

下面對 Liveness 探測和 Readiness 探測作個比較：

1. Liveness 探測和 Readiness 探測是兩種 Health Check 機制，若是不特地配置，Kubernetes 將對兩種探測採起相同的默認行爲，即經過判斷容器啓動進程的返回值是否爲零來判斷探測是否成功。

2. 兩種探測的配置方法徹底同樣，支持的配置參數也同樣。不一樣之處在於探測失敗後的行爲：Liveness 探測是重啓容器；Readiness 探測則是將容器設置爲不可用，不接收 Service 轉發的請求。

3. Liveness 探測和 Readiness 探測是獨立執行的，兩者之間沒有依賴，因此能夠單獨使用，也能夠同時使用。用 Liveness 探測判斷容器是否須要重啓以實現自愈；用 Readiness 探測判斷容器是否已經準備好對外提供服務。

理解了 Liveness 探測和 Readiness 探測的原理，下一節咱們會討論如何在業務場景中使用 Health Check。

書籍：
1.《天天5分鐘玩轉Docker容器技術》
https://item.jd.com/16936307278.html

2.《天天5分鐘玩轉OpenStack》
https://item.jd.com/12086376.html