15分鐘快速瞭解如何在Kubernetes中配置健康檢查

若您的應用程序是面向用戶的，那麼確保持續可用性、盡力達到最短停機時間，是一項無比重要卻也不易的挑戰。所以，想要避免任何中斷，良好地監控應用程序的運行情況，在此顯得相當重要。

Rancher 1.6中的健康檢查

Rancher 1.6中的編排引擎Cattle，具備爲部署好的服務添加HTTP或TCP健康檢查的功能。Rancher本身的健康檢查微服務提供了健康檢查支持。你能夠在這此瞭解更多信息：

https://rancher.com/docs/rancher/v1.6/en/cattle/health-checks/

簡單來講，Cattle用戶能夠向服務添加TCP健康檢查。Rancher的健康檢查容器會在不一樣的主機上啓動，它們會測試TCP鏈接是否在服務容器的指定端口打開。請注意，對於最新版本（v1.6.20），健康檢查容器也與服務容器安排在同一主機上。

在部署服務時，也能夠添加HTTP健康檢查。您能夠要求Rancher在指定路徑上發出HTTP請求，並指定預期的響應。

這些健康檢查會按期完成，您能夠自行配置檢查的間隔週期，重試/超時也是可配置的。若是健康檢查失敗，您還能夠指示Rancher是否以及什麼時候從新建立容器。

例如，在Cattle上運行Nginx鏡像的服務，並使用以下配置進行HTTP健康檢查：

健康檢查的參數顯示在rancher-compose.yml文件中，而不是docker-compose.yml，由於健康檢查功能是由Rancher實現的。

下面讓咱們來看看咱們是否能夠在Rancher 2.0中配置相應的健康檢查。

Rancher 2.0中的健康檢查

在2.0中，Rancher使用的是原生的Kubernetes健康檢查機制：livenessProbe和readinessProbe。

參考此文檔的定義，探針（probe）是由Kubelet在容器上按期執行的診斷：連接。在Rancher 2.0中，與Rancher 1.6中的跨主機健康檢查相比，健康檢查由本地運行的Kubelet完成。

快速Kubernetes健康檢查摘要

• livenessProbe

livenessProbe是對容器執行的操做，用於檢查容器是否正在運行。若是探針報告失敗，Kubernetes將終止pod容器，並根據規範中指定的從新啓動策略從新啓動它。

• readinessProbe

readinessProbe用於檢查容器是否已準備好接受請求及知足請求。當readinessProbe失敗時，則不會經過公共端點公開pod容器，所以容器不會接收到任何請求。

若是您的工做負載在處理請求以前忙於執行某些啓動例程，則最好爲工做負載配置readinessProbe。

能夠爲Kubernetes工做負載配置如下類型的livenessProbe和readinessProbe：

• tcpSocket – Kubelet會檢查是否能夠針對指定端口上的容器IP地址打開TCP鏈接。

• httpGet -在指定路徑上發出 HTTP / HTTPS GET請求，若是它返回200和400之間的HTTP響應代碼，則報告爲成功。

• exec - Kubelet在容器內執行指定的命令，並檢查命令是否以狀態0退出。

您可在此查看上述探針的更多配置詳細信息：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes

在Rancher 2.0中配置健康檢查

經過Rancher UI，用戶能夠向Kubernetes工做負載添加TCP或HTTP健康檢查。默認狀況下，Rancher會要求您爲工做負載配置readinessProbe，並使用相同的配置應用livenessProbe。您也能夠選擇定義單獨的livenessProbe。

若是健康檢查失敗，則容器會根據工做負載規範中定義的restartPolicy從新啓動。這至關於之前的rancher-compose.yml文件中的strategy參數，那時這一參數是用於使用Cattle中的健康檢查的1.6服務的。

TCP健康檢查

在Rancher 2.0中部署工做負載時，用戶能夠配置TCP健康檢查，以檢查是否能夠在特定端口打開TCP鏈接。

如下是Kubernetes YAML規範，也就是爲上文說的Nginx工做負載所配置的TCP readinessProbe。Rancher還使用相同的配置爲您的工做負載添加了livenessProbe。

從1.6到2.0，健康檢查參數的變化：

port 變成 tcpSocket.port

response_timeout 變成

timeoutSeconds

healthy_threshold 變成 failureThreshold

unhealthy_threshold 變成

successThreshold

interval 變成 periodSeconds

initializing_timeout 變成

initialDelaySeconds

strategy 變成 restartPolicy

HTTP健康檢查

您還能夠指定HTTP健康檢查，並在pod容器中提供Kubelet將發出HTTP / HTTPS GET請求的路徑。可是，不一樣於Rancher 1.6中支持任何HTTP方法，Kubernetes僅支持HTTP / HTTPS GET請求。

下面是Kubernetes YAML規範，顯示了爲上文所說的Nginx工做負載配置的HTTP readinessProbe和livenessProbe。

健康檢查在行動

如今讓咱們看看當Kubernetes中的健康檢查失敗時會發生什麼，以及工做負載如何恢復。

假定在咱們的Nginx工做負載上執行上述HTTP健康檢查，在/index.html路徑上執行HTTP GET。爲了刻意使健康檢查失敗，我使用Rancher中的Execute Shell UI選項在pod容器中執行了一個exec。

exec容器後，我移動了健康檢查執行GET的文件。

readinessProbe和livenessProbe檢查失敗，而且工做負載狀態已變爲「不可用」。

Kubernetes很快就殺死了原pod並從新建立了pod，而且因爲restartPolicy設置爲了Always，工做負載很快恢復了。

使用Kubectl，您能夠看到這些健康檢查事件日誌：

小提示：Rancher 2.0 UI提供了從Kubernetes Cluster視圖啓動Kubectl的功能，您能夠在該視圖中在集羣對象上運行原生的Kubernetes命令。

將健康檢查從Docker Compose遷移到Kubernetes Yaml？

Rancher 1.6經過本身的微服務提供了健康檢查，這就是爲何Cattle用戶添加到服務中的健康檢查參數會出如今rancher-compose.yml文件而不是docker-compose.yml配置文件中。

咱們以前在文章《如何簡潔優雅地實現Kubernetes服務暴露》中使用的Kompose工具適用於標準的docker-compose.yml參數，所以沒法解析Rancher健康檢查構造。目前，咱們暫時沒法使用此工具將Rancher 健康檢查從compose配置轉換爲Kubernetes Yaml。

結 論

如本文所述，可用於在Rancher 2.0中添加TCP或HTTP健康檢查的配置參數與Rancher 1.6很是類似。Cattle服務使用的健康檢查配置能夠徹底轉換爲2.0而不會丟失任何功能。

在後續文章中，咱們還會探討如何將Cattle支持的調度選項映射到Rancher 2.0中的Kubernetes。敬請關注！