作者 | 李鵬（元毅）
來源 | Serverless 公眾號

一、為什么需要 Knative

K8s 目前已成為云原生市場上的主流操作系統(tǒng)，K8s 對上通過數(shù)據(jù)抽象暴露基礎(chǔ)設(shè)施能力，比如 Service、Ingress、Pod、Deployment 等，這些都是通過 K8s 原生 API 給用戶暴露出來的能力；而對下 K8s 提供了基礎(chǔ)設(shè)施接入的一些標準接口，比如 CNI、CRI、CRD，讓云資源以一個標準化的方式進入到 K8s 的體系中。

K8s 處在一個承上啟下的位置，云原生用戶使用 K8s 的目的是為了交付和管理應(yīng)用，也包括灰度發(fā)布、擴容縮容等。但是對用戶來說，實現(xiàn)這些能力，通過直接操作 K8s API 難免有些復(fù)雜。另外節(jié)省資源成本和彈性對于用戶來說也越來越重要。

那么，如何才能簡單地使用 K8s 的技術(shù)，并且實現(xiàn)按需使用，最終實現(xiàn)降本增效的目的呢？答案就是 Knative。

二、Knative簡介

1. Knative 是什么

• 定義

Knative 是一款基于 Kubernetes 的 Serverless 編排引擎，Knative 一個很重要的目標是制定云原生跨平臺的編排標準，它通過整合容器構(gòu)建、工作負載以及事件驅(qū)動來實現(xiàn)這一目的。

Knative 社區(qū)當(dāng)前貢獻者主要有 Google、Pivotal、IBM、Red Hat，可見其陣容強大，另外還有 CloudFoundry、OpenShift 這些 PAAS 提供商也都在積極地參與 Knative 的建設(shè)。

• 核心模塊

Knative 核心模塊主要包括兩部分：事件驅(qū)動框架 Eventing 和提供工作負載的 Serving，接下來本文主要介紹 Serving 相關(guān)的一些內(nèi)容。

2. 流量灰度發(fā)布

以一個簡單的場景為例：

• 在 K8s 中實現(xiàn)基于流量的灰度發(fā)布

如果要在 K8s 中實現(xiàn)基于流量的灰度發(fā)布，需要創(chuàng)建對應(yīng)的 Service 與 Deployment，彈性相關(guān)的需要 HPA 來做，然后在流量灰度發(fā)布時，要創(chuàng)建新的版本。

以上圖為例，創(chuàng)始版本是 v1，要想實現(xiàn)流量灰度發(fā)布，我們需要創(chuàng)建一個新的版本 v2。創(chuàng)建 v2 時，要創(chuàng)建對應(yīng)的 Service、Deployment、HPA。創(chuàng)建完之后通過 Ingress 設(shè)置對應(yīng)的流量比例，最終實現(xiàn)流量灰度發(fā)布的功能。

• 在 Knative 中實現(xiàn)基于流量的灰度發(fā)布

如上圖所示，在 Knative 中想要實現(xiàn)基于流量的灰度發(fā)布，只需要創(chuàng)建一個 Knative Service，然后基于不同的版本進行灰度流量，可以用 Revision1 和 Revision2 來表示。在不同的版本里面，已經(jīng)包含了自動彈性。
?
從上面簡單的兩個圖例，我們可以看到在 Knative 中實現(xiàn)流量灰度發(fā)布時，需要直接操作的資源明顯較少。

3. Knative Serving 架構(gòu)

• **Service **

Service 對應(yīng) Serverless 編排的抽象，通過 Service 管理應(yīng)用的生命周期。Service 下又包含兩大部分：Route 和 Configuration。

• Route

Route 對應(yīng)路由策略。將請求路由到 Revision，并可以向不同的 Revision 轉(zhuǎn)發(fā)不同比例的流量。

• Configuration

Configuration 配置的是相應(yīng)的資源信息。當(dāng)前期望狀態(tài)的配置。每次更新 Service 就會更新 Configuration。

• Revision

每次更新 Configuration 都會相應(yīng)得到一個快照，這個快照就是 Revision，通過 Revision 實現(xiàn)多版本管理以及灰度發(fā)布。

我們可以這樣理解：Knative Service ≈ Ingress + Service + Deployment + 彈性（HPA）。

4. 豐富的彈性策略

當(dāng)然，Serverless 框架離不開彈性， Knative 中提供了以下豐富的彈性策略：

• 基于流量請求的自動擴縮容：KPA；
• 基于 CPU、Memory 的自動擴縮容：HPA；
• 支持定時 + HPA 的自動擴縮容策略；
• 事件網(wǎng)關(guān)（基于流量請求的精準彈性）。

三、Knative 和 ASK 融合

1. ASK：Serverless Kubernetes

