aspnetcore.webapi实践k8s健康探测机制 - kubernetes
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 探測均失敗，就會殺掉并重啟容器。
準備就緒30秒，30秒后，如果連續 3 次 Readiness 探測均失敗后，容器將被重置為不可用，不接收 Service 轉發的請求。
從上面可以看到，我們可以根據自身的需求來實現這兩種機制，然后，提供給k8s進行探測。
3、編寫k8s資源配置文件(yml)
k8s默認是根據命令進行探測的，由于我們需要與微服務結合，所以需要在yml文件中指定為http方式，k8s對于http方式探測成功的判斷條件是請求的返回代碼在 200-400 之間。
health-checks-deployment.yml 如下：
從上面可以看到，一共部署了3個pod副本，而每個pod副本里面部署一個容器，即為同一個微服務部署了3個實例進行集群。
4、在k8s集群的master機器上，創建部署對象
從上面可以看到，剛開始創建時，READY?狀態為不可用，等待一段時間
現在全部可用了
5、通過dashboard查看集群概況
?
6、剖析k8s集群自愈(self-healing)過程
?
從上面可以看到，大約1分鐘(dashboard統計信息有一定的延遲)左右，第一次進行 Readiness 探測并成功返回，此時準備就緒，可以對外提供服務了。在10分鐘內，探測Liveness也成功返回。
繼續等待一段時間，查詢其中一個pod詳細信息：
從上面可以看到，超過10分鐘存活期后，liveness探測失敗，容器被 killed and recreated。探測Readiness未成功返回時，整個容器處于不健康的狀態，并不會被負載均衡請求。
此時通過dashboard查看集群概況：
?
繼續等待一段時間：
現在，整個集群已經自愈完成了！！！
7、總結
Liveness 探測和 Readiness 探測是獨立執行的，二者之間沒有依賴，可以單獨使用，也可以同時使用。用 Liveness 探測判斷容器是否需要重啟以實現自愈；用 Readiness 探測判斷容器是否已經準備好對外提供服務。
?
源碼參考：https://github.com/justmine66/k8s.ecoysystem.apps
相關文章：
kubernetes實踐之運行aspnetcore webapi微服務
請注意，容器技術圈已邁入后Kubernetes時代！
利用VSTS跟Kubernetes整合進行CI/CD
Asp.net core應用在 Kubernetes上內存使用率過高問題分析
Kubernetes應用部署模型解析（原理篇）
?Kubernetes應用部署模型解析（部署篇）
原文：https://www.cnblogs.com/justmine/p/8620311.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的aspnetcore.webapi实践k8s健康探测机制 - kubernetes的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： kubernetes实践之运行aspne
- 下一篇： 开源服务容错处理库Polly使用文档