K8s中ASK與Knative的示例分析

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)K8s中ASK與Knative的示例分析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、為什么需要 Knative

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

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

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

二、Knative簡介

1. Knative 是什么

• 定義

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

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

• 核心模塊

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

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

以一個(gè)簡單的場景為例：

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

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

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

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

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

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 就會(huì)更新 Configuration。

• Revision

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

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

4. 豐富的彈性策略

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

• 基于流量請求的自動(dòng)擴(kuò)縮容：KPA；

• 基于 CPU、Memory 的自動(dòng)擴(kuò)縮容：HPA；

• 支持定時(shí) + HPA 的自動(dòng)擴(kuò)縮容策略；

• 事件網(wǎng)關(guān)（基于流量請求的精準(zhǔn)彈性）。

三、Knative 和 ASK 融合

1. ASK：Serverless Kubernetes

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

ASK 提供了以下能力：

• 免運(yùn)維

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

• 極致的彈性擴(kuò)容

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

• 低成本

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

• 兼容 K8s

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

• 存儲(chǔ)掛載

支持掛載云盤、NAS、OSS 存儲(chǔ)券。

• Knative on ASK

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

• Elastic Workload

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

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

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

Knative 運(yùn)維主要存在三個(gè)方面的問題：Gateway、Knative 管控組件和冷啟動(dòng)問題。

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

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

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

3. Gateway 和 SLB 融合

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

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

• 降成本：減少了十幾個(gè)組件，大大降低運(yùn)維成本和 IaaS 成本；

• 更穩(wěn)定：SLB 云產(chǎn)品服務(wù)更穩(wěn)定，可靠性更高，易用性也更好。

4. 管控組件下沉

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

• 開箱即用：用戶直接使用 Serverless Framework，不需要自己安裝；

• 免運(yùn)維、低成本：Knative 組件和 K8s 集群進(jìn)行融合，用戶沒有運(yùn)維負(fù)擔(dān)，也無需承擔(dān)額外的資源成本；

• 高管控：所有組件都在管控端部署，升級和迭代更容易。

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

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

• 免冷啟動(dòng)：通過保留規(guī)格消除了從 0 到 1 的 30 秒冷啟動(dòng)時(shí)間；

• 成本可控：突發(fā)性能實(shí)例成本比標(biāo)準(zhǔn)規(guī)格實(shí)例降低 40% 的成本，如果和 Spot 實(shí)例結(jié)合還能再進(jìn)一步降低成本。

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