不同于標(biāo)準(zhǔn)的云負(fù)載均衡器，Kubernetes服務(wù)自己并不對底層應(yīng)用執(zhí)行健康檢查。反之，服務(wù)通過檢查集群的共享狀態(tài)來判斷pod是否準(zhǔn)備就緒并能夠處理請求。但是如何才能知道pod是否已準(zhǔn)備好呢？
兩種健康檢查：存活性——應(yīng)用是否正確啟動；就緒性——應(yīng)用是否準(zhǔn)備好處理請求。
這兩種健康檢查對于服務(wù)的可恢復(fù)性而言是至關(guān)重要的。它們能確保流量都被路由到健康的微服務(wù)實例，而遠離那些執(zhí)行有問題或者完全不能執(zhí)行的實例。
默認(rèn)情況下，Kubernetes會對每個運行的pod執(zhí)行輕量級的基于進程(個人理解是基于容器是否運行正常的檢查，不知道此處是不是把容器當(dāng)做一個進程來看，具體原理待研究)的存活檢查。如果market-data服務(wù)中某個容器的存活檢查失敗，Kubernetes會嘗試重新啟動該容器（只要該容器的重啟策略沒有被設(shè)置為Never）。每個工作節(jié)點中的Kubelet進程負(fù)責(zé)執(zhí)行該健康檢查。這個進程會持續(xù)查詢?nèi)萜鞯倪\行時環(huán)境（比如Docker引擎）來確定是否需要重新啟動一個容器。
Kubernetes以指數(shù)退避調(diào)度算法來執(zhí)行重啟。如果某個pod在5min后沒有存活，則它會被標(biāo)記出來刪除。如果某個復(fù)制集負(fù)責(zé)管理這個pod，那么控制器會嘗試分配一個新的pod來保持所需的服務(wù)容量。
單憑這一點是不夠的，因為微服務(wù)可能會遇到一些不會導(dǎo)致容器本身失敗的故障場景：由請求飽和引起的死鎖、底層資源超時或普通的編碼錯誤。如果調(diào)度器不能識別此類場景，那么服務(wù)的性能可能會由于服務(wù)路由請求到?jīng)]有響應(yīng)的pod而下降，這可能導(dǎo)致級聯(lián)故障。
為了避免這種情況，需要調(diào)度器不斷檢查容器中應(yīng)用的狀態(tài)，確保它處于存活狀態(tài)并準(zhǔn)備就緒。在Kubernetes中，可以通過配置探針來實現(xiàn)這一點，探針可以是HTTP GET請求、容器中執(zhí)行的腳本或TCP套接字檢查。
market-data-replica-set.yml中的存活探針
livenessProbe:? ---? 在8000端口配置一個存活探針以查詢/ping接口
? httpGet:
? ? path: /ping
? ? port: 8000
? initialDelaySeconds: 10
? timeoutSeconds: 15? ?
readinessProbe:
? ? path: /ping
? ? port: 8000
? initialDelaySeconds: 10
? timeoutSeconds: 15? ? ---? 在8000端口配置一個就緒探針查詢/ping接口
再次使用kubectl來應(yīng)用這一配置以更新復(fù)制集的狀態(tài)。Kubernetes會盡最大能力使用這些探針來確保微服務(wù)實例的健康和活躍。在本例中，存活檢查和就緒檢查都是同一個端點，但是如果微服務(wù)有外部依賴（比如隊列服務(wù)），確保服務(wù)的就緒檢查就依賴于應(yīng)用與那些依賴之間的聯(lián)通性是有意義的。
摘取自 摩根·布魯斯和保羅·A.佩雷拉的《微服務(wù)實戰(zhàn)》
