當前位置：首頁 > 编程语言 > asp.net >内容正文

asp.net

ASP.NET Core on K8S深入学习（6）Health Check

發布時間：2023/12/4 asp.net 38 豆豆

生活随笔收集整理的這篇文章主要介紹了 ASP.NET Core on K8S深入学习（6）Health Check 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

本篇已加入《.NET Core on K8S學習實踐系列文章索引》，可以點擊查看更多容器化技術相關系列文章。預計閱讀時間為10分鐘。

—

關于K8S中的健康監測

　　所謂Health Check，就是健康檢查，即防微杜漸。K8S是一個編排引擎可以幫助我們快捷地部署容器集群，如果部署上錯誤的容器導致服務崩潰，通常情況下我們都會通過一些高可用機制進行故障轉移。但是，前提條件是有健康檢查。

　　K8S自然幫我們考慮到了這個問題，健康檢查是K8S的重要特性之一，默認有健康檢查機制，此外還可以主動設置一些自定義的健康檢查。

　　默認情況下，每個容器啟動時都會執行一個進程，由Dockerfile中的CMD或ENTRYPOINT指定。如果進程退出時的返回碼不為0，則認為容器發生了故障，K8S會根據重啟策略（restartPolicy）重啟容器。

　　例如下面這個例子，它模擬了容器發生故障的場景，注意下面配置文件中的args選項的定義：

apiVersion: v1kind: Podmetadata: name: edc-healthcheck-demo labels: test: healthcheckspec: restartPolicy: OnFailure containers: - name: healthcheck image: busybox imagePullPolicy: IfNotPresent args: - /bin/sh - -c - sleep 10; exit 1

　　其中 sleep 10; exit 1代表啟動10秒之后就非正常退出（返回碼不為0），然后通過kubectl創建Pod：

kubectl apply -f health-check.yaml

　　過一段時間后查看Pod的狀態，如下圖所示：

?　　可以看到，該容器已經重啟了2次。也可以看出，restartPolicy簡單直接暴力有效，不由感嘆重啟大法好！

　　但是，也要正視一個問題：必須等到進程退出后的返回值是非零才會觸發重啟策略，不能直接監測容器是否是健康。

　　那么，K8S中有沒有更好的機制能夠實現智能一點的健康檢查呢？答案就是使用Liveness與Readinesss。

—

Liveness探測

Liveness初體驗

一句話Liveness：如果檢測有問題（如果健康檢查失敗），重啟pod！至于怎么檢測，你說了算（自定義判斷容器是否健康的條件）！　

　　Liveness提供了一些重要的參數：

initialDelaySeconds：容器啟動后第一次執行探測是需要等待多少秒,看運行的服務而定。periodSeconds：執行探測的頻率，默認是10秒，最小1秒。timeoutSeconds：探測超時時間，默認1秒，最小1秒。successThreshold：探測失敗后，最少連續探測成功多少次才被認定為成功，默認是1，對于liveness必須是1，最小值是1。failureThreshold：探測成功后，最少連續探測失敗多少次才被認定為失敗。默認是3。最小值是1.

　　下面實踐一個小例子創建一個Pod：

#command自己定義，例子為 /tmp/healthy 不存在則認為pod有問題，大家根據實際業務來自定義。apiVersion: v1kind: Podmetadata: labels: test: liveness name: liveness-demospec: containers: - name: liveness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf/tmp/healthy; sleep 10 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 10 periodSeconds: 5

　　這里啟動pod后會創建文件夾 /tmp/healthy，30秒后刪除，在我們的設置中，如果 /tmp/healthy 存在，則認為容器處于正常狀態，否則認為發生故障。

　　需要注意的就是livenessProbe部分的定義了：

　　（1）探測方法：通過cat命令查看/tmp/healthy是否存在；如果返回值為0，則探測成功；否則，探測失敗；

　　（2）initialDelaySeconds: 10 => 容器啟動10秒之后開始執行liveness探測；

　　（3）periodSeconds: 5 => 每5秒執行一次liveness探測；如果連續執行3次探測都失敗，那么就會殺掉并重啟容器；

　　下面快速地驗證一下：

　　（1）kubectl創建demo

