K8S使用就緒和存活探針配置健康檢查是什么

K8S使用就緒和存活探針配置健康檢查是什么，針對這個(gè)問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

健康檢查

健康檢查（Health Check）可用于服務(wù)運(yùn)行的狀態(tài)監(jiān)控，比如騰訊旗下的DNSPOD的D監(jiān)控，要求配置一個(gè)訪問路徑以判斷網(wǎng)站是否可以正常訪問實(shí)際上就是一個(gè)健康檢查，當(dāng)發(fā)現(xiàn)健康檢查失敗時(shí)會發(fā)送一個(gè)郵件通知或者短信來告知網(wǎng)站管理員進(jìn)行維修。

K8S流量轉(zhuǎn)發(fā)

而在現(xiàn)代一些分布式系統(tǒng)中，用戶訪問不再是單臺主機(jī)，而是一個(gè)由成百上千臺實(shí)例組成的集群，用戶請求通過負(fù)載均衡器分發(fā)到不同的實(shí)例，負(fù)載均衡幫助解決單臺服務(wù)器的訪問壓力，同時(shí)提高了系統(tǒng)的高可用性，而健康檢查常常作為當(dāng)前實(shí)例是否“可用”的判斷標(biāo)準(zhǔn)。即：當(dāng)系統(tǒng)發(fā)現(xiàn)某臺實(shí)例健康檢查不通過，負(fù)載均衡器將不會把流量導(dǎo)向該實(shí)例。

現(xiàn)在的云服務(wù)廠商比如AWS一般都為負(fù)載均衡配備了健康檢查，而Kubernetes提供了兩種探針來檢查容器的狀態(tài)，Liveliness和Readiness，根據(jù)官方文檔，Liveliness探針是為了查看容器是否正在運(yùn)行，翻譯為存活探針（livenessProbe），Readiness探針是為了查看容器是否準(zhǔn)備好接受HTTP請求，翻譯為就緒探針（readinessProbe）。
在Kubernetes中，Pod是Kubernetes創(chuàng)建及管理的最小的可部署的計(jì)算單元，一個(gè)Pod由一個(gè)或者多個(gè)容器（Docker，rocket等等）組成，這些容器共享內(nèi)存，網(wǎng)絡(luò)以及運(yùn)行容器的方式。

在Kubernetes上下文中存活探針和就緒探針被稱作健康檢查。這些容器探針是一些周期性運(yùn)行的小進(jìn)程，這些探針返回的結(jié)果（成功，失敗或者未知）反映了容器在Kubernetes的狀態(tài)?；谶@些結(jié)果，Kubernetes會判斷如何處理每個(gè)容器，以保證彈性，高可用性和更長的正常運(yùn)行時(shí)間。

就緒探針

就緒探針旨在讓Kubernetes知道你的應(yīng)用是否準(zhǔn)備好為請求提供服務(wù)。Kubernetes只有在就緒探針通過才會把流量轉(zhuǎn)發(fā)到Pod。如果就緒探針檢測失敗，Kubernetes將停止向該容器發(fā)送流量，直到它通過。

存活探針

Liveness探測器是讓Kubernetes知道你的應(yīng)用是否活著。如果你的應(yīng)用還活著，那么Kubernetes就讓它繼續(xù)存在。如果你的應(yīng)用程序已經(jīng)死了，Kubernetes將移除Pod并重新啟動(dòng)一個(gè)來替換它。

工作過程

讓我們看看兩個(gè)場景，來看看就緒探針和存活探針怎樣幫助我們構(gòu)建更高可用的的系統(tǒng)。

就緒探針

