Knative應用程式模型Knative Service介紹 - Container Service for Kubernetes

Knative應用程式模型，即Knative Service，可以簡化 Kubernetes 上的服務部署和管理。您可以通過操作Knative Service進行工作負載的生命週期管理。

模型介紹

Knative Service是使用者直接操作的資來源物件，一個Knative Service的包括如下：

Configuration：用於定義工作負載配置，包括容器鏡像、環境變數、資源限制等。每次對 Configuration 的修改（例如更新鏡像版本、調整環境變數）都會觸發新 Revision 的產生。
Revision：每次Configuration的更新都會建立一個快照，即一個 Revision （修訂版本），以保留對應的配置狀態。Knative基於Revision實現應用的多版本管理。
Route：用於配置路由規則，向多個Revision分發流量。支援配置轉寄到不同Revision的流量百分比，以實現灰階發布
Tag：為特定Revision打上唯一Tag後， Knative 會自動為該Revision產生獨立的訪問地址，可用於金絲雀驗證。

簡單來說，Knative Service 是 Kubernetes 資源的進階抽象，整合了多個核心資源（Deployment、Serivce、Ingress），並支援Auto Scaling、多版本管理等能力。

YAML樣本

一個簡單的Knative Service樣本YAML如下。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    spec:
      containers:
      - image: registry-vpc.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

功能特性

通過操作Knative Service的資來源物件，它能以更簡便的方式實現如下功能。

基於請求的自動彈性

基於CPU或者Memory的彈性策略有時無法精準反映業務的實際負載。對於Web服務來說，基於並發數（Concurrency）或者每秒處理請求數（RPS）進行Auto Scaling更能直接反映服務效能。

Knative Serving會為每個Pod注入queue-proxy容器，收集容器並發數（Concurrency）或請求數（RPS）指標。Autoscaler定時擷取指標後，會根據相應的演算法自動調整Deployment的Pod數量，從而實現基於請求的自動擴縮容。實現流程如下。

使用者發起請求，HTTP Router將請求轉寄至Knative的Serverless Service（SKS）。
簡單來說，您可以將SKS理解為Knative基於Kubernetes抽象的Service資源,其後端可以對應不同的 endpoints
SKS根據應用中的運行執行個體數量進行路由決策。
- Serve 模式：當前應用中有運行執行個體，直接將請求轉寄至運行中的 Pod。
- Proxy 模式：當前應用中執行個體數量已縮容至0，流量會被路由到 Activator。Activator作為請求緩衝代理。
Activator接收請求並記錄並髮指標，然後將指標發送至Autoscaler。
Autoscaler 根據預設指標判斷是否需要擴容，在需要時向API Server發送擴容申請。
API Server根據Autoscaler的請求更新 Deployment，建立新Pod。
Activator 在檢測到新 Pod 就緒後，將請求轉寄至新 Pod。

操作文檔，請參見基於流量請求數實現服務自動擴縮容。

在沒有流量時將 Pod數量自動縮容至 0

Knative支援在應用無流量請求時將Pod數量自動縮容至0，並在有請求時自動擴容Pod。Knative中定義了2種請求訪問模式：Proxy（代理模式）和 Serve（請求直達模式）。模式的切換由Autoscaler組件負責。當請求為0時，Autoscaler會將請求模式切換為Proxy模式。當有請求訪問時，Autoscaler會收到通知進行擴容，擴容的Pod狀態變為Ready後對請求進行轉寄，此時Autoscaler會將訪問模式切換為Serve模式。

配置樣本，請參見基於流量請求數實現服務自動擴縮容。

多版本管理與灰階發布

Configuration的更新會建立一個唯一的Revision。Route可以將請求路由到Revision，並向不同的Revision轉寄不同比例的流量。您可以使用Revision進行版本管理（例如版本回退）。您還可以進行流量的灰階發布，例如建立了V1版本的Revision後，當版本需要變更時可以更新服務的Configuration，建立V2版本的Revision，通過Route對V1、V2設定不同的流量比例（例如V1為70%，V2是30%），那麼流量會按照預設的比例進行分發。

操作文檔，請參見基於流量灰階發布服務。