本教程將結合生產業務當中用到的業務實際分析去使用liveness probe應該如何做,當然你可以參考官方的文檔，如果官方的示例你沒有完全理解以及如何在生產去使用它，那麼這篇文章將對你去使用liveness probe的原理會產生深刻的理解，以及教會你如何在你的生產業務利用它，以達到高可用的可觀察性，這裏我會還原一個node.js的示例，以及還原代碼並解讀以及解決HTTP活動探針向請求發送到應用程序後端（例如某個服務器）的情況，並根據響應確定應用程序是否正常。
什麼是健康探測模式？
在設計關鍵任務，高可用性應用程序時，彈性是要考慮的最重要方面之一。當應用程序可以快速從故障中恢復時，它便具有彈性。雲原生應用程序通常設計爲使用微服務架構，其中每個組件都位於容器中。爲了確保Kubernetes託管的應用程序高度可用，在設計集羣時需要遵循一些特定的模式。在這些模式中有“健康探測模式”。運行狀況探測模式定義應用程序如何向Kubernetes報告其運行狀況。健康狀態不僅關係到Pod是否已啓動並正在運行，還關係到Pod是否能夠接收和響應請求。隨着Kubernetes對pod的健康狀況有了更多的瞭解，它可以對流量路由和負載平衡做出更明智的決策。因此，應用高可觀察性原則（HOP）可確保您的應用程序收到的每個請求都能及時找到響應。
高可觀察性原理（HOP）
高可觀察性原則是基於容器的應用程序設計原則之一。微服務架構要求每個服務不（也不應該）關心接收者服務如何處理其請求並做出響應。例如，一個向另一個容器發出HTTP請求以驗證用戶身份的容器期望以特定格式進行響應，僅此而已。該請求可能來自NodeJS，而響應則由Python Flask處理。兩個容器都像內部部件隱藏的黑匣子一樣對待彼此。但是，HOP原則要求每個服務必須公開幾個API端點，以揭示其健康狀態，就緒狀態和活動狀態。Kubernetes調用這些端點，因此決定下一步的路由和負載平衡。
設計更好的雲原生應用程序還應該將基本事件記錄到標準錯誤（STDERR）和標準輸出（STDOUT）通道中。此外，此外，像filebeat、logstash或fluentd這樣的日誌採集服務將這些日誌發送到集中監視平臺（例如Prometheus）和日誌聚合系統（例如ELK堆棧）。下圖說明了雲原生應用程序如何遵守健康狀況探測模式和高可觀察性原理。
如何在Kubernetes中應用健康探測模式？
開箱即用的Kubernetes使用其控制器之一（Deployments，ReplicaSets，DaemonSets，StatefulSets）監視Pod的狀態。等）。如果控制器檢測到Pod由於某種原因而崩潰，它將嘗試重新啓動Pod或將其重新安排到另一個節點。但是，pod可能會報告它已啓動並正在運行。但是，它無法正常工作。讓我們舉個例子：您有一個使用Apache作爲其Web服務器的應用程序。您將組件部署在集羣中的多個Pod上。由於庫配置錯誤，因此使用HTTP代碼500（內部服務器錯誤）響應對此應用程序的所有請求。部署檢查Pod的狀態時，它將檢測到Pod正在運行。但是，那不是您的客戶的想法。讓我們將這種不良情況描述如下：
在我們的示例中，Kubernetes正在執行運行狀況檢查過程。在這種類型的檢查中，kubelet不斷探測容器過程。如果檢測到該進程已關閉，則將其重新啓動。如果僅通過重新啓動應用程序即可解決錯誤，並且如果該程序旨在在發生任何故障時自行關閉，則只需按照HOP和運行狀況探測模式進行進程運行狀況檢查即可。不幸的是，並非所有錯誤都會通過重新啓動消失。因此，Kubernetes提供了兩種更全面的檢測Pod故障的方法：活動性探針和就緒性探針。
Liveness Probes
通過“活動性 探針”，kubelet可以執行三種類型的檢查，以確保pod不僅正在運行，而且還準備好接收並充分響應請求：
-
建立對Pod的HTTP請求。該響應應該具有範圍從200到399的HTTP響應代碼。這樣，5xx和4xx代碼表示儘管進程正在運行，但pod仍然有問題。
-
對於暴露非HTTP服務的Pod（例如Postfix郵件服務器），檢查是建立成功的TCP連接。
- 對Pod執行任意命令（內部）。如果命令退出代碼爲0，則檢查成功。
對於官方的示例我們不演示，因爲你直接可以通過官方的示例去驗證它的使用,而這裏我們主要演示http get的方式確保pod不僅正在運行，而且還準備好接收並充分響應請求
活力探針的好處
通常，當Kubernetes注意到您的應用程序崩潰時，kubelet只會重新啓動它。但是，在某些情況下，應用程序已崩潰或死鎖而沒有真正終止。這正是活動探針可以提供幫助的情況！活動探針可以在您的pod或部署規範中包含幾行內容，因此可以將您的Kubernetes應用程序轉變爲自我修復的有機體，可以提供：
- 零停機時間部署
- 以您喜歡的任何方式實施簡單有效的健康監控
- 識別應用程序中潛在的錯誤和缺陷
現在，我們將在行動中展示這些好處，帶您通過成功和失敗的活力探索示例。
講解
在本教程中，我們爲簡單的Node JS服務器創建活動探針。活動探測將向特定服務器路由發送HTTP請求，並且來自服務器的響應將告訴Kubernetes活動探測是通過還是失敗。
第1步：創建爲活動探針準備的Node JS應用
爲了實現一個活躍的探針，我們設計了一個能夠處理它的容器化應用程序。在本教程中，我們對一個簡單的Node JS Web服務器進行了容器化，其中配置了兩條路由以處理來自活動性探針的請求。該應用程序是使用Docker容器運行時進行容器化的，並被推送到公共Docker存儲庫。實現基本服務器功能和路由的代碼位於該server.js 文件中：
'use strict';
const express = require('express');
// Constants
const PORT = 8080;
const HOST = '0.0.0.0';
// App
const app = express();
app.get('/', (req, res) => {
res.send('Hello world');
});
app.get('/health-check',(req,res)=> {
res.send ("Health check passed");
});
app.get('/bad-health',(req,res)=> {
res.status(500).send('Health check did not pass');
});
app.listen(PORT, HOST);
console.log(Running on http://${HOST}:${PORT});在此文件中，我們已經配置了三個響應客戶端GET請求的服務器路由。第一個向服務器的Web根路徑提供請求，該請求從服務器/發送基本問候：
app.get('/', (req, res) => {
res.send('Hello world');
});第二條路徑/health-check返回200 HTTP成功狀態，告知活動探測器我們的應用程序運行正常。默認情況下，任何大於或等於200且小於400的HTTP狀態代碼都表示成功。狀態代碼大於400表示失敗。
app.get(‘/health-check’,(req,res)=> {
res.send (“Health check passed”);
});此應用程序只是一個簡單的示例，它說明了如何配置服務器以響應活動性探針。實現HTTP活動度探針所需要做的就是在應用程序中分配一些路徑，並將服務器的端口公開給Kubernetes。就如此容易！
步驟2：將Pod配置爲使用活動探針
讓我們創建一個pod規範，爲我們的Node JS應用程序定義一個活動性探針：
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: zhaocheng172/k8s-liveliness:latest
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /health-check
port: 8080
initialDelaySeconds: 3
periodSeconds: 3
failureThreshold: 2讓我們討論該規範與活動性探針相關的關鍵字段：
spec.containers.livenessProbe.httpGet.path— HTTP服務器上處理活動性探測的路徑。注意：默認情況下，spec.livenessProbe.httpGet.host 設置爲Pod的IP。由於我們將從集羣內部訪問我們的應用程序，因此我們無需指定外部主機。
spec.containers.livenessProbe.httpGet.port—用於訪問HTTP服務器的端口名稱或端口號。端口號必須在1到65535之間。
spec.containers.livenessProbe.initialDelaySeconds —自啓動容器以來，可以啓動活動性探針的秒數。
spec.containers.livenessProbe.periodSeconds-多長時間執行一次活躍度調查。默認值爲10秒，最小值爲1
spec.containers.livenessProbe.failureThreshold—如果在Pod啓動時探測失敗，則嘗試執行活動探測。放棄進行活動探測的任何嘗試都意味着重新啓動Pod。該字段的默認值爲，3最小值爲1。
讓我們保存此規範liveness.yaml 並創建運行以下命令的Pod：
kubectl create -f liveness.yaml
pod “liveness-http” created如你所見。我們將其定義/health-check爲活動探針的服務器路徑。在這種情況下，我們的Node JS服務器將始終返回成功200狀態代碼。這意味着活動性探測將始終成功，並且窗格將繼續運行。
讓我們爲應用程序容器添加一個外殼，以查看服務器發送的響應：
kubectl exec -it liveness-http — / bin / bash在容器內時，安裝cURL以將GET請求發送到服務器：
apt-get update
apt-get install curl現在，我們可以嘗試訪問服務器以檢查/health-check路由的響應。不要忘記服務器正在偵聽端口8080：
curl localhost:8080/health-check
Health check passed如果活動探針通過（如本示例中所示），則pod將繼續運行而沒有任何錯誤，並觸發重新啓動。但是，當活動性探針失敗時會發生什麼？
爲了說明這一點，讓我們將字段中指示的服務器路徑更改livenessProbe.httpGet.path爲/bad-health。首先，從輸入的容器中退出外殼程序exit，然後在中更改路徑名liveness.yaml。進行必要的更改後，刪除pod。
現在，我們的活動探測將向/bad-health路徑返回500 HTTP錯誤的路徑發送請求。此錯誤將使kubelet重新啓動pod。由於我們的活動探測始終失敗，因此pod將永遠不會再次運行。讓我們驗證一下生動性探針實際上是否失敗：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 1m default-scheduler Successfully assigned liveness-http to minikube
Normal SuccessfulMountVolume 1m kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-9wdtd"
Normal Started 1m (x3 over 1m) kubelet, minikube Started container
Warning Unhealthy 57s (x4 over 1m) kubelet, minikube Liveness probe failed: HTTP probe failed with statuscode: 500
Normal Killing 57s (x3 over 1m) kubelet, minikube Killing container with id docker://liveness:Container failed liveness probe.. Container will be killed and recreated.
Warning BackOff 56s (x2 over 57s) kubelet, minikube Back-off restarting failed container
Normal Pulling 42s (x4 over 1m) kubelet, minikube pulling image "supergiantkir/k8s-liveliness"
Normal Pulled 40s (x4 over 1m) kubelet, minikube Successfully pulled image "supergiantkir/k8s-liveliness"
Normal Created 40s (x4 over 1m) kubelet, minikube Created container首先，您可能已經注意到，活動探針恰好在“spec.containers.livenessProbe.initialDelaySeconds之後”中指定的三秒鐘後啓動，該探針以狀態碼500觸發失敗，該狀態碼觸發了殺死和重新創建容器的操作。
現在，您知道如何創建活動性探針以檢查Kubernetes應用程序的運行狀況。
注意：在本教程中，我們使用了兩個始終返回成功或錯誤狀態代碼的服務器路由。這足以說明活躍度探針如何工作，但是，在生產中，您將需要一種方法來評估應用程序的健康狀況，並將成功或失敗響應發送回kubelet。
結論
如您所見，活動探針在保持應用程序健康並確保零停機時間方面非常強大。
參考地址：
https://supergiant.io/blog/creating-liveness-probes-for-your-node-js-application-in-kubernetes/
南方的小鎮陰雨的冬天沒有北方冷
她不需要臃腫的棉衣去遮蓋她似水的面容
——鼓樓 趙雷。
【一個懂你的雲原生知識共享平臺】歡迎掃描下方二維碼關注