如果要準備 ECI 資源的話，需要提前進行容量規(guī)劃，這無疑違背了 Serverless 的初衷。為擺脫 ECI 資源的束縛，不必提前進行 ECI 資源規(guī)劃，阿里云提出了無服務(wù)器 Serverless——ASK。用戶無需購買節(jié)點，即可直接部署容器應(yīng)用，無需對節(jié)點進行維護和容量規(guī)劃。ASK 提供了 K8s 兼容的能力，同時極大地降低了 K8s 的使用門檻，讓用戶專注于應(yīng)用程序，而不是底層基礎(chǔ)設(shè)施。

ASK 提供了以下能力：

• 免運維

開箱即用，無節(jié)點管理和運維，無節(jié)點安全維護，無節(jié)點 NotReady，簡化 K8s 集群管理。

• 極致的彈性擴容

無容量規(guī)劃，秒級擴容，30s 500pod。

• 低成本

按需創(chuàng)建 Pod，支持 Spot，預(yù)留實例券。

• 兼容 K8s

支持 Deployment/statfulset/job/service/ingress/crd 等。

• 存儲掛載

支持掛載云盤、NAS、OSS 存儲券。

• Knative on ASK

基于應(yīng)用流量的自動彈性，開箱即用，縮容到最小規(guī)格。

• Elastic Workload

支持 ECI 按量和 Spot 混合調(diào)度。

• 集成 ARMS/SLS 等云產(chǎn)品

2. Knative 運維復(fù)雜度

Knative 運維主要存在三個方面的問題：Gateway、Knative 管控組件和冷啟動問題。

如上圖所示，在 Knative 中管控組件會涉及到相應(yīng)的 Activator，它是從 0 到 1 的一個組件；Autoscaler 是擴縮容相關(guān)的組件；Controller 是自身的管控組件以及網(wǎng)關(guān)。對于這些組件的運維，如果放在用戶層面做，無疑會加重負擔(dān)，同時這些組件還會占用成本。

除此之外，從 0 到 1 的冷啟動問題也需要考慮。當(dāng)應(yīng)用請求過來時，第一個資源從開始到啟動完成需要一段時間，這段時間內(nèi)的請求如果響應(yīng)不及時的話，會造成請求超時，進而帶來冷啟動問題。

對于上面說到的這些問題，我們可以通過 ASK 來解決。下面看下 ASK 是如何做的？

3. Gateway 和 SLB 融合

相比于之前 Istio 提供的能力，我們需要運營管控 Istio 相關(guān)的組件，這無疑加大了管控成本。實際上對于大部分場景來說，我們更關(guān)心網(wǎng)關(guān)的能力，Istio 本身的一些服務(wù)（比如服務(wù)網(wǎng)格）我們其實并不需要。

在 ASK 中，我們將網(wǎng)關(guān)這一層通過 SLB 進行了替換：

• 降成本：減少了十幾個組件，大大降低運維成本和 IaaS 成本；
• 更穩(wěn)定：SLB 云產(chǎn)品服務(wù)更穩(wěn)定，可靠性更高，易用性也更好。

4. 管控組件下沉

對于 Knative 管控組件，ASK 做了一些托管：

• 開箱即用：用戶直接使用 Serverless Framework，不需要自己安裝；
• 免運維、低成本：Knative 組件和 K8s 集群進行融合，用戶沒有運維負擔(dān)，也無需承擔(dān)額外的資源成本；
• 高管控：所有組件都在管控端部署，升級和迭代更容易。

5. 優(yōu)雅的保留實例

在 ASK 平臺中，我們提供了優(yōu)雅保留實例的能力，其作用是免冷啟動。通過保留實例，消除了從 0 到 1 的冷啟動時間。當(dāng)我們縮容到 0 的時候，并沒有把實例真正縮容到 0，而是縮容到一個低規(guī)格的保留實例上，目的是降低成本。

• 免冷啟動：通過保留規(guī)格消除了從 0 到 1 的 30 秒冷啟動時間；
• 成本可控：突發(fā)性能實例成本比標準規(guī)格實例降低 40% 的成本，如果和 Spot 實例結(jié)合還能再進一步降低成本。

四、實操演示

最后進行動手實踐演示，以一家咖啡店（cafe）為例，演示內(nèi)容主要有：

• 在 ASK 集群中安裝 Knative；
• 部署 coffee 服務(wù)；
• 訪問 coffee 服務(wù)；
• 保留實例。

演示過程觀看鏈接：https://developer.aliyun.com/live/246126

作者簡介：
李鵬，花名：元毅，阿里云容器平臺高級開發(fā)工程師，2016 年加入阿里， 深度參與了阿里巴巴全面容器化、連續(xù)多年支持雙十一容器化鏈路。專注于容器、Kubernetes、Service Mesh 和 Serverless 等云原生領(lǐng)域，致力于構(gòu)建新一代 Serverless 平臺。當(dāng)前負責(zé)阿里云容器服務(wù) Knative 相關(guān)工作。

總結(jié)

以上是生活随笔為你收集整理的K8s 原生 Serverless 实践：ASK 与 Knative的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。