一個(gè)應(yīng)用往往需要一段時(shí)間來預(yù)熱和啟動(dòng)，比如一個(gè)后端項(xiàng)目的啟動(dòng)需要連接數(shù)據(jù)庫執(zhí)行數(shù)據(jù)庫遷移等等，一個(gè)Spring項(xiàng)目的啟動(dòng)也需要依賴Java虛擬機(jī)。即使該過程已啟動(dòng)，您的服務(wù)在啟動(dòng)并運(yùn)行之前也無法運(yùn)行。應(yīng)用在完全就緒之前不應(yīng)接收流量，但默認(rèn)情況下，Kubernetes會在容器內(nèi)的進(jìn)程啟動(dòng)后立即開始發(fā)送流量。通過就緒探針探測，直到應(yīng)用程序完全啟動(dòng)，然后才允許將流量發(fā)送到新副本。

就緒探針的工作過程

存活探針

讓我們想象另一種情況，當(dāng)我們的應(yīng)用在成功啟動(dòng)以后因?yàn)橐恍┰颉板礄C(jī)”，或者遇到死鎖情況，導(dǎo)致它無法響應(yīng)用戶請求。
在默認(rèn)情況下，Kubernetes會繼續(xù)向Pod發(fā)送請求，通過使用存活探針來檢測，當(dāng)發(fā)現(xiàn)服務(wù)不能在限定時(shí)間內(nèi)處理請求（請求錯(cuò)誤或者超時(shí)），就會重新啟動(dòng)有問題的pod。

存活探針的工作過程

探針類型

探針類型是指通過何種方式來進(jìn)行健康檢查，K8S有三種類型的探測：HTTP，Command和TCP。
HTTP
HTTP探測可能是最常見的探針類型。即使應(yīng)用不是HTTP服務(wù)，也可以創(chuàng)建一個(gè)輕量級HTTP服務(wù)器來響應(yīng)探測。比如讓Kubernetes通過HTTP訪問一個(gè)URL，如果返回碼在200到300范圍內(nèi)，就將應(yīng)用程序標(biāo)記為健康狀態(tài)，否則它被標(biāo)記為不健康。
更多關(guān)于HTTP探測可參考這里。

命令
對于命令探測，是指Kubernetes在容器內(nèi)運(yùn)行命令。如果命令以退出代碼0返回，則容器將標(biāo)記為正常。否則，它被標(biāo)記為不健康。
更多關(guān)于命令探測可參考這里。

TCP
最后一種類型的探測是TCP探測，Kubernetes嘗試在指定端口上建立TCP連接。如果它可以建立連接，容器被認(rèn)為是健康的; 如果它不能被認(rèn)為是不健康的。這常用于對gRPC或FTP服務(wù)的探測。

更多關(guān)于TCP探測可參考這里。

初始探測延遲

我們可以配置K8S健康檢查運(yùn)行的頻率，檢查成功或失敗的條件，以及響應(yīng)的超時(shí)時(shí)間?？蓞⒖加嘘P(guān)配置探針的文檔。

存活探針探測失敗會導(dǎo)致pod重新啟動(dòng)，所以配置初始探測延遲initialDelaySeconds十分重要，要確保在應(yīng)用準(zhǔn)備之后探針才啟動(dòng)。否則，應(yīng)用將無限重啟！

我建議使用p99啟動(dòng)時(shí)間作為initialDelaySeconds，或者取平均啟動(dòng)時(shí)間外加一個(gè)buffer。同時(shí)根據(jù)應(yīng)用程序的啟動(dòng)時(shí)間更新這個(gè)值。

舉例

以下面的一個(gè)K8S的配置代碼為例，

• K8S將在Pod開始啟動(dòng)后120s(initialDelaySeconds)后利用HTTP訪問8080端口的/actuator/health，如果超過10s或者返回碼不在200~300內(nèi)，就緒檢查就失敗

• 類似的，在Pod運(yùn)行過程中，K8S仍然會每隔5s(periodSeconds檢測8080端口的/actuator/health

apiVersion: apps/v1beta1
kind: Deployment
...
...
        readinessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 120
          timeoutSeconds: 10
        livenessProbe:
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 60
          timeoutSeconds: 10
          periodSeconds: 5

關(guān)于K8S使用就緒和存活探針配置健康檢查是什么問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。