K8s 原生 Serverless 實踐：ASK 與 Knative

作者 | 李鵬（元毅）

爲什麼需要 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 中實現基於流量的灰度發佈，需要創建對應的 Service 與 Deployment，彈性相關的需要 HPA 來做，然後在流量灰度發佈時，要創建新的版本。

以上圖爲例，創始版本是 v1，要想實現流量灰度發佈，我們需要創建一個新的版本 v2。創建 v2 時，要創建對應的 Service、Deployment、HPA。創建完之後通過 Ingress 設置對應的流量比例，最終實現流量灰度發佈的功能。

如上圖所示，在 Knative 中想要實現基於流量的灰度發佈，只需要創建一個 Knative Service，然後基於不同的版本進行灰度流量，可以用 Revision1 和 Revision2 來表示。在不同的版本里面，已經包含了自動彈性。

從上面簡單的兩個圖例，我們可以看到在 Knative 中實現流量灰度發佈時，需要直接操作的資源明顯較少。

3. Knative Serving 架構

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

Route 對應路由策略。將請求路由到 Revision，並可以向不同的 Revision 轉發不同比例的流量。

Configuration 配置的是相應的資源信息。當前期望狀態的配置。每次更新 Service 就會更新 Configuration。

每次更新 Configuration 都會相應得到一個快照，這個快照就是 Revision，通過 Revision 實現多版本管理以及灰度發佈。

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

4. 豐富的彈性策略

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

Knative 和 ASK 融合

1. ASK：Serverless Kubernetes

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

ASK 提供了以下能力：

開箱即用，無節點管理和運維，無節點安全維護，無節點 NotReady，簡化 K8s 集羣管理。

無容量規劃，秒級擴容，30s 500pod。

按需創建 Pod，支持 Spot，預留實例券。

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

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

基於應用流量的自動彈性，開箱即用，縮容到最小規格。

支持 ECI 按量和 Spot 混合調度。

2. Knative 運維複雜度

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

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

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

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

3. Gateway 和 SLB 融合

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

在 ASK 中，我們將網關這一層通過 SLB 進行了替換：

4. 管控組件下沉

對於 Knative 管控組件，ASK 做了一些託管：

5. 優雅的保留實例

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

實操演示

最後進行動手實踐演示，以一家咖啡店（cafe）爲例，演示內容主要有：

演示過程觀看方式：

（掃碼觀看實操演示）

作者簡介：

李鵬，花名：元毅，阿里雲容器平臺高級開發工程師，2016 年加入阿里， 深度參與了阿里巴巴全面容器化、連續多年支持雙十一容器化鏈路。專注於容器、Kubernetes、Service Mesh 和 Serverless 等雲原生領域，致力於構建新一代 Serverless 平臺。當前負責阿里雲容器服務 Knative 相關工作。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/v-5MpEqKiwVpA0Xlt15qnA

猜你喜歡