HTTP 請求流程

雖然概述描述了邏輯組件，而架構描述了 Knative Serving 的整體架構，但本頁說明了傳送到在 Knative Serving 上執行的應用程式的 HTTP 請求行為和流程。

下圖顯示了 Knative Serving 的不同請求流程和控制平面迴圈。請注意，某些組件（例如 autoscaler 和 apiserver）不會在每個請求上更新，而是定期測量系統（這稱為控制平面）。

HTTP 路由器、啟動器和 autoscaler 都是共用的叢集層級資源；這將新 Knative 服務的開銷減少到僅在服務未使用時的元數據，並允許更有效率地管理和升級這些共用組件。

路由決策在 HTTP 路由器（可插入的入口層）上以每個請求層級執行一次，並記錄在請求的內部標頭中。一旦請求被分配給修訂版本，後續的路由將取決於測量的流量；在低流量或零流量時，傳入的請求會路由到啟動器，而在高流量級別（備用容量大於 target-burst-capacity）時，流量會直接路由到應用程式 Pod。

從零開始擴展

當特定修訂版本的流量較低或零時，HTTP 路由器會將流量傳送到啟動器，其中包含一個標頭，指示選定的修訂版本。啟動器充當傳入請求的緩衝區或佇列 -- 如果請求路由到目前沒有可用容量的修訂版本，啟動器會延遲請求，並向 autoscaler 發出訊號，表示需要額外的容量。

當 autoscaler 偵測到修訂版本的可用容量低於請求的容量時，它會增加從 Kubernetes 請求的 Pod 數量。

當這些新的 Pod 準備就緒或現有 Pod 有容量時，啟動器會將延遲的請求轉送到準備就緒的 Pod。如果需要啟動新的 Pod 來處理請求，則稱為冷啟動。

高規模

當修訂版本的流量很高時（備用容量大於 target-burst-capacity），入口路由器會直接使用修訂版本的 Pod 位址進行程式設計，並從流量流程中移除啟動器。當不需要啟動器的額外緩衝時，這會減少延遲並提高效率。在所有情況下，queue-proxy 都會保留在請求路徑中。

如果流量降到突發容量閾值以下（計算為：current_demand + target-burst-capacity > (pods * concurrency-target)），則入口路由器將重新程式設計為將流量傳送到啟動器 Pod。

入口和啟動器之間的路由流量是透過將啟動器端點的子集寫入修訂版本的服務的端點來完成的。與修訂版本對應的 Kubernetes 服務是無選擇器，並且可能包含修訂版本的 Pod 端點或啟動器端點。使用無選擇器服務的原因如下

• 某些入口實作不允許跨命名空間服務參考。啟動器在 knative-serving 命名空間中執行。

• 某些入口實作無法順利處理路由端點的後端 Kubernetes 服務的變更。

• 透過在每個修訂版本上使用子設定，傳入的請求會被引導到少數可以更有效率地做出準備就緒/未準備就緒容量決策的啟動器。每個修訂版本的有效啟動器數量少並不是一個擴展問題，因為當修訂版本擴展以接收更多流量時，啟動器將從請求路徑中移除。

Queue-Proxy

queue-proxy 組件實作了許多功能來提高 Knative 的可靠性和擴展性

• 測量 autoscaler 的並行請求，尤其是在從請求路徑中移除啟動器時。

• 如果請求，則實作請求並行性的 containerConcurrency 硬性限制。

• 處理 Pod 終止時的正常關閉（拒絕新的請求、失敗的準備檢查、繼續服務現有的請求）。

• 從使用者容器外部報告 HTTP 指標和追蹤，以便可以測量基礎結構延遲貢獻。

• 在啟動期間（準備就緒之前），更積極地探測使用者容器，以啟用比 Kubelet 探測（每秒最多探測一次）更早的服務。

• 為了支援此功能，Knative Serving 會將使用者容器的 readinessProbe 重寫為 queue-proxy 的引數；queue-proxy 的準備檢查包含 queue-proxy 自己的準備狀態和使用者容器的準備狀態。