建站
咨詢
售后
建站咨詢
新聞中心
Kubernetes 存活、就緒探針
作者：閃念基因 2020-09-10 13:51:48
云計(jì)算 云原生應(yīng)用程序通常設(shè)計(jì)為使用微服務(wù)架構(gòu)，其中每個(gè)組件都位于容器中。為了確保Kubernetes托管的應(yīng)用程序高可用，在設(shè)計(jì)集群時(shí)需要遵循一些特定的模式，其中有“健康探測(cè)模式”。應(yīng)用 高可觀察性原則 (HOP)可確保您的應(yīng)用程序收到的每個(gè)請(qǐng)求都能及時(shí)找到響應(yīng)。
在設(shè)計(jì)關(guān)鍵任務(wù)、高可用應(yīng)用程序時(shí)，彈性是要考慮的最重要因素之一。
當(dāng)應(yīng)用程序可以快速?gòu)墓收现谢謴?fù)時(shí)，它便具有彈性。
云原生應(yīng)用程序通常設(shè)計(jì)為使用微服務(wù)架構(gòu)，其中每個(gè)組件都位于容器中。為了確保Kubernetes托管的應(yīng)用程序高可用，在設(shè)計(jì)集群時(shí)需要遵循一些特定的模式，其中有“健康探測(cè)模式”。應(yīng)用 高可觀察性原則 (HOP)可確保您的應(yīng)用程序收到的每個(gè)請(qǐng)求都能及時(shí)找到響應(yīng)。
The High Observability Principle (HOP)
高可觀察性原則是基于容器的應(yīng)用程序設(shè)計(jì)原則之一。微服務(wù)體系要求每個(gè)服務(wù)不關(guān)心(也不應(yīng)該關(guān)心)被調(diào)用方如何處理請(qǐng)求。
HOP原則要求每個(gè)服務(wù)必須公開(kāi)幾個(gè)API端點(diǎn)，其意義在于揭示服務(wù)健康狀態(tài)，Kubernetes調(diào)用這些端點(diǎn)，決定下一步的路由和負(fù)載平衡。
設(shè)計(jì)良好的云原生程序應(yīng)將日志事件記錄到STDERR和STDOUT，由logstash、Fluent等日志攝取服務(wù)將這些日志運(yùn)送到集中式監(jiān)控(例如Prometheus)和日志聚合系統(tǒng)(例如ELK)。下圖說(shuō)明了云原生應(yīng)用程序如何遵守健康狀況探測(cè)模式和高可觀察性原則。
How to Apply Health Probe Pattern in Kubernetes?
我之前寫過(guò)ASP.NetCore + Docker健康檢查的原創(chuàng):[web程序暴露http健康檢查端點(diǎn)，平臺(tái)輪詢探測(cè)]， Kubernetes針對(duì)不同場(chǎng)合細(xì)化了探針，更為強(qiáng)大的是給出對(duì)應(yīng)決策。
Liveness Probes
使用[存活探針]判斷什么時(shí)候重啟容器。
使用存活探針檢查容器本身是否無(wú)響應(yīng)、死鎖， 有時(shí)候重啟容器常常能解決此類問(wèn)題。
我們以kubernetes官方demo為例：
- apiVersion: v1
- kind: Pod
- metadata:
- labels:
- test: liveness
- name: liveness-exec
- spec:
- containers:
- - name: liveness
- image: busybox
- args:
- - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
- livenessProbe:
- exec:
- command:
- - cat
- - /tmp/healthy
- initialDelaySeconds: 5 # 指示kubectl等待5s才執(zhí)行首次探測(cè)
- periodSeconds: 5 # 間隔5秒輪詢
- 在第5秒kubectl開(kāi)始首次liveness探測(cè)
- 在30秒進(jìn)行的每次探測(cè)均成功
- 30s之后容器內(nèi)文件被刪除，之后間隔5s的探測(cè)會(huì)失敗，根據(jù)liveness默認(rèn)配置連續(xù)3次失敗就會(huì)放棄探測(cè)，放棄探測(cè)意味著重啟容器，故容器會(huì)在第45s重啟
- 重啟之后又開(kāi)始以上流程， 故可以看到此探針以重啟的決策嘗試修復(fù)應(yīng)用問(wèn)題。
這個(gè)探針會(huì)體現(xiàn)到 kubectl get pod 的 RESTARTS 列
Readiness Probes
使用[就緒探針]判斷容器是否就緒，是否可以接受流量。
Pod內(nèi)所有容器ready，則該P(yáng)od被認(rèn)為ready，當(dāng)pod沒(méi)有ready，將會(huì)從服務(wù)負(fù)載均衡中移除。
有些時(shí)候，應(yīng)用程序臨時(shí)不可用(加載大量數(shù)據(jù)或者依賴外部服務(wù))，這個(gè)時(shí)候，重啟這個(gè)Pod無(wú)濟(jì)于事，同時(shí)你也不希望請(qǐng)求被發(fā)送到該P(yáng)od
下面的應(yīng)用強(qiáng)依賴mongodb，我們針對(duì)這些依賴項(xiàng)設(shè)置了readiness探針
- services.AddHealthChecks()
- .AddCheck
(nameof(MongoHealthCheck), tags: new[] { "readyz" }); - // ----------------------
- app.UseHealthChecks("/readyz", new HealthCheckOptions
- {
- Predicate = (check) => check.Tags.Contains("readyz")
- });
以下是探測(cè)Mongodb的連通性
- sealed class MongoHealthCheck : IHealthCheck
- { private readonly IMongoDatabase _defaultMongoDatabase;
- public MongoHealthCheck(IDefaultMongoDatabaseProvider defaultMongoDatabaseProvider)
- { _defaultMongoDatabase = defaultMongoDatabaseProvider.GetDatabase(); } public async Task
CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default) - { var doc = await _defaultMongoDatabase.RunCommandAsync(
- new BsonDocumentCommand
( - new BsonDocument() {
- { "ping", "1" }
- }), cancellationToken: cancellationToken); var ok = doc["ok"].ToBoolean();
- if (ok)
- { return HealthCheckResult.Healthy("OK");
- } return HealthCheckResult.Unhealthy("NotOK");
- } }
對(duì)于依賴項(xiàng)的探測(cè)，探測(cè)周期和超時(shí)時(shí)間可以設(shè)置的稍長(zhǎng)一點(diǎn)
- readinessProbe:
- httpGet:
- path: /readyz
- port: 80
- initialDelaySeconds: 5
- periodSeconds: 60 # 60s探測(cè)一次
- timeoutSeconds: 30 # 每次探測(cè)30s超時(shí)，與應(yīng)用建立與依賴項(xiàng)的連接超時(shí)時(shí)間一致
- failureThreshold: 3 # 連續(xù)3次探測(cè)失敗,該P(yáng)od會(huì)被標(biāo)記為`Unready`
Startup Probes
使用[啟動(dòng)探針]判斷容器應(yīng)用是否已經(jīng)啟動(dòng)。如果配置了這個(gè)探針，則該探針成功之前將會(huì)禁用存活和就緒探針。
配置探針
- initialDelaySeconds：容器啟動(dòng)，探針延后工作，默認(rèn)是0s
- periodSeconds 探針探測(cè)周期，默認(rèn)10s
- timeoutSeconds： 探針工作的超時(shí)時(shí)間，默認(rèn)1s
- successThreshold： 連續(xù)幾次探測(cè)成功，該探針被認(rèn)為是成功的，默認(rèn)1次
- failureThreshold： 連續(xù)幾次探測(cè)失敗，該探針被認(rèn)為最終失敗，對(duì)于livenes探針最終失敗意味著重啟，對(duì)于readiness探針意味著該pod Unready, 默認(rèn)3次。
強(qiáng)烈建議根據(jù)應(yīng)用結(jié)構(gòu)合理設(shè)置探針參數(shù)，避免不切實(shí)際的認(rèn)定失敗導(dǎo)致的頻繁重啟或 Unready。
結(jié)論：
- Kubernetes生態(tài)這么龐大，為啥單獨(dú)拎出k8s探針， 是因?yàn)閗8s探針是與應(yīng)用程序結(jié)構(gòu)密切相關(guān)的機(jī)制。
就使用方式看：
- 存活探針：用于快速判斷應(yīng)用進(jìn)程是否無(wú)響應(yīng)，嘗試重啟修復(fù);
- 就緒探針：判斷應(yīng)用及依賴項(xiàng)是否就緒，是否可以分配流量，如果不能就標(biāo)記Unready，從負(fù)載均衡器中移除該P(yáng)od
Kubernetes存活、就緒探針可以極大地提高服務(wù)的健壯性和彈性，并提供出色的最終用戶體驗(yàn)。
新聞名稱：Kubernetes存活、就緒探針
分享網(wǎng)址：http://m.5511xx.com/article/dhphhsp.html
