Knative serving 架構總覽

本頁面提供 Knative Serving 的架構總覽,並說明在 Google Kubernetes Engine 叢集中啟用 Knative Serving 時發生的變化。

這項資訊對下列類型的使用者很有幫助:

  • Knative serving 的新手使用者。
  • 有執行 GKE 叢集經驗的運算子。
  • 應用程式開發人員需要進一步瞭解 Knative serving 如何與 Kubernetes 叢集整合,以便設計更完善的應用程式或設定 Knative serving 應用程式。

預設安裝的元件

在叢集中安裝 Knative Serving,即可連線及管理無狀態工作負載。Knative 元件會在 knative-serving 命名空間中建立。

Knative serving 會使用 Cloud Service Mesh 路由流量。根據預設,Cloud Service Mesh 會在 istio-system 命名空間中安裝元件。

以下列出 Knative Serving 和 Cloud Service Mesh 安裝的元件:

  • Knative Serving 在 knative-serving 命名空間中安裝的元件:

    • Activator:當 Pod 縮減為零,或傳送至修訂版本的請求過多時,啟動器會暫時將請求加入佇列,並將指標傳送至自動調整程式,以啟動更多 Pod。自動調度器會根據回報的指標和可用 Pod 數量調度修訂版本,而啟動器會將佇列中的要求轉送至修訂版本。啟動器是資料平面元件;資料平面元件會管理所有函式和程序,轉送使用者流量。
    • 自動配置器:彙整及處理來自啟動器和佇列 Proxy Sidecar 容器的指標,這是資料層中的元件,可強制執行要求並行限制。自動調度器接著會計算修訂版本的觀察並行數,並根據所需的 Pod 數量調整部署大小。如果修訂版本中有可用的 Pod,自動調度器就是控制層元件;否則,如果 Pod 縮減為零,自動調度器就是資料層元件。
    • 控制器:建立及更新 Autoscaler 的子項資源和服務物件。控制器是控制層元件;控制層元件會管理所有功能和程序,建立使用者流量的要求路徑。
    • 指標收集器:從 Knative 服務元件收集指標,然後轉送至 Cloud Monitoring。
    • Webhook:設定預設值、拒絕不一致和無效的物件,並驗證變更對 Knative serving 資源發出的 Kubernetes API 呼叫。Webhook 是控制層元件。
  • istio-system 命名空間中執行的 Cloud Service Mesh 安裝元件:

    • 叢集本機閘道:資料平面中的負載平衡器,負責處理從一個 Knative 服務傳送至另一個服務的內部流量。叢集本機閘道只能從 GKE 叢集內存取,且不會註冊外部網域,避免私人資訊或內部程序意外曝光。
    • Istio Ingress Gateway:資料平面中的負載平衡器,負責接收及處理來自叢集外部的連入流量,包括來自外部或內部網路的流量。
    • Istiod:設定叢集本機閘道和 Istio Ingress 閘道,在正確的端點處理 HTTP 要求。Istiod 是控制層元件,詳情請參閱「Istiod」。

只要 GKE 控制層叢集有任何更新,Knative 服務元件就會自動更新。詳情請參閱「可用的 GKE 版本」。

叢集資源用量

Knative 服務的初始安裝作業大約需要 1.5 個虛擬 CPU 和 1 GB 的叢集記憶體。叢集中的節點數量不會影響 Knative 服務安裝的空間和記憶體需求。

啟動器最多可耗用 1000 mCPU 和 600 MiB RAM 的要求。 如果現有的啟動器無法支援大量要求,系統會啟動額外的啟動器,這需要預留 300 毫 CPU 和 60 MiB RAM。

Knative 服務服務建立的每個 Pod 都會建立佇列 Proxy Sidecar,強制執行要求並行限制。佇列 Proxy 會保留 25 毫 CPU,且沒有記憶體保留項目。佇列 Proxy 的耗用量取決於排入佇列的要求數量和要求大小,CPU 和記憶體資源耗用量沒有限制。

建立服務

顯示 Knative serving 服務架構的圖表
Knative Serving 服務架構 (按一下即可放大)

Knative Serving 會定義一組自訂資源定義 (CRD),藉此擴充 Kubernetes:Service、Revision、Configuration 和 Route。這些 CRD 會定義及控管應用程式在叢集上的行為:

  • Knative serving 服務是 Knative serving 定義的頂層自訂資源。這項單一應用程式可管理工作負載的整個生命週期。服務會確保應用程式在每次更新服務時,都有路徑設定和新的修訂版本
  • 修訂版本是程式碼和設定在特定時間點的不可變更快照。
  • 「設定」會保留最新修訂版本的目前設定,並記錄所有先前修訂版本的歷史記錄。修改設定會建立新的修訂版本。
  • Route 會定義 HTTP 端點,並將端點與一或多個要求轉送的修訂版本建立關聯。

使用者建立 Knative Serving Service 時,會發生下列情況:

  1. Knative serving 服務物件定義了下列項目:

    1. 修訂版本服務方式的設定。
    2. 這個服務版本的不可變更修訂版本。
    3. 管理指定流量分配給修訂版本的路徑。
  2. 路由物件會建立 VirtualService。VirtualService 物件會設定 Ingress Gateway 和 Cluster Local Gateway,將閘道流量導向正確的修訂版本。

  3. 修訂版本物件會建立下列控制層元件:Kubernetes Service 物件和 Deployment 物件。

  4. 網路設定會連線 Activator、Autoscaler 和應用程式的負載平衡器。

處理要求

下圖概略說明使用者流量可能的要求路徑,流量會通過範例 Google Kubernetes Engine 叢集上的 Knative 服務資料平面元件:

顯示 Knative Serving 叢集架構的圖表
Knative 服務叢集架構 (按一下即可放大)

下圖以上圖為基礎,深入瞭解使用者流量的要求路徑,詳情如下:

顯示 Knative Serving 要求路徑的圖表
Knative 服務要求路徑 (按一下即可放大)

Knative serving 要求路徑:

  1. 流量來源:

    • 叢集外部流量的 Ingress 閘道
    • 叢集本機閘道,用於叢集內的流量
  2. VirtualService 元件會指定流量轉送規則,並設定閘道,確保使用者流量轉送至正確的修訂版本。

  3. Kubernetes Service (控制層元件) 會根據可處理流量的 Pod 可用性,判斷要求路徑中的下一個步驟:

    • 如果修訂版本中沒有任何 Pod:

      1. 啟動器會暫時將收到的要求加入佇列,並將指標推送至自動調度器,以調度更多 Pod。
      2. 自動配置器會將 Deployment 中的 Pod 擴充至所需狀態。
      3. 部署作業會建立更多 Pod,以接收額外要求。
      4. 啟動器會重試對佇列 Proxy Sidecar 的要求。
    • 如果服務已擴充 (Pod 可用),Kubernetes 服務會將要求傳送至佇列 Proxy Sidecar。

  4. 佇列 Proxy Sidecar 會強制執行要求佇列參數、單一或多執行緒要求,容器一次可處理的要求。

  5. 如果佇列 Proxy Sidecar 的要求數超出處理上限,自動調度資源程序會建立更多 Pod,處理額外要求。

  6. 佇列 Proxy Sidecar 會將流量傳送至使用者容器。