若您的應用程序是面向用戶的，那麼確保持續可用性、盡力達到最短停機時間，是一項無比重要卻也不易的挑戰。因此，想要避免任何中斷，良好地監控應用程序的運行狀況，在此顯得至關重要。
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工作負載配置的HTTPreadinessProbe和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。敬請關注！
閱讀更多 RancherLabs 的文章
