在Kubernetes中爲Node.js應用程序建立活動性探針

本教程將結合生產業務當中用到的業務實際分析去使用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/

南方的小鎮陰雨的冬天沒有北方冷
她不須要臃腫的棉衣去遮蓋她似水的面容
——鼓樓 趙雷。
【一個懂你的雲原生知識共享平臺】

歡迎掃描下方二維碼關注