通俗易懂,微服務實踐kubernetes的健康探測機制

作者:justmine(大數據達摩院)

出處:https://www.cnblogs.com/justmine

1、淺析k8s兩種健康檢查機制

  • Liveness

k8s通過liveness來探測微服務的存活性,判斷什麼時候該重啟容器實現自愈。比如訪問 Web 服務器時顯示 500 內部錯誤,可能是系統超載,也可能是資源死鎖,此時 httpd 進程並沒有異常退出,在這種情況下重啟容器可能是最直接最有效的解決方案。

  • Readiness

k8s通過readiness來探測微服務的什麼時候準備就緒(例如初始化時,連接數據庫,加載緩存數據等等,可能需要一段時間),然後將容器加入到server的負載均衡池中,對外提供服務。

1.1、k8s默認的健康檢查機制

每個容器啟動時都會執行一個進程,此進程由 Dockerfile 的 CMD 或 ENTRYPOINT 指定。如果進程退出時返回碼非零,則認為容器發生故障,Kubernetes 就會根據 restartPolicy 重啟容器。如果不特意配置,Kubernetes 將對兩種探測採取相同的默認行為。

2、通過微服務自定義兩種機制

存活10分鐘:如果當前時間超過服務啟動時間10分鐘,則探測失敗,否則探測成功。Kubernetes 如果連續執行 3 次 Liveness 探測均失敗,就會殺掉並重啟容器。

通俗易懂,微服務實踐kubernetes的健康探測機制

準備就緒30秒,30秒後,如果連續 3 次 Readiness 探測均失敗後,容器將被重置為不可用,不接收 service 轉發的請求。

通俗易懂,微服務實踐kubernetes的健康探測機制

從上面可以看到,我們可以根據自身的需求來實現這兩種機制,然後,提供給k8s進行探測。

3、編寫k8s資源配置文件(yml)

k8s默認是根據命令進行探測的,由於我們需要與微服務結合,所以需要在yml文件中指定為http方式(備註:k8s提供了三種container probes方式:command、TCP check、HTTP Get,其他的方式希望大家下去自己實踐),k8s對於http方式探測成功的判斷條件是請求的返回代碼在 200-400 之間。

health-checks-deployment.yml 如下:

apiVersion: apps/v1
kind: Deployment
metadata:
namespace: k8s-ecoysystem-apps
name: healthchecks-api
labels:
app: healthchecks-api
spec:
replicas: 3
selector:
matchLabels:
app: healthchecks-api
template:
metadata:
namespace: k8s-ecoysystem-apps
labels:
app: healthchecks-api
spec:
containers:
- name: healthchecks-api
imagePullPolicy: Always
image: justmine/healthchecksapi:v1.5
ports:
- containerPort: 80

readinessProbe:
httpGet:
path: /api/v1/heathchecks/readiness
port: 80
scheme: HTTP
initialDelaySeconds: 30
periodSeconds: 60
livenessProbe:
httpGet:
path: /api/v1/heathchecks/liveness
port: 80
scheme: HTTP
initialDelaySeconds: 120
periodSeconds: 60

從上面可以看到,一共部署了3個pod副本,而每個pod副本里面部署一個容器,即為同一個微服務部署了3個實例進行集群。

4、在k8s集群的master機器上,創建部署對象

通俗易懂,微服務實踐kubernetes的健康探測機制

從上面可以看到,剛開始創建時,READY 狀態為不可用,等待一段時間

通俗易懂,微服務實踐kubernetes的健康探測機制

現在全部可用了。

5、通過dashboard查看集群概況

通俗易懂,微服務實踐kubernetes的健康探測機制

6、剖析k8s集群自愈(self-healing)過程

通俗易懂,微服務實踐kubernetes的健康探測機制

通俗易懂,微服務實踐kubernetes的健康探測機制

通俗易懂,微服務實踐kubernetes的健康探測機制

從上面可以看到,大約1分鐘(dashboard統計信息有一定的延遲)左右,第一次進行 Readiness 探測併成功返回,此時準備就緒,可以對外提供服務了。在10分鐘內,探測Liveness也成功返回。

繼續等待一段時間,查詢其中一個pod詳細信息:

通俗易懂,微服務實踐kubernetes的健康探測機制

通俗易懂,微服務實踐kubernetes的健康探測機制

從上面可以看到,超過10分鐘存活期後,liveness探測失敗,容器被 killed and recreated。探測Readiness未成功返回時,整個容器處於不健康的狀態,並不會被負載均衡請求。

此時通過dashboard查看集群概況:

通俗易懂,微服務實踐kubernetes的健康探測機制

繼續等待一段時間:

通俗易懂,微服務實踐kubernetes的健康探測機制

現在,整個集群已經自愈完成了!!!

7、總結

Liveness 探測和 Readiness 探測是獨立執行的,二者之間沒有依賴,可以單獨使用,也可以同時使用。用 Liveness 探測判斷容器是否需要重啟以實現自愈;用 Readiness 探測判斷容器是否已經準備好對外提供服務

如果你覺得本篇文章對您有幫助的話,感謝您的【推薦】。

如果你對kubernets感興趣的話可以關注我,我會定期的在博客分享我的學習心得。

源碼參考:https://github.com/justmine66/k8s.ecoysystem.apps

下一篇,我們將實踐微服務中的環境變量和配置信息,如何與k8s進行結合。


分享到:


相關文章: