作者| 阿里雲智慧型事業群技術專家牛秋霖（冬島）
knative serving 模組的核心原理如下圖所示，圖中的 route 可以理解成是 istio gateway 的角色。
knative 的 pod 是由兩個 container 組成的：queue-proxy 和業務容器 user-container。架構如下：
咱們以 http1 為例進行說明：業務流量首先進入 istio gateway，然後會**到 queue-proxy 的 8012 埠，queue-proxy 8012 再把請求**到 user-container 的監聽埠，至此乙個業務請求的服務就算完成了。
粗略的介紹原理基本就是上面這樣，現在咱們對幾個細節進行深入的剖析看看其內部機制：
serverless 的乙個核心訴求就是把業務的複雜度下沉到基礎平台，讓業務**快速迭代並且按需使用資源。不過現在更多的還是聚焦在按需使用資源層面。
如果想要按需使用資源我們就需要收集相關的 metrics，並根據這些 metrics 資訊來指導資源的伸縮。knative 首先實現的就是 kpa 策略，這個策略是根據請求數來判斷是否需要擴容的。所以 knative 需要有乙個機制收集業務請求數量。除了業務請求數還有如下資訊也是需要統一處理：
為了保持和業務的低耦合關係，還需要實現上述這些功能，所以就引入了 queue-proxy 負責這些事情。這樣可以在業務無感知的情況下把 serverless 的功能實現。
當 pod 縮容到零的時候流量會指到 activator 上面，activator 接收到流量以後會主動「通知」autoscaler 做乙個擴容的操作。擴容完成以後 activator 會探測 pod 的健康狀態，需要等待第乙個 pod ready 之後才能把流量**過來。所以這裡就出現了第乙個健康檢查的邏輯：activator 檢查第乙個 pod 是否 ready。
**這個健康檢查是呼叫的 pod 8012 埠完成的，activator 會發起 http 的健康檢查，並且設定 k-network-probe=queue header，所以 queue container 中會根據 k-network-probe=queue 來判斷這是來自 activator 的檢查，然後執行相應的邏輯。
knative revision 部署完成後會自動建立乙個 ingress（以前叫做 clusteringress）, 這個 ingress 最終會被 ingress controller 解析成 istio 的 virtualservice 配置，然後 istio gateway 才能把相應的流量**給相關的 revision。
所以每新增乙個新的 revision 都需要同步建立 ingress 和 istio 的 virtualservice ，而 virtualservice 是沒有狀態表示 istio 的管理的 envoy 是否配置生性能力。所以 ingress controller 需要發起乙個 http 請求來監測 virtualservice 是否 ready。這個 http 的檢查最終也會打到 pod 的 8012 埠上。標識 header 是 k-network-probe=probe 。queue-proxy 需要基於此來判斷，然後執行相應的邏輯。
**gateway 通過這個健康檢查來判斷 pod 是否可以提供服務。
knative 最終生成的 pod 是需要落實到 kubernetes 集群的，kubernetes 中 pod 有兩個健康檢查的機制：readinessprober 和 livenessprober。
那麼問題來了，knative 的 pod 中缺省會有兩個 container：queue-proxy 和 user-container 。
前面兩個健康檢查機制你應該也發現了，流量的「前半路徑」需要通過 queue-proxy 來判斷是否可以**流量到當前 pod，而在 kubernetes 的機制中，pod 是否加入 kubernetes service endpoint 完全是由 readinessprober 的結果決定的。而這兩個機制是獨立的，所以我們需要有一種方案來把這兩個機制協調一致。這也是 knative 作為乙個 serverless 編排引擎時需要對流量做更精細的控制要解決的問題。所以 knative 最終是把 user-container 的 readinessprober 收斂到 queue-proxy 中，通過 queue-proxy 的結果來決定 pod 的狀態。
另外這個 issue 中也提到在啟動 istio 的情況下，kubelet 發起的 tcp 檢查可能會被 envoy 攔截，所以給 user-container 配置 tcp 探測器判斷 user-container 是否 ready 也是不准的。這也是需要把 readiness 收斂到 queue-proxy 的乙個動機。
knative 收斂 user-container 健康檢查能力的方法是：
如下所示可以在 knative service 中定義 readiness。
需要說明兩點：
和原生的 kubernetes pod readiness 配置相比，knative 中 timeoutseconds、failurethreshold、periodseconds 和 successthreshold 如果要配置就要一起配置，並且不能為零，否則 knative webhook 校驗無法通過。並且如果設定了 periodseconds，那麼一旦出現一次 success，就再也不會去探測 user-container（不建議設定 periodseconds，應該讓系統自動處理）。
如果 periodseconds 沒有配置那麼就會使用預設的探測策略，預設配置如下：
timeoutseconds: 60
failurethreshold: 3
periodseconds: 10
successthreshold: 1
前面提到的三種健康檢查機制的對比關係：
MAC終端快捷健
快捷鍵 功能ctrl a 移動到開頭 ctrl e 移動到結尾 ctrl b 向左移動乙個字元 助記back ctrl f 向右移動乙個字元 助記forward option left 向左移動乙個單詞 option right 向右移動乙個單詞 ctrl h 向左刪除乙個字元 ctrl w 向左刪...
Ubuntu TAB健作用修復
首先利用vi編輯器開啟 etc bash。bashrc檔案 需root許可權 sudo vi etc bash.bashrc 找到下列 按下i進行修改，將第二行開始的 去 enable bash completion in interactive shells if shopt oq posix t...
docker容器HEALTHCHECK 健康檢查
docker容器的健康檢測是在編寫dockerfile時，將檢測機制寫入到dockerfile中，基於此docerfile生成的映象，在執行容器時會有健康檢測的功能。dockerfile中的格式 healthcheck 指令是告訴 docker引擎應該如何進行判斷容器的狀態是否正常，這是 docke...