Knative 入門系列2

即便使用無服務器架構,處理和響應 HTTP 請求的能力依然重要。在開始寫代碼使用事件觸發一個函數之前,您需要有地方來運行代碼。

本章探討 Knative Serving 組件,您將了解 Knative Serving 如何管理部署以及為應用和函數提供服務。通過 Serving,您可以輕松地將一個預先構建好的鏡像部署到底層 Kubernetes 集群中。(在第三章:Build,您將看到 Knative Build 可以幫助構建鏡像以在 Serving 組件中運行)Knative Serving 維護某一時刻的快照,提供自動化伸縮功能 (既支持擴容,也支持縮容直至為零),以及處理必要的路由和網絡編排。

Serving 模塊定義一組特定的對象以控制所有功能:Revision(修訂版本)、Configuration (配置)、Route(路由)和 Service(服務)。Knative 使用 Kubernetes CRD(自定義資源)的方式實現這些 Kubernetes 對象。下圖 2-1 展示所有 Serving 組件對象模型間的關系。在接下去的章節將具體介紹每個部分。

圖 2-1: Knative Serving 對象模型

Configuration(配置)和 Revision(修訂版本)

Knative Serving 始于 Configuration。您可以在 Configuration 中為部署定義所需的狀態。最小化 Configuration 至少包括一個配置名稱和一個要部署容器鏡像的引用。在 Knative 中,定義的引用為 Revision。Revision 代表一個不變的,某一時刻的代碼和 Configuration 的快照。每個 Revision 引用一個特定的容器鏡像和運行它所需要的任何特定對象(例如環境變量和卷)。然而,您不必顯式創建 Revision。由于 Revision 是不變的,它們從不會被改變和刪除,相反,當您修改 Configuration 的時候,Knative 會創建一個 Revision。這允許一個 Configuration 既反映工作負載的當前狀態,同時也維護一個它自己的歷史 Revision 列表。

以下示例 2-1 展示了一個完整的 Configuration 定義。它指定一個 Revision,該 Revision 使用一個容器鏡像倉庫 URI 引用一個特定的鏡像并且指定其版本標簽。

示例 2-1. knative-helloworld/configuration.yml

apiVersion: serving.knative.dev/v1alpha1kind: Configurationmetadata:  name: knative-helloworld  namespace: defaultspec:  revisionTemplate:    spec:      container:        image: docker.io/gswk/knative-helloworld:latest        env:          - name: MESSAGE            value: "Knative!"

現在,您可以用一個簡單的命令啟用該 YAML 文件:

$ kubectl apply -f configuration.yaml

自定義端口

默認情況下,Knative 將假定您的應用程序監聽 8080 端口。但是,如果不是這樣的話,您可以通過 containerPort 參數自定義一個端口:

spec:      revisionTemplate:        spec:          container:            image: docker.io/gswk/knative-helloworld:latest            env:              - name: MESSAGE                value: "Knative!"            ports:              - containerPort: 8081

就像任意 Kubernetes 對象一樣,您可以在系統中使用命令行工具(CLI)查閱 Revision 和 Configuration。您可以使用 kubectlgetrevisions 和 kubectlgetconfigurations 得到它們的列表。獲取我們剛剛創建示例 2-1 的 Configuration,可以使用命令 kubectlgetconfiguration knative-helloworld-oyaml。這將以 YAML 形式顯示該 Configuration 完整詳情(如下示例 2-2)。

示例 2-2. 命令 kubectlgetconfiguration knative-hellworld-oyaml 的輸出

apiVersion: serving.knative.dev/v1alpha1kind: Configurationmetadata:  creationTimestamp: YYYY-MM-DDTHH:MM:SSZ  generation: 1  labels:    serving.knative.dev/route: knative-helloworld    serving.knative.dev/service: knative-helloworld  name: knative-helloworld  namespace: default  ownerReferences:  - apiVersion: serving.knative.dev/v1alpha1    blockOwnerDeletion: true    controller: true    kind: Service    name: knative-helloworld    uid: 9835040f-f29c-11e8-a238-42010a8e0068  resourceVersion: "374548"  selfLink: "/apis/serving.knative.dev/v1alpha1/namespaces    /default/configurations/knative-helloworld"  uid: 987101a0-f29c-11e8-a238-42010a8e0068spec:  generation: 1  revisionTemplate:    metadata:      creationTimestamp: null    spec:      container:        image: docker.io/gswk/knative-helloworld:latest        name: ""        resources: {}status:  conditions:  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ    status: "True"    type: Ready  latestCreatedRevisionName: knative-helloworld-00001  latestReadyRevisionName: knative-helloworld-00001  observedGeneration: 1

