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 會定義一組自訂資源定義 (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 服務叢集架構 (按一下即可放大)

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

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 會將流量傳送至使用者容器。