站在用戶的角度思考問題，與客戶深入溝通，找到昭通網(wǎng)站設計與昭通網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站制作、網(wǎng)站設計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)絡空間、企業(yè)郵箱。業(yè)務覆蓋昭通地區(qū)。

作者|??阿里云智能事業(yè)群技術專家牛秋霖（冬島）

導讀：從頭開發(fā)一個 Serverss 引擎并不是一件容易的事情，今天咱們就從 Knative 的健康檢查說起。通過健康檢查這一個點來看看 Serverless 模式和傳統(tǒng)的模式都有哪些不同，以及 Knative 針對 Serverless 場景都做了什么思考。

Knative Serving 模塊的核心原理如下圖所示，圖中的 Route 可以理解成是 Istio Gateway 的角色。

• 當縮容到零時進來的流量就會指到 Activator 上面；
• 當 Pod 數(shù)不為零時流量就會指到對應的 Pod 上面，此時流量不經(jīng)過 Activator；
• 其中 Autoscaler 模塊根據(jù)請求的 Metrics 信息實時動態(tài)的擴縮容。

Knative 的 Pod 是由兩個 Container 組成的：Queue-Proxy 和業(yè)務容器 user-container。架構如下：

咱們以 http1 為例進行說明：業(yè)務流量首先進入 Istio Gateway，然后會轉發(fā)到 Queue-Proxy 的 8012 端口，Queue-Proxy 8012 再把請求轉發(fā)到 user-container 的監(jiān)聽端口，至此一個業(yè)務請求的服務就算完成了。

粗略的介紹原理基本就是上面這樣，現(xiàn)在咱們對幾個細節(jié)進行深入的剖析看看其內(nèi)部機制：

• 為什么要引入 Queue-Proxy？
• Pod 縮容到零的時候流量會轉發(fā)到 Activator 上面，那么 Activator 是怎么處理這些請求的？
• Knative 中的業(yè)務 Pod 有 Queue-Proxy 和 user-container，那么 Pod 的 readinessProber 和 LivenessProber 分別是怎么做的？Pod 的 readinessProber、 LivenessProber 和業(yè)務的健康狀態(tài)是什么樣的關系？
• Istio Gateway 向 Pod 轉發(fā)流量的時候是怎么選擇 Pod 進行轉發(fā)的？

為什么要引入 Queue-Proxy

Serverless 的一個核心訴求就是把業(yè)務的復雜度下沉到基礎平臺，讓業(yè)務代碼快速迭代并且按需使用資源。不過現(xiàn)在更多的還是聚焦在按需使用資源層面。

如果想要按需使用資源我們就需要收集相關的 Metrics，并根據(jù)這些 Metrics 信息來指導資源的伸縮。Knative 首先實現(xiàn)的就是 KPA 策略，這個策略是根據(jù)請求數(shù)來判斷是否需要擴容的。所以 Knative 需要有一個機制收集業(yè)務請求數(shù)量。除了業(yè)務請求數(shù)還有如下信息也是需要統(tǒng)一處理：

• 訪問日志的管理；
• Tracing；
• Pod 健康檢查機制；
• 需要實現(xiàn) Pod 和 Activator 的交互，當 Pod 縮容到零的時候如何接收 Activator 轉發(fā)過來的流量；
• 其他諸如判斷 Ingress 是否 Ready 的邏輯也是基于 Queue-Proxy 實現(xiàn)的。

為了保持和業(yè)務的低耦合關系，還需要實現(xiàn)上述這些功能，所以就引入了 Queue-Proxy 負責這些事情。這樣可以在業(yè)務無感知的情況下把 Serverless 的功能實現(xiàn)。

從零到一的過程

當 Pod 縮容到零的時候流量會指到 Activator 上面，Activator 接收到流量以后會主動“通知”Autoscaler 做一個擴容的操作。擴容完成以后 Activator 會探測 Pod 的健康狀態(tài)，需要等待第一個 Pod ready 之后才能把流量轉發(fā)過來。所以這里就出現(xiàn)了第一個健康檢查的邏輯：Activator 檢查第一個 Pod 是否 ready。

這個健康檢查是調(diào)用的 Pod 8012 端口完成的，Activator 會發(fā)起 HTTP 的健康檢查，并且設置 ?K-Network-Probe=queue Header，所以 Queue Container 中會根據(jù) K-Network-Probe=queue 來判斷這是來自 Activator 的檢查，然后執(zhí)行相應的邏輯。

參考閱讀

• Activator to perform health checks before forwarding real requests
• Activator: Retry on Get Revision error
• Retry on Get Revision error?
• Always pass Healthy dests to the throttler
• Consolidate queue-proxy probe handlers
• Queue proxy logging, metrics and end to end traces
• End to end traces from queue proxy

VirtualService 的健康檢查

Knative Revision 部署完成后會自動創(chuàng)建一個 Ingress（以前叫做 ClusterIngress）, 這個 Ingress 最終會被 Ingress Controller 解析成 Istio 的 VirtualService 配置，然后 Istio ?Gateway 才能把相應的流量轉發(fā)給相關的 Revision。

所以每添加一個新的 Revision 都需要同步創(chuàng)建 Ingress 和 Istio 的 VirtualService ，而 VirtualService 是沒有狀態(tài)表示 Istio 的管理的 Envoy 是否配置生效能力。所以 Ingress Controller 需要發(fā)起一個 http 請求來監(jiān)測 VirtualService 是否 ready。這個 http 的檢查最終也會打到 Pod 的 8012 端口上。標識 Header 是 K-Network-Probe=probe 。Queue-Proxy 需要基于此來判斷，然后執(zhí)行相應的邏輯。