注意示例 2-2 中 status 小節,Configuration 控制器保持對最近創建和就緒 Revison 的追蹤。它也包含了 Revision 的適用條件,表明它是否就緒以接收流量。

NOTEConfiguration 可以指定一個已有的容器鏡像,如示例 2-1 中所示?；蛘?它也可以選擇指向一個 Build 資源以從源代碼創建一個容器鏡像。第三章:Build 將介紹 Knative Build 組件的詳情并提供一些示例。

那么在 Kubernetes 集群內部發生了什么?我們在 Configuration 中指定的容器鏡像是什么樣子?Knative 轉換 Configuration 定義為一些 Kubernetes 對象并在集群中創建它們。在啟用 Configuration 后,可以看到相應的 Deployment、ReplicaSet 和 Pod。示例 2-3 展示了所有來自示例 2-1 所創建的對象。

示例 2-3. Knative 創建的 Kubernetes 對象

$ kubectl get deployments -onamedeployment.extensions/knative-helloworld-00001-deployment$ kubectl get replicasets -onamereplicaset.extensions/knative-helloworld-00001-deployment-5f7b54c768$ kubectl get pods -onamepod/knative-helloworld-00001-deployment-5f7b54c768-lrqt5

現在我們有了用于運行我們應用的 Pod,但是我們怎么知道該向哪里發送請求?這正是 Route 用武之地。

Route(路由)

Knative 中的 Route 提供了一種將流量路由到正在運行的代碼的機制。它將一個命名的,HTTP 可尋址端點映射到一個或者多個 Revision。Configuration 本身并不定義 Route。示例 2-4 展示了一個將流量發送到指定 Configuration 最新 Revision 的最基本路由定義。

示例 2-4. knative-helloworld/route.yml

apiVersion: serving.knative.dev/v1alpha1kind: Routemetadata:  name: knative-helloworld  namespace: defaultspec:  traffic:  - configurationName: knative-helloworldpercent: 100

就像我們對 Configuration 所做的那樣,我們可以運行一個簡單的命令應用該 YAML 文件:

kubectl apply -f route.yaml

這個定義中,Route 發送 100% 流量到由 configurationName 屬性指定 Configuration 的最新就緒 Revision,該 Revision 由 Configuration YAML 中 latestReadyRevisionName 屬性定義。您可以通過發送如下 curl 命令來測試這些 Route 和 Configuration :

curl -H "Host: knative-routing-demo.default.example.com"http://$KNATIVE_INGRESS

通過使用 revisionName 替代 latestReadyRevisionName ,您可以鎖定一個 Route 以發送流量到一個指定的 Revision。使用 name 屬性,您也可以通過可尋址子域名訪問 Revision。示例 2-5 同時展示兩種場景。

示例 2-5. knative-routing-demo/route.yml

apiVersion: serving.knative.dev/v1alpha1kind: Routemetadata:  name: knative-routing-demo  namespace: defaultspec:  traffic:  - revisionName: knative-routing-demo-00001    name: v1    percent: 100

我們可以再一次使用簡單命令應用該 YAML 文件:

kubectl apply -f route.yaml

指定的 Revision 可以使用 v1 子域名訪問,如下 curl 命令所示:

curl -H "Host: v1.knative-routing-demo.default.example.com"http://$KNATIVE_INGRESS

NOTEKnative 默認使用 example.com 域名,但不適合生產使用。您會注意到在 curl 命令 (v1.knative-routing-demo.default.example.com) 中作為一個主機頭傳遞的 URL 包含該默認值作為域名后綴。URL 格式遵循模式 {REVISION_NAME}.{SERVICE_NAME}.{NAMESPACE}.{DOMAIN} 。在這個案例中,子域名中 default 部分指的是命名空間。您將在第六章:部署注意事項一節中學習到如何改變這些值以及如何使用自定義域名。

