作者 | 李鵬（元毅）
來源 |
Serverless 公衆号一、為什麼需要 Knative
K8s 目前已成為雲原生市場上的主流作業系統，K8s 對上通過資料抽象暴露基礎設施能力，比如 Service、Ingress、Pod、Deployment 等，這些都是通過 K8s 原生 API 給使用者暴露出來的能力；而對下 K8s 提供了基礎設施接入的一些标準接口，比如 CNI、CRI、CRD，讓雲資源以一個标準化的方式進入到 K8s 的體系中。
K8s 處在一個承上啟下的位置，雲原生使用者使用 K8s 的目的是為了傳遞和管理應用，也包括灰階釋出、擴容縮容等。但是對使用者來說，實作這些能力，通過直接操作 K8s API 難免有些複雜。另外節省資源成本和彈性對于使用者來說也越來越重要。
那麼，如何才能簡單地使用 K8s 的技術，并且實作按需使用，最終實作降本增效的目的呢？答案就是 Knative。
二、Knative簡介
1. Knative 是什麼
- 定義
Knative 是一款基于 Kubernetes 的 Serverless 編排引擎，Knative 一個很重要的目标是制定雲原生跨平台的編排标準，它通過整合容器建構、工作負載以及事件驅動來實作這一目的。
Knative 社群目前貢獻者主要有 Google、Pivotal、IBM、Red Hat，可見其陣容強大，另外還有 CloudFoundry、OpenShift 這些 PAAS 提供商也都在積極地參與 Knative 的建設。
- 核心子產品
Knative 核心子產品主要包括兩部分：事件驅動架構 Eventing 和提供工作負載的 Serving，接下來本文主要介紹 Serving 相關的一些内容。
2. 流量灰階釋出
以一個簡單的場景為例：
- 在 K8s 中實作基于流量的灰階釋出
如果要在 K8s 中實作基于流量的灰階釋出，需要建立對應的 Service 與 Deployment，彈性相關的需要 HPA 來做，然後在流量灰階釋出時，要建立新的版本。
以上圖為例，創始版本是 v1，要想實作流量灰階釋出，我們需要建立一個新的版本 v2。建立 v2 時，要建立對應的 Service、Deployment、HPA。建立完之後通過 Ingress 設定對應的流量比例，最終實作流量灰階釋出的功能。
- 在 Knative 中實作基于流量的灰階釋出
如上圖所示，在 Knative 中想要實作基于流量的灰階釋出，隻需要建立一個 Knative Service，然後基于不同的版本進行灰階流量，可以用 Revision1 和 Revision2 來表示。在不同的版本裡面，已經包含了自動彈性。
從上面簡單的兩個圖例，我們可以看到在 Knative 中實作流量灰階釋出時，需要直接操作的資源明顯較少。
3. Knative Serving 架構
- Service
Service 對應 Serverless 編排的抽象，通過 Service 管理應用的生命周期。Service 下又包含兩大部分：Route 和 Configuration。
- Route
Route 對應路由政策。将請求路由到 Revision，并可以向不同的 Revision 轉發不同比例的流量。
- Configuration
Configuration 配置的是相應的資源資訊。目前期望狀态的配置。每次更新 Service 就會更新 Configuration。
- Revision
每次更新 Configuration 都會相應得到一個快照，這個快照就是 Revision，通過 Revision 實作多版本管理以及灰階釋出。
我們可以這樣了解：Knative Service ≈ Ingress + Service + Deployment + 彈性（HPA）。
4. 豐富的彈性政策
當然，Serverless 架構離不開彈性， Knative 中提供了以下豐富的彈性政策：
- 基于流量請求的自動擴縮容：KPA；
- 基于 CPU、Memory 的自動擴縮容：HPA；
- 支援定時 + HPA 的自動擴縮容政策；
- 事件網關（基于流量請求的精準彈性）。
三、Knative 和 ASK 融合
1. ASK：Serverless Kubernetes
如果要準備 ECI 資源的話，需要提前進行容量規劃，這無疑違背了 Serverless 的初衷。為擺脫 ECI 資源的束縛，不必提前進行 ECI 資源規劃，阿裡雲提出了無伺服器 Serverless——ASK。使用者無需購買節點，即可直接部署容器應用，無需對節點進行維護和容量規劃。ASK 提供了 K8s 相容的能力，同時極大地降低了 K8s 的使用門檻，讓使用者專注于應用程式，而不是底層基礎設施。
ASK 提供了以下能力：
- 免運維
開箱即用，無節點管理和運維，無節點安全維護，無節點 NotReady，簡化 K8s 叢集管理。
- 極緻的彈性擴容
無容量規劃，秒級擴容，30s 500pod。
- 低成本
按需建立 Pod，支援 Spot，預留執行個體券。
- 相容 K8s
支援 Deployment/statfulset/job/service/ingress/crd 等。
- 存儲挂載
支援挂載雲盤、NAS、OSS 存儲券。
- Knative on ASK
基于應用流量的自動彈性，開箱即用，縮容到最小規格。
- Elastic Workload
支援 ECI 按量和 Spot 混合排程。
- 內建 ARMS/SLS 等雲産品
2. Knative 運維複雜度
Knative 運維主要存在三個方面的問題：Gateway、Knative 管控元件和冷啟動問題。
如上圖所示，在 Knative 中管控元件會涉及到相應的 Activator，它是從 0 到 1 的一個元件；Autoscaler 是擴縮容相關的元件；Controller 是自身的管控元件以及網關。對于這些元件的運維，如果放在使用者層面做，無疑會加重負擔，同時這些元件還會占用成本。
除此之外，從 0 到 1 的冷啟動問題也需要考慮。當應用請求過來時，第一個資源從開始到啟動完成需要一段時間，這段時間内的請求如果響應不及時的話，會造成請求逾時，進而帶來冷啟動問題。
對于上面說到的這些問題，我們可以通過 ASK 來解決。下面看下 ASK 是如何做的？
3. Gateway 和 SLB 融合
相比于之前 Istio 提供的能力，我們需要營運管控 Istio 相關的元件，這無疑加大了管控成本。實際上對于大部分場景來說，我們更關心網關的能力，Istio 本身的一些服務（比如服務網格）我們其實并不需要。
在 ASK 中，我們将網關這一層通過 SLB 進行了替換：
- 降成本：減少了十幾個元件，大大降低運維成本和 IaaS 成本；
- 更穩定：SLB 雲産品服務更穩定，可靠性更高，易用性也更好。
4. 管控元件下沉
對于 Knative 管控元件，ASK 做了一些托管：
- 開箱即用：使用者直接使用 Serverless Framework，不需要自己安裝；
- 免運維、低成本：Knative 元件和 K8s 叢集進行融合，使用者沒有運維負擔，也無需承擔額外的資源成本；
- 高管控：所有元件都在管控端部署，更新和疊代更容易。
5. 優雅的保留執行個體
在 ASK 平台中，我們提供了優雅保留執行個體的能力，其作用是免冷啟動。通過保留執行個體，消除了從 0 到 1 的冷啟動時間。當我們縮容到 0 的時候，并沒有把執行個體真正縮容到 0，而是縮容到一個低規格的保留執行個體上，目的是降低成本。
- 免冷啟動：通過保留規格消除了從 0 到 1 的 30 秒冷啟動時間；
- 成本可控：突發性能執行個體成本比标準規格執行個體降低 40% 的成本，如果和 Spot 執行個體結合還能再進一步降低成本。
四、實操示範
最後進行動手實踐示範，以一家咖啡店（cafe）為例，示範内容主要有：
- 在 ASK 叢集中安裝 Knative；
- 部署 coffee 服務；
- 通路 coffee 服務；
- 保留執行個體。
示範過程觀看連結：
https://developer.aliyun.com/live/246126作者簡介：
李鵬，花名：元毅，阿裡雲容器平台進階開發工程師，2016 年加入阿裡， 深度參與了阿裡巴巴全面容器化、連續多年支援雙十一容器化鍊路。專注于容器、Kubernetes、Service Mesh 和 Serverless 等雲原生領域，緻力于建構新一代 Serverless 平台。目前負責阿裡雲容器服務 Knative 相關工作。