kubectl apply -f liveness-demo.yaml

　　（2）查看pod日志

kubectl describe pod liveness-demo

　　結果如下圖所示：

?　　30秒之后，/tmp/healthy 被刪除了，liveness探測失敗，又過了幾十秒，重復探測均失敗后，開啟了重啟容器。

Liveness探針

??????上面的例子使用的是Liveness的exec探針，此外K8S還有幾種其他類型的探針：

exec：在容器中執行一個命令，如果命令退出碼返回0則表示探測成功，否則表示失敗
tcpSocket：對指定的容IP及端口執行一個TCP檢查，如果端口是開放的則表示探測成功，否則表示失敗
httpGet：對指定的容器IP、端口及路徑執行一個HTTP Get請求，如果返回的狀態碼在 [200,400)之間則表示探測成功，否則表示失敗

　　針對tcpSocket的例子：這里會檢測80端口是否可以正常訪問；

#檢測80端口是否聯通apiVersion: v1kind: Podmetadata: labels: test: readiness name: readiness-tcpspec: containers: - name: readiness image: nginx readinessProbe: failureThreshold: 3 tcpSocket: port: 80 initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10

　　針對httpGet的例子：這里會檢測index.html文件是否可以正常訪問；

#訪問80端口的index.html文件是否存在apiVersion: v1kind: Podmetadata: labels: test: readiness name: readiness-httpgetspec: containers: - name: readiness image: nginx readinessProbe: failureThreshold: 3 httpGet: path: /index.html port: 80 scheme: HTTP initialDelaySeconds: 10 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10

—

Readiness探測

Readiness初體驗

一句話Readiness：如果檢查失敗，K8S會將該Pod從服務代理的分發后端去除，不再讓其接客（分發請求給該Pod）。如果檢測成功，那么K8S就會將容器加入到分發后端，重新對外接客（對外提供服務）。　

　　下面繼續以上面Liveness的例子來實踐一下：

apiVersion: v1kind: Podmetadata: labels: test: readiness name: readiness-demospec: containers: - name: readiness image: busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf/tmp/healthy; sleep 10 readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 10 periodSeconds: 5

　　readinessProbe的配置語法與livenessProbe完全一致，但執行后的效果卻不一樣，見下圖所示：

　　可以看出：

　　（1）剛被創建時，其READY狀態為不可用；

　　（2）15秒（initialDelaySeconds + periodSeconds = 10 + 5 = 15）之后，第一次進行Readiness探測成功，其READY狀態變為可用。

　　（3）30秒之后，/tmp/healthy被刪除，連續3次Readiness探測均失敗后，其READY狀態又變為了不可用。

　　此外，我們也可以通過 kubectl describe pod readiness-demo 查看到更想起的日志信息。

與Liveness的對比

????????Liveness與Readiness都是K8S的Health Check機制，Liveness探測是重啟容器，而Readiness探測則是將容器設置為不可用，不讓其再接受Service轉發的請求。

　　Liveness與Readiness是獨立執行的，二者無依賴，可以單獨使用也可以同時使用。

—

Health Check在K8S中的應用

在Scale Up中的應用

????? 對于多副本應用，當執行Scale Up操作時，新的副本會作為后端服務加入到Service的負載均衡列表中。但是，很多時候應用的啟動都需要一定的時間做準備（比如加載緩存、連接數據庫等等），這時我們可以通過Readiness探測判斷容器是否真正就緒，從而避免將請求發送到還未真正就緒的后端服務。

　　下面一個示例YAML配置文件定義了Readiness探測，重點關注readinessProbe部分：

apiVersion: apps/v1kind: Deploymentmetadata: name: edc-webapi-deployment namespace: aspnetcorespec: replicas: 2 selector: matchLabels: name: edc-webapi template: metadata: labels: name: edc-webapi spec: containers: - name: edc-webapi-container image: edisonsaonian/k8s-demo:1.2 ports: - containerPort: 80 imagePullPolicy: IfNotPresent readinessProbe: httpGet: scheme: HTTP path: /api/health port: 80 initialDelaySeconds: 10 periodSeconds: 5
---
apiVersion: v1kind: Servicemetadata: name: edc-webapi-service namespace: aspnetcorespec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi

