做者 | 李鵬（元毅） 來源 | Serverless 公衆號安全
1、爲何須要 Knative
K8s 目前已成爲雲原生市場上的主流操做系統，K8s 對上經過數據抽象暴露基礎設施能力，好比 Service、Ingress、Pod、Deployment 等，這些都是經過 K8s 原生 API 給用戶暴露出來的能力；而對下 K8s 提供了基礎設施接入的一些標準接口，好比 CNI、CRI、CRD，讓雲資源以一個標準化的方式進入到 K8s 的體系中。服務器
K8s 處在一個承上啓下的位置，雲原生用戶使用 K8s 的目的是爲了交付和管理應用，也包括灰度發佈、擴容縮容等。可是對用戶來講，實現這些能力，經過直接操做 K8s API 不免有些複雜。另外節省資源成本和彈性對於用戶來講也愈來愈重要。架構
那麼，如何才能簡單地使用 K8s 的技術，而且實現按需使用，最終實現降本增效的目的呢？答案就是 Knative。框架
2、Knative簡介
1. Knative 是什麼
- 定義
Knative 是一款基於 Kubernetes 的 Serverless 編排引擎，Knative 一個很重要的目標是制定雲原生跨平臺的編排標準，它經過整合容器構建、工做負載以及事件驅動來實現這一目的。less
Knative 社區當前貢獻者主要有 Google、Pivotal、IBM、Red Hat，可見其陣容強大，另外還有 CloudFoundry、OpenShift 這些 PAAS 提供商也都在積極地參與 Knative 的建設。運維
- 核心模塊
Knative 核心模塊主要包括兩部分：事件驅動框架 Eventing 和提供工做負載的 Serving，接下來本文主要介紹 Serving 相關的一些內容。性能
2. 流量灰度發佈
以一個簡單的場景爲例：阿里雲
- 在 K8s 中實現基於流量的灰度發佈
若是要在 K8s 中實現基於流量的灰度發佈，須要建立對應的 Service 與 Deployment，彈性相關的須要 HPA 來作，而後在流量灰度發佈時，要建立新的版本。url
以上圖爲例，創始版本是 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 的自動擴縮容策略；
- 事件網關（基於流量請求的精準彈性）。
3、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 實例結合還能再進一步下降成本。
4、實操演示
最後進行動手實踐演示，以一家咖啡店（cafe）爲例，演示內容主要有：
- 在 ASK 集羣中安裝 Knative；
- 部署 coffee 服務；
- 訪問 coffee 服務；
- 保留實例。
演示過程觀看連接：https://developer.aliyun.com/live/246126
做者簡介： 李鵬，花名：元毅，阿里雲容器平臺高級開發工程師，2016 年加入阿里， 深度參與了阿里巴巴全面容器化、連續多年支持雙十一容器化鏈路。專一於容器、Kubernetes、Service Mesh 和 Serverless 等雲原生領域，致力於構建新一代 Serverless 平臺。當前負責阿里雲容器服務 Knative 相關工做。