Knative 也允許以百分比的方式跨 Revision 進行流量分配。支持諸如增量發布、藍綠部署或者其他復雜的路由場景。您將在第六章看到這些以及其他案例。

Autoscaler(自動伸縮器)和 Activator(激活器)

Serverless 的一個關鍵原則是可以按需擴容以滿足需要和縮容以節省資源。Serverless 負載應當可以一直縮容至零。這意味著如果沒有請求進入,則不會運行容器實例。Knative 使用兩個關鍵組件以實現該功能。它將 Autoscaler 和 Activator 實現為集群中的 Pod。您可以看到它們伴隨其他 Serving 組件一起運行在 knative-serving 命名空間中(參見示例 2-6)。

示例 2-6. kubectlgetpods-n knative-serving 輸出

NAME                          READY     STATUS    RESTARTS   AGEactivator-69dc4755b5-p2m5h    2/2       Running   0          7hautoscaler-7645479876-4h2ds   2/2       Running   0          7hcontroller-545d44d6b5-2s2vt   1/1       Running   0          7hwebhook-68fdc88598-qrt52      1/1       Running   0          7h

Autoscaler 收集打到 Revision 并發請求數量的有關信息。為了做到這一點,它在 Revision Pod 內運行一個稱之為 queue-proxy 的容器,該 Pod 中也運行用戶提供的 (user-provided) 鏡像?？梢栽谙鄳?Revision Pod 上,通過運行 kubectl describe 命令可以看到這些容器 (參見示例 2-7)。

示例 2-7. kubectl describe pod knative-helloworld-00001-deployment-id 輸出片段

...Containers:  user-container:    Container ID:  docker://f02dc...    Image:         index.docker.io/gswk/knative-helloworld......  queue-proxy:    Container ID:  docker://1afcb...    Image:         gcr.io/knative-releases/github.com/knative......

queue-proxy 檢測該 Revision 上觀察到的并發量,然后它每隔一秒將此數據發送到 Autoscaler。Autoscaler 每兩秒對這些指標進行評估?；谠u估的結果,它增加或者減少 Revision 部署的規模。

默認情況下,Autoscaler 嘗試維持每 Pod 每秒平均 100 個并發請求。這些并發目標和平均并發窗口均可以變化。Autoscaler 也能夠被配置為利用 Kubernets HPA (Horizontal Pod Autoscaler) 來替代該默認配置。這將基于 CPU 使用率來自動伸縮但不支持縮容至零。這些設定都能夠通過 Revision 元數據注解 (annotations) 定制。有關這些注解的詳情,請參閱 Knative 文檔。

例如,一個 Revision 每秒收到 350 個請求并且每次請求大約需要處理 0.5 秒。使用默認設置 (每 Pod 100 個并發請求),這個 Revision 將擴展至兩個 Pod:

350 * .5 = 175175 / 100 = 1.75ceil(1.75) = 2 pods

Autoscaler 也負責縮容至零。Revision 處于 Active (激活) 狀態才接受請求。當一個 Revision 停止接受請求時,Autoscaler 將其置為 Reserve (待命) 狀態,條件是每 Pod 平均并發必須持續 30 秒保持為 0 (這是默認設置,但可以配置)。

處于 Reserve 狀態下,一個 Revision 底層部署縮容至零并且所有到它的流量均路由至 Activator。Activator 是一個共享組件,其捕獲所有到待命 Revisios 的流量。當它收到一個到某一待命 Revision 的請求后,它轉變 Revision 狀態至 Active。然后代理請求至合適的 Pods。

