aspnetcore.webapi實戰k8s健康探測機制 - kubernetes

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

• Liveness 

     k8s經過liveness來探測微服務的存活性，判斷何時該重啓容器實現自愈。好比訪問 Web 服務器時顯示 500 內部錯誤，多是系統超載，也多是資源死鎖，此時 httpd 進程並無異常退出，在這種狀況下重啓容器多是最直接最有效的解決方案。

• Readiness 

      k8s經過readiness來探測微服務的何時準備就緒（例如初始化時，鏈接數據庫，加載緩存數據等等，可能須要一段時間），而後將容器加入到server的負載均衡池中，對外提供服務。

    1.一、k8s默認的健康檢查機制

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

二、經過微服務自定義兩種機制

存活10分鐘：若是當前時間超過服務啓動時間10分鐘，則探測失敗，不然探測成功。Kubernetes 若是連續執行 3 次 Liveness 探測均失敗，就會殺掉並重啓容器。

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

從上面能夠看到，咱們能夠根據自身的需求來實現這兩種機制，而後，提供給k8s進行探測。

三、編寫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個實例進行集羣。

四、在k8s集羣的master機器上，建立部署對象

從上面能夠看到，剛開始建立時，READY 狀態爲不可用，等待一段時間

如今所有可用了

五、經過dashboard查看集羣概況

 

六、剖析k8s集羣自愈(self-healing)過程

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

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

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

此時經過dashboard查看集羣概況：

 

繼續等待一段時間：

如今，整個集羣已經自愈完成了！！！

七、總結

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

若是你以爲本篇文章對您有幫助的話，感謝您的【推薦】。
若是你對 kubernets 感興趣的話能夠關注我，我會按期的在博客分享個人學習心得。

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

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