從頭開發(fā)一個(gè) Serverless 引擎并不是一件容易的事情，今天咱們就從 Knative 的健康檢查說起。通過健康檢查這一個(gè)點(diǎn)來看看 Serverless 模式和傳統(tǒng)的模式都有哪些不同以及 Knative 針對(duì) Serverless 場(chǎng)景都做了什么思考。
Knative Serving 模塊的核心原理如下圖所示。下圖中的 Route 可以理解成是 Istio Gateway 的角色。

• 當(dāng)縮容到零時(shí)進(jìn)來的流量就會(huì)指到 Activator 上面
• 當(dāng) Pod 數(shù)不為零時(shí)流量就會(huì)指到對(duì)應(yīng)的 Pod 上面，此時(shí)流量不經(jīng)過 Activator
• 其中 Autoscaler 模塊根據(jù)請(qǐng)求的 Metrics 信息實(shí)時(shí)動(dòng)態(tài)的擴(kuò)縮容

Knative 的 Pod 是由兩個(gè) Container 組成的: Queue-Proxy 和業(yè)務(wù) Container。架構(gòu)如下：

咱們以 http1 為例進(jìn)行說明。業(yè)務(wù)流量首先進(jìn)入 Istio Gateway，然后會(huì)轉(zhuǎn)發(fā)到 Queue-Proxy 的 8012 端口，Queue-Proxy 8012 再把請(qǐng)求轉(zhuǎn)發(fā)到業(yè)務(wù)容器的監(jiān)聽端口，至此一個(gè)業(yè)務(wù)請(qǐng)求的服務(wù)就算完成了。

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

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

為什么要引入 Queue-Proxy

Serverless 的一個(gè)核心訴求就是把業(yè)務(wù)的復(fù)雜度下沉到基礎(chǔ)平臺(tái)，讓業(yè)務(wù)代碼快速的迭代并且按需使用資源。不過現(xiàn)在更多的還是聚焦在按需使用資源層面。
如果想要按需使用資源我們就需要收集一些資源相關(guān)的 Metrics，根據(jù)這些 Metrics 信息來指導(dǎo)資源的管理。Knative 首先實(shí)現(xiàn)的就是 KPA 策略，這個(gè)是根據(jù)請(qǐng)求數(shù)來判斷是否需要擴(kuò)容的。所以 Knative 需要有一個(gè)機(jī)制收集業(yè)務(wù)請(qǐng)求數(shù)量。除了業(yè)務(wù)請(qǐng)求數(shù)還有如下信息也是需要統(tǒng)一處理了：

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

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

從零到一的過程

當(dāng) Pod 縮容到零的時(shí)候流量會(huì)指到 Activator 上面，Activator 接收到流量以后會(huì)主動(dòng)“通知”Autoscaler 做一個(gè)擴(kuò)容的操作。擴(kuò)容完成以后 Activator 會(huì)探測(cè) Pod 的健康狀態(tài)，需要等待第一個(gè) Pod ready 之后才能把流量轉(zhuǎn)發(fā)過來。所以這里就出現(xiàn)了第一個(gè)健康檢查的邏輯：Activator 檢查 Pod 是否 ready
這個(gè)健康檢查是調(diào)用的 Pod 8012 端口完成的，Activator 會(huì)發(fā)起 HTTP 的健康檢查，并且設(shè)置 K-Network-Probe=queue Header，所以 Queue Container 中會(huì)根據(jù) K-Network-Probe=queue 來判斷這是來自 Activator 的檢查，然后執(zhí)行相應(yīng)的邏輯。

VirtualService 的健康檢查

Knative Revision 部署完成以后就會(huì)自動(dòng)創(chuàng)建一個(gè) Ingress(以前叫做 ClusterIngress), 這個(gè) Ingress 最終會(huì)被 Gateway 解析，然后 Gateway 才能把相應(yīng)的流量轉(zhuǎn)發(fā)給相關(guān)的 Revision。
所以每次添加一個(gè)新的 Revision 都需要同步創(chuàng)建 Ingress 和 Istio 的 VirtualService ，而 VirtualService 是沒有狀態(tài)表示 Istio 的管理的 Envoy 是否配置生效的能力的。所以 Ingress Controller 需要發(fā)起一個(gè) http 請(qǐng)求來判斷 VirtualService 是否 ready。這個(gè) http 的檢查最終也會(huì)打到 Pod 的 8012 端口上。標(biāo)識(shí) Header 是 K-Network-Probe=probe 。Queue-Proxy 需要基于此來判斷，然后執(zhí)行相應(yīng)的邏輯。

相關(guān)代碼如下所示：

Kubelet 的健康檢查

Knative 最終生成的 Pod 是需要落實(shí)到 Kubernetes 集群的，Kubernetes 中 Pod 有兩個(gè)健康檢查的機(jī)制 ReadinessProber 和 LivenessProber。其中 LivenessProber 是判斷 Pod 是否活著，如果檢查失敗 Kubelet 就會(huì)嘗試重啟 Container，ReadinessProber 是來判斷業(yè)務(wù)是否 Ready，只有業(yè)務(wù) Ready 的情況下才會(huì)把 Pod 掛載到 Kubernetes Service 的 EndPoint 中，這樣可以保證 Pod 故障時(shí)對(duì)業(yè)務(wù)無損。

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

另外?https://github.com/knative/serving/issues/2912?這個(gè) Issue 中也提到在啟動(dòng) istio 的情況下，kubelet 發(fā)起的 tcp 檢查可能會(huì)被 Envoy 鏈接，所以 TCP 請(qǐng)求無法判斷用戶的 Container 是否 ready，這也是需要把 Readiness 收斂到 Queue-Proxy 的一個(gè)動(dòng)機(jī)。

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

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

使用方法
如下所示可以在 Knative Service 中定義 Readiness

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

但是需要說明兩點(diǎn)：

和原生的 Kubernetes Pod Readiness 配置相比，Knative 中 timeoutSeconds、failureThreshold、periodSeconds 和 successThreshold 如果要配置就要一起配置，并且不能為零。否則 Knative webhook 校驗(yàn)無法通過。并且如果設(shè)置了 periodSeconds 那么一旦出現(xiàn)一次 Success，就再也不會(huì)去探測(cè) user-container(v0.9.0 版本是這個(gè)行為，這應(yīng)該是一個(gè) Bug)

如果 periodSeconds 沒有配置那么就會(huì)使用默認(rèn)的探測(cè)策略，默認(rèn)配置如下，并且這個(gè)配置是不能修改的。

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

從這個(gè)使用方式上來看其實(shí) Knative 是在逐漸收斂用戶配置的靈活性，因?yàn)樵?Serverless 模式中需要系統(tǒng)自動(dòng)化處理很多邏輯。

小結(jié)

前面提到的三種健康檢查機(jī)制的對(duì)比關(guān)系：

Probe Request SourcePathExtra featurescomment

Activator probe requests	:8012	With header K-Network-Probe=queue. Expected?queue?as response body.	Probe requests from Activator before it proxies external requests
VirtualService/Gateway probe requests	:8012	With header K-Network-Probe=probe and non-empty K-Network-Hash header	This is used to detect which version of a VirtualService an Envoy Pod is currently serving. They are proxied from VirtualService to activator/queue-proxy.
Kubelet probe requests	:8012	With non-empty K-Kubelet-Probe header or with header user-agent=kube-probe/*	I don't think currently kubectl sends probe requests to this path. We can delete it. Correct me if I was wrong.

阿里云雙11億元補(bǔ)貼提前領(lǐng)，進(jìn)入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Knative 健康检查机制分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。