1 什么是就緒檢測、存活檢測、啟動檢測？

我們在 k8s 中使用【readiness】探針是用來判定容器是否準備就緒，是否可以接受流量。當 Pod 內所以容器均就緒，則 Pod 將被認為已 ready，如果沒有，那么將從 service 的 Loader Blance 中剔除該 Pod。

而 k8s 中使用【liveness】探針是用于判定是否需要重啟容器，通常情況下主要用于檢查容器是否無響應，死鎖等，從而通過重啟來提高應用的可用性。

至于k8s 1.6中增加的【starup】探針是用于判定應用程序容器什么時候啟動了，而啟用這個探針主要目的是希望容器在啟動成功后再進行存活性和就緒檢查，確保這些存活、就緒探測器不會影響應用程序的啟動。這可以用于對慢啟動容器進行存活性檢測，避免它們在啟動運行之前就被殺掉。

用最簡單的話概括liveness和startup的區別就是，startup是從0到1的檢測過程，探測成功后再交由liveness接管，而liveness是從1到0的檢測過程。

2 注意事項及最佳實踐

在實際的使用中，很多就緒檢測和存活檢測配置一模一樣，這是不合理的。

比較推薦的做法是：如果存活檢測和就緒檢測使用相同的健康檢測方法，那么需要將?failureThreshold 設置的更大一些，比如就緒檢測設置為3次失敗就設置為未就緒，而存活設置為10次后才讓存活檢測失敗。

原因是：當服務運行出現問題或者直接hang住，我們需要預留一定的緩沖空間，讓就緒檢測更靈敏一點，以在服務重啟之前，先從K8S Service提供的負載均衡上將其流量摘掉，從Endpoint列表中去除。否則負載均衡將會把部分請求繼續分發到已經發生重啟的Pod實例上面。

還有一個地方需要特別注意，使用存活檢測探針時，如果設置不當會引起應用可用性降低甚至是引發雪崩。即存活檢測探針不能引入外部的故障注入，就緒檢測探針是可以的，因為其并不會重啟Pod實例。這個是我們在實踐過程中遇到的比較嚴重的問題。比如在做存活檢測的時候，如果數據庫連接不上，rabbitmq無法連接，甚至于郵箱密碼錯誤或者網絡不穩定，那么可能導致存活檢測不通過，而Pod被強制重啟，從而導致業務中斷，這肯定不是我們想要的情況，所以就需要避免這個外部依賴，避免引起雪崩。

所以最佳的實踐需要區分就緒檢測和存活檢測的接口，存活檢測探針可以僅檢測程序運行與否，而和業務上重度耦合的一些健康檢查可以留到就緒檢測里去實現。

總結

以上是生活随笔為你收集整理的关于 K8S 探针（startupProbe、livenessProbe、readinessProbe）的最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。