K8s中ASK與Knative的示例分析

這期內容當中小編將會給大家帶來有關K8s中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 中實現基于流量的灰度發布

如果要在 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 實例結合還能再進一步降低成本。

上述就是小編為大家分享的K8s中ASK與Knative的示例分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。