　　對于readinessProbe部分：

　　（1）schema指定了協議，這里是HTTP協議，也可以是HTTPS協議；

　　（2）path指定訪問路徑，這里是我們自定義的一個Controller中的接口：簡單地返回一個狀態碼為200的響應；

[Produces("application/json")] [Route("api/Health")] public class HealthController : Controller { [HttpGet] public IActionResult Get() => Ok("ok"); }

　　（3）port指定端口，這里是容器的端口80；

　　（4）initialDelaySeconds和periodSeconds指定了容器啟動10秒之后開始探測，然后每隔5秒執行探測，如果發生3次以上探測失敗，則該容器會從Service的負載均衡中移除，直到下次探測成功后才會重新加入。

在Rolling Update中的應用

????假設現在有一個正常運行的多副本應用，我們要對其進行滾動更新即Rolling Update，K8S會逐步用新Pod替換舊Pod，結果就有可能發生這樣的一個場景：當所有舊副本被替換之后，而新的Pod由于人為配置錯誤一直無法啟動，因此整個應用將無法處理請求，無法對外提供服務，后果很嚴重！

　　因此，Readiness探測還提供了用于避免滾動更新中出現這種情況的一些解決辦法，比如maxSurge和maxUnavailable兩個參數，用來控制副本替換的數量。

　　繼續以上面的YAML配置文件為例，重點關注strategy部分：

apiVersion: apps/v1kind: Deploymentmetadata: name: edc-webapi-deployment namespace: aspnetcorespec: strategy: rollingupdate: maxSurge: 25% maxUnavailable: 25% replicas: 10 selector: matchLabels: name: edc-webapi template: metadata: labels: name: edc-webapi spec: containers: - name: edc-webapi-container image: edisonsaonian/k8s-demo:1.2 ports: - containerPort: 80 imagePullPolicy: IfNotPresent readinessProbe: httpGet: scheme: HTTP path: /api/health port: 80 initialDelaySeconds: 10 periodSeconds: 5
---
apiVersion: v1kind: Servicemetadata: name: edc-webapi-service namespace: aspnetcorespec: type: NodePort ports: - nodePort: 31000 port: 8080 targetPort: 80 selector: name: edc-webapi

　　（1）maxSurge : 25% => 控制滾動更新過程中副本總數超過預期（這里預期是10個副本 replicas: 10）的上限，可以是數值也可以是百分比，然后向上取整。這里寫的百分比，默認值是25%；

　　如果預期副本數為10，那么副本總數的最大值為RoundUp(10 + 10 * 25%)=13個。

　　（2）maxUnavailable : 25% => 控制滾動更新過程中不可用的副本（這里預期是10個副本 replicas: 10）占預期的最大比例，可以是數值也可以是百分比，然后向下取整，同樣地默認值也是25%；

　　如果預期副本總數為10，那么可用的副本數至少要為10-roundDown(10 * 25%)=10-2=8個。

　　綜上看來，maxSurge的值越大，初始創建的新副本數量就越多；maxUnavaliable值越大，初始銷毀的舊副本數量就越多；

—

小結

本文探索了K8S中的默認健康檢查機制以及Liveness和Readiness兩種各有特點的探測機制，并通過一些小例子進行了說明。不過由于筆者也是初學，對于這一塊沒有過多實踐經驗，因此也是講的比較粗淺，也希望以后能夠有更多的實際經驗分享與各位。

參考資料：

（1）CloudMan，《每天5分鐘玩轉Kubernetes》

（2）李振良，《一天入門Kubernets教程》

（3）馬哥（馬永亮），《Kubernetes快速入門》

（4）華仔，《[譯]Kubernetes最佳實踐：使用Readiness和Liveness探測做Health Check》

（5）benjanmin楊，《K8S中的Health Check》

（6）條子在洗澡，《K8S健康性檢查-探測》

恰童鞋騷年，風華不再正茂，仍想揮斥方遒

點個在看少個bug??

總結

以上是生活随笔為你收集整理的ASP.NET Core on K8S深入学习（6）Health Check的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：对微软的敌视何时休？从一篇语言评论文章
下一篇： ASP.NET Core 使用 JWT