相關代碼如下所示：

圖片來源

圖片來源

參考閱讀

Gateway 通過這個健康檢查來判斷 Pod 是否可以提供服務。

• New probe handling in Queue-Proxy & Activator
• Extend VirtualService/Gateway probing to HTTPS
• Probe Envoy pods to determine when a ClusterIngress is actually deployed
• ClusterIngress Status
• Consolidate queue-proxy probe handlers

Kubelet 的健康檢查

Knative 最終生成的 Pod 是需要落實到 Kubernetes 集群的，Kubernetes 中 Pod 有兩個健康檢查的機制：ReadinessProber 和 LivenessProber。

• 其中 LivenessProber 是判斷 Pod 是否活著，如果檢查失敗 Kubelet 就會嘗試重啟 Container；
• ReadinessProber 是來判斷業(yè)務是否 Ready，只有業(yè)務 Ready 的情況下才會把 Pod 掛載到 Kubernetes Service 的 EndPoint 中，這樣可以保證 Pod 故障時對業(yè)務無損。

那么問題來了，Knative 的 Pod 中默認會有兩個 Container：Queue-Proxy 和 user-container 。

前面兩個健康檢查機制你應該也發(fā)現(xiàn)了，流量的“前半路徑”需要通過 Queue-Proxy 來判斷是否可以轉發(fā)流量到當前 Pod，而在 Kubernetes 的機制中，Pod 是否加入 Kubernetes Service EndPoint 完全是由 ReadinessProber 的結果決定的。而這兩個機制是獨立的，所以我們需要有一種方案來把這兩個機制協(xié)調(diào)一致。這也是 Knative 作為一個 Serverless 編排引擎時需要對流量做更精細的控制要解決的問題。所以 Knative 最終是把 user-container 的 ReadinessProber 收斂到 Queue-Proxy 中，通過 Queue-Proxy 的結果來決定 Pod 的狀態(tài)。

另外這個 Issue 中也提到在啟動 istio 的情況下，kubelet 發(fā)起的 tcp 檢查可能會被 Envoy 攔截，所以給 user-container 配置 TCP 探測器判斷 user-container 是否 ready 也是不準的。這也是需要把 Readiness 收斂到 Queue-Proxy 的一個動機。

Knative 收斂 user-container 健康檢查能力的方法是：

• 置空 user-container 的 ReadinessProber；
• 把 user-container 的 ReadinessProber 配置的 json String 配置到 Queue-Proxy 的 env 中；
• Queue-Proxy 的 Readinessprober 命令里面解析 user-container 的 ReadinessProber 的 json String 然后實現(xiàn)健康檢查邏輯，且這個檢查的機制和前面提到的 Activator 的健康檢查機制合并到了一起。這樣做也保證了 Activator 向 Pod 轉發(fā)流量時 user-container 一定是 ?Ready 狀態(tài)。

參考閱讀

• Consolidate queue-proxy probe handlers
• Use user-defined readinessProbe in queue-proxy
• Apply default livenessProbe and readinessProbe to the user container
• Good gRPC deployment pods frequently fail at least one health check
• Fix invalid helloworld example<br />
  這里面有比較詳細的方案討論，最終社區(qū)選擇的方案也是在這里介紹的。
• Allow probes to run on a more granular timer.
• Merge 8022/health to 8012/8013
• TCP probe the user-container from the queue-proxy before marking the pod ready.
• Use user-defined readiness probes through queue-proxy
• queue-proxy /heatlth to perform TCP connect to user container

使用方法

如下所示可以在 Knative Service 中定義 Readiness。

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: readiness-prober
spec:
  template:
    metadata:
      labels:
        app: helloworld-go
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4db7
          readinessProbe:
            httpGet:
              path: /
            initialDelaySeconds: 3

需要說明兩點：

1. 和原生的 Kubernetes Pod Readiness 配置相比，Knative 中 timeoutSeconds、failureThreshold、periodSeconds 和 successThreshold 如果要配置就要一起配置，并且不能為零，否則 Knative webhook 校驗無法通過。并且如果設置了 periodSeconds，那么一旦出現(xiàn)一次 Success，就再也不會去探測 user-container（不建議設置 periodSeconds，應該讓系統(tǒng)自動處理）。

2. 如果 periodSeconds 沒有配置那么就會使用默認的探測策略，默認配置如下：

timeoutSeconds: 60
            failureThreshold: 3
            periodSeconds: 10
            successThreshold: 1

從這個使用方式上來看，其實 Knative 是在逐漸收斂 user-container 配置，因為在 Serverless 模式中需要系統(tǒng)自動化處理很多邏輯，這些“系統(tǒng)行為”就不需要麻煩用戶了。

小結

前面提到的三種健康檢查機制的對比關系：

“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技術領域、聚焦云原生流行技術趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)×××

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

當前名稱：KnativeServing健康檢查機制分析-創(chuàng)新互聯(lián)
路徑分享：http://jinyejixie.com/article12/dphsgc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供定制開發(fā)、移動網(wǎng)站建設、響應式網(wǎng)站、電子商務、服務器托管、域名注冊

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)