Autoscaler 如何伸縮Autoscaler 采用的伸縮算法針對兩個獨立的時間間隔計算所有數據點的平均值。它維護兩個時間窗,分別是 60 秒和 6 秒。Autoscaler 使用這些數據以兩種模式運作:Stable Mode (穩定模式) 和 Panic Mode (忙亂模式)。在 Stable 模式下,它使用 60 秒時間窗平均值決定如何伸縮部署以滿足期望的并發量。如果 6 秒窗口的平均并發量兩次到達期望目標,Autoscaler 轉換為 Panic Mode 并使用 6 秒時間窗。這讓它更加快捷的響應瞬間流量的增長。它也僅僅在 Panic Mode 期間擴容以防止 Pod 數量快速波動。如果超過 60 秒沒有擴容發生,Autoscaler 會轉換回 Stable Mode。

圖 2-2 顯示 Autoscaler 和 Activator 如何和 Routes 及 Revisions 協同工作。

圖 2-2: Autoscaler 和 Activator 如何和 Routes 及 Revisions 互動。

WARNAutoscaler 和 Activator 均是 Knative 中快速演化的部分。參閱最新 Knative 文檔獲取最近改進。

服務

在 Knative 中,Service 管理負責的整個生命周期。包括部署、路由和回滾。(不要將 Knative Service 和 Kubernetes Service 混淆。它們是不同的資源。) Knative Service 控制一系列組成軟件的 Route 和 Configuration。Knative Service 可以被看作是一段代碼 —— 您正在部署的應用或者函數。

一個 Service 注意確保一個應用有一個 Route、一個 Configuation,以及為每次 Service 更新產生的一個新 Revision。當創建一個 Service 時,您沒有特別定義一個 Route,Knative 創建一個發送流量到最新 Revision 的路由。您可以選擇一個特定的 Revision 以路由流量到該 Revision。

不要求您明確創建一個 Service。Route 和 Configuration 可以被分開在不同的 YAML 文件(如示例 2-1 和 示例 2-4)。在這種情形下,您可以應用每個單獨的對象到集群。然而,推薦的方式使用一個 Service 來編排 Route 和 Configuration。示例 2-8 所示文件用于替換來自示例 2-1 和示例 2-4 定義的 configuation.yml 和 route.yml。

示例 2-8. knative-helloworld/service.yml

apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata:  name: knative-helloworld  namespace: defaultspec:  runLatest:    configuration:      revisionTemplate:        spec:          container:            image: docker.io/gswk/knative-helloworld:latest

注意這個 service.yml 文件和 configuration.yml 非常相似。這個文件定義 Configuration 并且是最小化 Service 定義。由于這里沒有 Route 定義,一個默認 Route 指向最新 Revision。Service 控制器整體追蹤它所有的 configuration 和 Route 的狀態。然后反映這些狀態在它的 ConfigurationsReady 和 RoutesReady conditions 屬性里。當通過 CLI 使用 kubectlgetksvc 命令請求 Knative Service 信息的時候,這些狀態可以被看到。

示例 2-9. kubectlgetksvc knative-helloworld-oyaml 命令輸出片段

apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata:...  name: knative-helloworld  namespace: default...spec:...status:conditions:  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ    status: "True"    type: ConfigurationsReady  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ    status: "True"    type: Ready  - lastTransitionTime: YYYY-MM-DDTHH:MM:SSZ    status: "True"    type: RoutesReady  domain: knative-helloworld.default.example.com  domainInternal: knative-helloworld.default.svc.cluster.local  latestCreatedRevisionName: knative-helloworld-00001  latestReadyRevisionName: knative-helloworld-00001  observedGeneration: 1  targetable:    domainInternal: knative-helloworld.default.svc.cluster.local  traffic:  - percent: 100    revisionName: knative-helloworld-00001

示例 2-9 顯示這個命令的輸出。

小結

至此已經向您介紹了 Service、Route、Configuration 和 Revision。Revision 是不變的并且只能經由 Configuration 改變而被創建。您可以分別單獨創建 Configuration 和 Route,或者把它們組合在一起并定義為一個 Service。理解 Serving 組件的這些構建塊是使用 Knative 的基礎。您部署的應用均需要一個 Service 或者 Configuration 以在 Knative 中作為容器運行。

但是,如何打包您的源代碼進入一個容器鏡像以使用本章介紹的方式進行部署?第三章將回答這些問題并且向您介紹 Knative Build 組件。