作者|??阿里云智能事業(yè)群技術(shù)專家牛秋霖(冬島)
導(dǎo)讀:從頭開發(fā)一個(gè) Serverss 引擎并不是一件容易的事情,今天咱們就從 Knative 的健康檢查說起。通過健康檢查這一個(gè)點(diǎn)來看看 Serverless 模式和傳統(tǒng)的模式都有哪些不同,以及 Knative 針對(duì) Serverless 場景都做了什么思考。
Knative Serving 模塊的核心原理如下圖所示,圖中的 Route 可以理解成是 Istio Gateway 的角色。
Knative 的 Pod 是由兩個(gè) Container 組成的:Queue-Proxy 和業(yè)務(wù)容器 user-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ā)到 user-container 的監(jiān)聽端口,至此一個(gè)業(yè)務(wù)請(qǐng)求的服務(wù)就算完成了。
粗略的介紹原理基本就是上面這樣,現(xiàn)在咱們對(duì)幾個(gè)細(xì)節(jié)進(jìn)行深入的剖析看看其內(nèi)部機(jī)制:
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)一處理:
為了保持和業(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ì)探測 Pod 的健康狀態(tài),需要等待第一個(gè) Pod ready 之后才能把流量轉(zhuǎn)發(fā)過來。所以這里就出現(xiàn)了第一個(gè)健康檢查的邏輯:Activator 檢查第一個(gè) 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)的邏輯。
Knative Revision 部署完成后會(huì)自動(dòng)創(chuàng)建一個(gè) Ingress(以前叫做 ClusterIngress), 這個(gè) Ingress 最終會(huì)被 Ingress Controller 解析成 Istio 的 VirtualService 配置,然后 Istio ?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)求來監(jiān)測 VirtualService 是否 ready。這個(gè) http 的檢查最終也會(huì)打到 Pod 的 8012 端口上。標(biāo)識(shí) Header 是 K-Network-Probe=probe 。Queue-Proxy 需要基于此來判斷,然后執(zhí)行相應(yīng)的邏輯。
相關(guān)代碼如下所示:
圖片來源
圖片來源
Gateway 通過這個(gè)健康檢查來判斷 Pod 是否可以提供服務(wù)。
Knative 最終生成的 Pod 是需要落實(shí)到 Kubernetes 集群的,Kubernetes 中 Pod 有兩個(gè)健康檢查的機(jī)制:ReadinessProber 和 LivenessProber。
那么問題來了,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 是否加入 Kubernetes Service EndPoint 完全是由 ReadinessProber 的結(jié)果決定的。而這兩個(gè)機(jī)制是獨(dú)立的,所以我們需要有一種方案來把這兩個(gè)機(jī)制協(xié)調(diào)一致。這也是 Knative 作為一個(gè) Serverless 編排引擎時(shí)需要對(duì)流量做更精細(xì)的控制要解決的問題。所以 Knative 最終是把 user-container 的 ReadinessProber 收斂到 Queue-Proxy 中,通過 Queue-Proxy 的結(jié)果來決定 Pod 的狀態(tài)。
另外這個(gè) Issue 中也提到在啟動(dòng) istio 的情況下,kubelet 發(fā)起的 tcp 檢查可能會(huì)被 Envoy 攔截,所以給 user-container 配置 TCP 探測器判斷 user-container 是否 ready 也是不準(zhǔn)的。這也是需要把 Readiness 收斂到 Queue-Proxy 的一個(gè)動(dòng)機(jī)。
Knative 收斂 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
需要說明兩點(diǎn):
和原生的 Kubernetes Pod Readiness 配置相比,Knative 中 timeoutSeconds、failureThreshold、periodSeconds 和 successThreshold 如果要配置就要一起配置,并且不能為零,否則 Knative webhook 校驗(yàn)無法通過。并且如果設(shè)置了 periodSeconds,那么一旦出現(xiàn)一次 Success,就再也不會(huì)去探測 user-container(不建議設(shè)置 periodSeconds,應(yīng)該讓系統(tǒng)自動(dòng)處理)。
timeoutSeconds: 60
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
從這個(gè)使用方式上來看,其實(shí) Knative 是在逐漸收斂 user-container 配置,因?yàn)樵?Serverless 模式中需要系統(tǒng)自動(dòng)化處理很多邏輯,這些“系統(tǒng)行為”就不需要麻煩用戶了。
前面提到的三種健康檢查機(jī)制的對(duì)比關(guān)系:
“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐,做最懂云原生開發(fā)×××
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
當(dāng)前名稱:KnativeServing健康檢查機(jī)制分析-創(chuàng)新互聯(lián)
路徑分享:http://muchs.cn/article12/dphsgc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供定制開發(fā)、移動(dòng)網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站、電子商務(wù)、服務(wù)器托管、域名注冊
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容