在設(shè)計關(guān)鍵任務(wù)、高可用應(yīng)用程序時，彈性是要考慮的最重要因素之一。

當(dāng)應(yīng)用程序可以快速從故障中恢復(fù)時，它便具有彈性。

云原生應(yīng)用程序通常設(shè)計為使用微服務(wù)架構(gòu)，其中每個組件都位于容器中。為了確保Kubernetes托管的應(yīng)用程序高可用，在設(shè)計集群時需要遵循一些特定的模式，其中有“健康探測模式”。應(yīng)用 高可觀察性原則 (HOP)可確保您的應(yīng)用程序收到的每個請求都能及時找到響應(yīng)。

The High Observability Principle (HOP)

高可觀察性原則是基于容器的應(yīng)用程序設(shè)計原則之一。微服務(wù)體系要求每個服務(wù)不關(guān)心(也不應(yīng)該關(guān)心)被調(diào)用方如何處理請求。

HOP原則要求每個服務(wù)必須公開幾個API端點，其意義在于揭示服務(wù)健康狀態(tài)，Kubernetes調(diào)用這些端點，決定下一步的路由和負(fù)載平衡。

設(shè)計良好的云原生程序應(yīng)將日志事件記錄到STDERR和STDOUT，由logstash、Fluent等日志攝取服務(wù)將這些日志運送到集中式監(jiān)控(例如Prometheus)和日志聚合系統(tǒng)(例如ELK)。下圖說明了云原生應(yīng)用程序如何遵守健康狀況探測模式和高可觀察性原則。

How to Apply Health Probe Pattern in Kubernetes?

我之前寫過ASP.NetCore + Docker健康檢查的原創(chuàng):[web程序暴露http健康檢查端點，平臺輪詢探測]， Kubernetes針對不同場合細(xì)化了探針，更為強大的是給出對應(yīng)決策。

Liveness Probes

使用[存活探針]判斷什么時候重啟容器。

使用存活探針檢查容器本身是否無響應(yīng)、死鎖， 有時候重啟容器常常能解決此類問題。

我們以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í)行首次探測 
      periodSeconds: 5         # 間隔5秒輪詢 

• 在第5秒kubectl開始首次liveness探測
• 在30秒進(jìn)行的每次探測均成功
• 30s之后容器內(nèi)文件被刪除，之后間隔5s的探測會失敗，根據(jù)liveness默認(rèn)配置連續(xù)3次失敗就會放棄探測，放棄探測意味著重啟容器，故容器會在第45s重啟
• 重啟之后又開始以上流程， 故可以看到此探針以重啟的決策嘗試修復(fù)應(yīng)用問題。

這個探針會體現(xiàn)到 kubectl get pod 的 RESTARTS 列

Readiness Probes

使用[就緒探針]判斷容器是否就緒，是否可以接受流量。

Pod內(nèi)所有容器ready，則該Pod被認(rèn)為ready，當(dāng)pod沒有ready，將會從服務(wù)負(fù)載均衡中移除。

有些時候，應(yīng)用程序臨時不可用(加載大量數(shù)據(jù)或者依賴外部服務(wù))，這個時候，重啟這個Pod無濟(jì)于事，同時你也不希望請求被發(fā)送到該Pod

下面的應(yīng)用強依賴mongodb，我們針對這些依賴項設(shè)置了readiness探針

services.AddHealthChecks() 
    .AddCheck<MongoHealthCheck>(nameof(MongoHealthCheck), tags: new[] { "readyz" }); 
// ---------------------- 
app.UseHealthChecks("/readyz", new HealthCheckOptions 
{ 
        Predicate = (check) => check.Tags.Contains("readyz") 
}); 

以下是探測Mongodb的連通性

sealed class MongoHealthCheck : IHealthCheck 
    {        private readonly IMongoDatabase _defaultMongoDatabase; 
        public MongoHealthCheck(IDefaultMongoDatabaseProvider defaultMongoDatabaseProvider) 
        {            _defaultMongoDatabase = defaultMongoDatabaseProvider.GetDatabase();        }        public async Task<HealthCheckResult> CheckHealthAsync(HealthCheckContext context, CancellationToken cancellationToken = default) 
        {            var doc = await _defaultMongoDatabase.RunCommandAsync( 
                new BsonDocumentCommand<BsonDocument>( 
                    new BsonDocument() { 
                        { "ping", "1" } 
                    }),                 cancellationToken: cancellationToken);            var ok = doc["ok"].ToBoolean(); 
            if (ok) 
            {                return HealthCheckResult.Healthy("OK"); 
            }            return HealthCheckResult.Unhealthy("NotOK"); 
        }    } 

對于依賴項的探測，探測周期和超時時間可以設(shè)置的稍長一點

readinessProbe: 
  httpGet: 
    path: /readyz 
    port: 80 
  initialDelaySeconds: 5 
  periodSeconds: 60     # 60s探測一次 
  timeoutSeconds: 30    # 每次探測30s超時，與應(yīng)用建立與依賴項的連接超時時間一致 
  failureThreshold: 3   # 連續(xù)3次探測失敗,該Pod會被標(biāo)記為`Unready` 

Startup Probes

使用[啟動探針]判斷容器應(yīng)用是否已經(jīng)啟動。如果配置了這個探針，則該探針成功之前將會禁用存活和就緒探針。

配置探針

• initialDelaySeconds：容器啟動，探針延后工作，默認(rèn)是0s
• periodSeconds 探針探測周期，默認(rèn)10s
• timeoutSeconds： 探針工作的超時時間，默認(rèn)1s
• successThreshold： 連續(xù)幾次探測成功，該探針被認(rèn)為是成功的，默認(rèn)1次
• failureThreshold： 連續(xù)幾次探測失敗，該探針被認(rèn)為最終失敗，對于livenes探針最終失敗意味著重啟，對于readiness探針意味著該pod Unready, 默認(rèn)3次。

強烈建議根據(jù)應(yīng)用結(jié)構(gòu)合理設(shè)置探針參數(shù)，避免不切實際的認(rèn)定失敗導(dǎo)致的頻繁重啟或 Unready。

結(jié)論：

• Kubernetes生態(tài)這么龐大，為啥單獨拎出k8s探針， 是因為k8s探針是與應(yīng)用程序結(jié)構(gòu)密切相關(guān)的機制。

就使用方式看：

• 存活探針：用于快速判斷應(yīng)用進(jìn)程是否無響應(yīng)，嘗試重啟修復(fù);
• 就緒探針：判斷應(yīng)用及依賴項是否就緒，是否可以分配流量，如果不能就標(biāo)記Unready，從負(fù)載均衡器中移除該Pod

Kubernetes存活、就緒探針可以極大地提高服務(wù)的健壯性和彈性，并提供出色的最終用戶體驗。