作者 | 牛秋霖（冬島） 阿里云容器平臺技術(shù)專家

關(guān)注“阿里巴巴云原生”公眾號，回復(fù)關(guān)鍵詞“1205”即可觀看 Knative-Demo 演示視頻。

導(dǎo)讀：Serverless 無疑是當(dāng)前最熱的云原生話題，那么作為業(yè)務(wù)的開發(fā)人員或者運維人員咱們應(yīng)該怎么看待這個事情？云原生和 Serverless 到底有什么關(guān)系？通過本次分享咱們將逐一揭開這些神秘的面紗。

通過本文您將了解到：

Knative 是如何讓普通的應(yīng)用具備 Serverless 能力的？

為什么說 Knative 是云原生的應(yīng)用 Serverless 編排引擎？

Knative 為什么是由 Tekton 、Eventing 和 Serving 三個模塊組成，以及這三個模塊的協(xié)作方式。

本文共有四部分內(nèi)容：首先咱們一起來看一下云的核心驅(qū)動力是什么，接著從這個核心驅(qū)動力出發(fā)看一下云原生應(yīng)用是什么樣子。然后咱們再一起來看看 Knative 到底給應(yīng)用的云原生化帶來了什么價值，最后咱們通過一個 Demo 親身感受一下 Knative 帶來的這些能力。

云的核心驅(qū)動力

在討論云原生之前我們先來思考一下：為什么企業(yè)要上云、為什么技術(shù)人員要學(xué)習(xí)面向云的編程思維以及咱們應(yīng)該怎么看待云這件事兒。

咱們先來剖析一下發(fā)生這些事情的核心驅(qū)動力，然后通過這個核心驅(qū)動力出發(fā)看看整個云原生技術(shù)棧是什么樣子。

社會分工

我們先從一頓火鍋談起，一頓火鍋雖然很簡單，但會涉及到非常多的東西，比如各種蔬菜、牛羊肉等。細(xì)想一下，所有的這些東西我們都經(jīng)常食用，但是其中有哪些東西是我們自己親手種植或養(yǎng)殖的呢？事實上都沒有，我們每天都是坐在辦公室，下班的路上到市場或超市買到這些東西，不知道也并不關(guān)心這些東西的具體生產(chǎn)過程。

我小時候在內(nèi)蒙的農(nóng)村長大，大家都知道，內(nèi)蒙很大。村里每戶人家都有一個大園子，夏天的時候家家戶戶都會在園子里種植各種蔬菜，如西紅柿、黃瓜、茄子、辣椒等；但到了冬天，由于天氣很冷，根本見不到新鮮的蔬菜，大家吃的都是咸菜、酸菜，或者是秋天晾曬的一些干菜。我們可以發(fā)現(xiàn)：一個地域非常容易受到季節(jié)的影響，雖然夏天可以種植各種蔬菜，但是到了冬天就什么都沒有了。但是現(xiàn)在就不同了，全國各地隨處都能非常容易地買到新鮮蔬菜，這其實是社會分工的結(jié)果、是不同地域、不同角色之間通過市場相互協(xié)作的成果。

現(xiàn)在因為有專業(yè)的人在做這些事情，所以我們大多數(shù)人都無需勞心蔬菜是怎么種植的。而我們工程師所做的和計算機打交道的事情也能通過其他的渠道反過來幫助那些種菜的人。

分工提高效率，這是現(xiàn)代經(jīng)濟(jì)學(xué)之父亞當(dāng)斯密 200 多年前在他的經(jīng)典著作《國富論》中的開篇觀點。其實現(xiàn)代社會的運行機制也印證了該理論；我認(rèn)為它也是企業(yè)擁抱云計算的根本原因。因為大家需要把一些非業(yè)務(wù)核心的部分“承包”給專業(yè)的人士去完成，那些和自己的業(yè)務(wù)強相關(guān)的部分才是企業(yè)的核心競爭力。

應(yīng)用上云

接著咱們再來看看一個應(yīng)用都是由哪些部分構(gòu)成的。

應(yīng)用要提供服務(wù)首先要有計算、存儲和網(wǎng)絡(luò)資源才能把進(jìn)程跑起來。當(dāng)然這些也僅僅是把進(jìn)程跑起來，如果要承接具體的業(yè)務(wù)還需要依賴數(shù)據(jù)庫等服務(wù)；如果要做分布式架構(gòu)還需要做微服務(wù)拆分，這時候就需要緩存、注冊中心、消息各種中間件的服務(wù)。

以上的情況都是程序已經(jīng)存在，如何把程序跑起來承接業(yè)務(wù)的部分。還有一部分是如何把代碼變成可啟動的程序，這就是 CICD 部分了。從代碼到應(yīng)用啟動再到應(yīng)用依賴的周邊系統(tǒng)支撐都說完了，還有一部分就是日常運維相關(guān)的：

• 比如日志收集、分析
• 比如監(jiān)控和告警

雖然我們本來只是想要寫一個應(yīng)用，來為業(yè)務(wù)提供服務(wù)。但是應(yīng)用周邊的這些支撐系統(tǒng)比這個應(yīng)用自身的消耗還要高上很多。這其實不是我們期望的結(jié)果，讓業(yè)務(wù)團(tuán)隊更多的聚焦在業(yè)務(wù)邏輯本身，而不是周邊的這些系統(tǒng)上，這才是我們希望看到的。

實際上有一定規(guī)模的公司，內(nèi)部的組織架構(gòu)基本也都是由一個基礎(chǔ)平臺團(tuán)隊和多個業(yè)務(wù)團(tuán)隊構(gòu)成的，基礎(chǔ)平臺團(tuán)隊負(fù)責(zé)提供這些應(yīng)用需要的公共能力支撐，業(yè)務(wù)團(tuán)隊更聚焦在業(yè)務(wù)上，直接使用基礎(chǔ)平臺團(tuán)隊的能力即可。這其實就是社會分工在 IT 組織中的體現(xiàn)，專業(yè)的人做專業(yè)的事兒，分工提升效率。

現(xiàn)在我們再回顧一下剛才吃火鍋的例子。

如果時間倒退 20 年，回到北方的冬天，我們想要吃一頓有肉、有蔬菜、還有金針菇的火鍋，根本就不可能，但是現(xiàn)在，我們可以隨時隨地買到這些東西，而所有這些都是專業(yè)的人士生產(chǎn)的，我們無法自給自足這么豐富的資源。

那么對于一家企業(yè)而言，也是一樣的。雖然每個企業(yè)都有自己的基礎(chǔ)平臺團(tuán)隊，但是由于規(guī)模或者資金投入等原因，不可能提供像云這么豐富的平臺支撐。如果有，那一定也是一個云廠商。所以對于業(yè)務(wù)來說，把所有和應(yīng)用相關(guān)的周邊系統(tǒng)都使用云的初始設(shè)施搭建，把這些周邊系統(tǒng)承包給云廠商才是高效率的做法。我理解為這就是云原生出現(xiàn)的背景。

分工提高效率這是大家使用云的根本動力。云原生理念是在各大企業(yè)上云的過程中逐漸形成和完善的。這套理念是協(xié)調(diào)所有參與方對服務(wù)上云逐漸形成的統(tǒng)一標(biāo)準(zhǔn)，這個統(tǒng)一的標(biāo)準(zhǔn)可以很好地幫助企業(yè)上云、幫助云廠商釋放云的能力。從云的客戶角度來講，這個統(tǒng)一標(biāo)準(zhǔn)就是避免云廠商鎖定。比如 Kubernetes 就是一個非常好的統(tǒng)一共識，因為所有云平臺都支持 Kubernetes。

那么這個標(biāo)準(zhǔn)的價值是什么呢？為什么云廠商和上云的企業(yè)都積極參與這個標(biāo)準(zhǔn)的“制定”呢？這其實是一個互利互惠的結(jié)果。在具體談?wù)撨@個標(biāo)準(zhǔn)的作用之前，我們先來聊聊兩種資源分配模式的差別。

排隊（先到先得）

這部分咱們以就醫(yī)為例進(jìn)行說明。

去醫(yī)院看病需要提前掛號，醫(yī)生的號源這是一種先到先得的資源分配方式。特別是在北上廣這些大城市，好醫(yī)生的號源更是一號難求。如果想保證一定要拿到某個醫(yī)生的就診號，就要保證比別人都更早地到醫(yī)院排隊，提前排隊可以優(yōu)先拿到就診號。我們現(xiàn)在來分析一下，提前排隊的人所付出的努力都有什么價值。

• 對于排隊的當(dāng)事人：當(dāng)事人付出的努力對于自己是有意義的，自己拿到了就診號，得到了回報；

• 對于其他的排隊者而言，是沒有任何好處的。早來的人拿到了就診號，這就給別的競爭號源的人發(fā)出了一個信號——來的越早就越有可能得到號源。這有可能引發(fā)更多人更早的前來排隊，這是一個惡性循環(huán)；

• 對于醫(yī)生來說，沒有任何意義，誰來看病都是一樣，誰得到這個號對醫(yī)生來說差別不大。很多時候甚至患者要求加號，但醫(yī)生其實是不愿意的，因為每增加一個號源就意味著醫(yī)生要付出一點兒休息的時間。對于醫(yī)生而言，多付出的休息時間是不能換來更多報酬的，因為這是一個先到先得的排隊秩序規(guī)則，每一個號源的價格都是一樣的。

有沒有發(fā)現(xiàn)在排隊的過程中所做出的付出只對排隊的當(dāng)事人是有意義的，對于醫(yī)生以及其他排隊者都沒有任何意義，甚至?xí)韾盒愿偁?#xff0c;造成社會資源的巨大浪費。在排隊的過程中，大量的資源都白白地流失，沒有給社會帶來任何價值。

市場經(jīng)濟(jì)

這部分我們以購買云服務(wù)器 ECS 為例進(jìn)行說明。

假設(shè)目前阿里云的 ECS 是性價比最高的，大家上云都優(yōu)先選擇使用阿里云的 ECS，那么如果出現(xiàn)供不應(yīng)求的情況就可能會導(dǎo)致 ECS 價格上漲，而價格上漲就會導(dǎo)致更多的云廠商供應(yīng) ECS ，最終導(dǎo)致價格又回落下來。我們分析一下在這個過程中購買 ECS 的人和提供 ECS 的云廠商之間的關(guān)系：

• 我們發(fā)現(xiàn)大量客戶選購 ECS 這件事情本身對于上云的客戶是有益無害的，因為大量的需求會導(dǎo)致云廠商做更多的供應(yīng)，價格不可能持續(xù)高攀。所以 ECS 需求的競爭者之間其實不是零和博弈，而是一個相互合作的關(guān)系。大家一起把餅做大，就讓整個供應(yīng)鏈更穩(wěn)定、便宜。就好比我買蘋果手機，你也買蘋果手機，但是咱倆不是競爭關(guān)系，而且買的人越多，蘋果手機的質(zhì)量就會越來越好；

• 大量的 ECS 需求會促使 ECS 技術(shù)的成熟。對于 ECS 的提供者云廠商而言，越多的人購買自己的服務(wù)就越好，所有的客戶和云廠商之間都是相互促進(jìn)的關(guān)系。

市場經(jīng)濟(jì)這種基于價格的自由交易能夠非常高效地促進(jìn)大家的合作，任何一方的努力對于其他的參與者而言都是有價值的。和醫(yī)院排隊中先到的人付出的努力只對自己產(chǎn)生價值相比較，市場經(jīng)濟(jì)的自由交易方式中，每一方的付出都讓整個系統(tǒng)得到了優(yōu)化，這是社會資源合理利用、合理分配的一種非常好的方式。

是不是感覺扯遠(yuǎn)了，這和云計算有什么關(guān)系？我們繼續(xù)來剖析一下市場經(jīng)濟(jì)，就可以看到和云計算的密切關(guān)系了。

我們先來看一下這個場景：如果云廠商 A 提供的服務(wù)性價比很高，但是有一天云廠商 B 提供了性價比更高的服務(wù)，客戶會不會立即把服務(wù)遷移到云廠商 B 上去？答案是客戶想要遷移，但是比較難遷移。因為每一個云廠商提供的服務(wù)標(biāo)準(zhǔn)都不太一樣，服務(wù)遷移的過程需要適配大量差異化的底層基礎(chǔ)設(shè)施，這給遷移帶來了巨大的成本，甚至抵消了云廠商 B 提供的高性價比，所以平常比較少見到這種遷移。

前面咱們分析了市場經(jīng)濟(jì)的資源分配方式是非常有利于社會各方面資源進(jìn)行最優(yōu)配置的，可是如果云客戶不能在云廠商之間低成本的流動，其實就很難選擇性價比高的云廠商。所以從有效配置社會資源這個角度來分析，現(xiàn)在迫切需要一個能夠讓客戶在不同云廠商之間低成本“流動”的體系，而這就是云原生的意義所在。

如果把客戶要在云上托管的應(yīng)用比喻成水的話，那么云服務(wù)的價格就是海拔的高度。哪里海拔低，水就很自然的流到哪里去。無限降低遷移的成本，對于客戶和云廠商來說都是非常有價值的一件事情。云原生旨在以標(biāo)準(zhǔn)化云服務(wù)的提供方式銜接云廠商和客戶。這種方式對于客戶而言降低了上云和跨云遷移的成本，讓客戶始終保有和云廠商議價的能力；對云廠商而言，因為客戶跨云遷移的成本低，所以只要能提供性價比更高的云服務(wù)，就能很容易的聚集大量用戶。

云原生是在不斷促進(jìn)整個系統(tǒng)的良性循環(huán)：既能讓客戶始終保有選擇的能力，又能讓優(yōu)秀的云廠商快速服務(wù)更多的客戶。如果客戶的業(yè)務(wù)服務(wù)能像水一樣低成本在不同云廠商之間流通，那么云廠商提供的服務(wù)就能像貨幣一樣在客戶之間流通。這是一個多贏的局面。

云原生應(yīng)用

說完云原生這個理念，我們來看一下云原生應(yīng)用，以及在云原生的這個大背景下，如何看待傳統(tǒng)的應(yīng)用架構(gòu)？

云上基礎(chǔ)設(shè)施

無論是云上的應(yīng)用，還是云下的應(yīng)用，其實依賴的核心要素都沒有變，只是這些核心要素的提供形式發(fā)生了變化。

如上圖所示，共有 7 個核心要素。這 7 個要素中日常運維這一塊其實不是強依賴的，雖然它對業(yè)務(wù)的穩(wěn)定性影響極大，但是這并不是業(yè)務(wù)跑起來的核心鏈路，沒有這些業(yè)務(wù)也能跑，而其它的幾塊都是核心鏈路。那么我們就來看一下在云原生架構(gòu)下，這些核心鏈路的要素都處于什么位置？然后剖析一下云原生應(yīng)用的基本范式。

云原生技術(shù)棧

我們先來看看最右邊的中間件這一塊，里面有數(shù)據(jù)庫、Redis 以及消息中間件組件。而這一塊其實是應(yīng)用代碼里面直接調(diào)用的，并且這里包含的所有能力都有標(biāo)準(zhǔn)的協(xié)議，比如無論是使用 SQL Server 還是使用 MySQL，我們程序里都可以使用 SQL 規(guī)范進(jìn)行操作。這部分其實早就被標(biāo)準(zhǔn)化了。

如圖所示，計算、存儲和網(wǎng)絡(luò)這三個核心要素已經(jīng)被 Kubernetes 層統(tǒng)一了。很多云服務(wù)已經(jīng)實現(xiàn)了計算、存儲和網(wǎng)絡(luò)資源的無服務(wù)器化，比如阿里云的 ECI 和 ASK(Aliyun Serverless Kubernetes)。那么還有兩塊 CICD 和應(yīng)用托管沒有標(biāo)準(zhǔn)化，這就是應(yīng)用編排這一層需要標(biāo)準(zhǔn)化的事情。Serverless 其實不單單是無服務(wù)器，還包括應(yīng)用本身的編排，這也是應(yīng)用編排這一層的價值所在。

云原生應(yīng)用 Serverless 編排

Serverless Kubernetes 已經(jīng)提供了 Pod 的無服務(wù)器支持，而應(yīng)用層想要用好這個能力其實還有很多事情需要處理。

• 彈性：
  • 縮容到零
  • 突發(fā)流量
• 灰度發(fā)布
  • 如何實現(xiàn)灰度發(fā)布
  • 灰度發(fā)布和彈性的關(guān)系
• 流量管理
  • 灰度發(fā)布的時候如何在 v1 和 v2 之間動態(tài)調(diào)整流量比例
  • 流量管理和彈性是怎樣一個關(guān)系
  • 當(dāng)有突發(fā)流量的時候如何和彈性配合，做到突發(fā)請求不丟失

我們發(fā)現(xiàn)雖然基礎(chǔ)資源可以動態(tài)申請，但是應(yīng)用如果要做到實時彈性、按需分配和按量付費的能力還是需要有一層編排系統(tǒng)來完成應(yīng)用和 Kubernetes 的適配。這個適配不單單要負(fù)責(zé)彈性，還要有能力同時管理流量和灰度發(fā)布。

Knative 應(yīng)運而生

上文中的內(nèi)容就是 Knative 要解決的問題，這也是 Knative 出現(xiàn)的背景。接下來咱們來看看 Knative 。

Knative 是什么

我們先看看官方給出的定義：“基于 Kubernetes 平臺，用于構(gòu)建、部署和管理現(xiàn)代 Serverless 工作負(fù)載”。Knative 就是基于 Kubernetes 的應(yīng)用 Serverless 編排系統(tǒng)。實際上 Knative 包含的不單單是 Workload，它還有 Kubernetes 原生的流程編排引擎和完備的事件系統(tǒng)。

前面提到 Kubernetes 實現(xiàn)了計算、存儲和網(wǎng)絡(luò)的標(biāo)準(zhǔn)化，而 Knative 目標(biāo)基于 Kubernetes 提供了應(yīng)用 Serverless 工作負(fù)載編排的標(biāo)準(zhǔn)化。

Knative 核心模塊

Knative 由三個核心模塊構(gòu)成：Tekton、Eventing 和 Serving。

• Tekton 是 Kubernetes 原生的流程編排框架，主要用于構(gòu)建 CICD 系統(tǒng)；
• Eventing 主要負(fù)責(zé)事件處理功能，可以接入外部系統(tǒng)的事件，事件接入以后進(jìn)行一系列的流程處理以及觸發(fā) Serving 消費事件；
• Serving 是應(yīng)用運行工作負(fù)載的核心管理模塊，主要負(fù)責(zé)流量調(diào)度、彈性以及灰度發(fā)布等職責(zé)。

Tekton

Tekton 是一套 Kubernetes 原生的流程編排框架，主要用于構(gòu)建 CICD 系統(tǒng)。比如從源碼編譯成鏡像，以及對鏡像里的服務(wù)進(jìn)行測試、把鏡像發(fā)布成應(yīng)用等一系列的操作都可以基于 Tekton 完成。

Tekton 里面基本的執(zhí)行單元是 Task。>

• Task 里面可以包含多個順序執(zhí)行的 Step。一個 Task 最終就是一個 Pod，里面的每一個 Step 最終執(zhí)行的時候就是一個 Container 。每提交一個 TaskRun CRD 到 Kubernetes 就會觸發(fā)一次 Task 的執(zhí)行；

• Pipeline 可以編排多個 Task，Pipeline 中的 Task 是可以設(shè)置依賴關(guān)系。Pipeline 會根據(jù)依賴關(guān)系生成一個有向無環(huán)圖，然后生成的根據(jù)有向無環(huán)圖并發(fā)或者串行執(zhí)行一系列的 Task。每提交一個 PipelineRun CRD 就會觸發(fā) Pipeline 的一次執(zhí)行；

• PipelineResource 代表 Pipeline 使用或者生成的資源，比如：github 代碼倉庫、依賴或者使用的鏡像等等；

• Tekton 是 Kubernetes 原生的實現(xiàn)，所以資源鑒權(quán)的秘鑰等信息都可以通過 Kubernetes 的 Secret 進(jìn)行管理。

Eventing

Eventing 模塊基于 CloudEvent 標(biāo)準(zhǔn)實現(xiàn)了一系列的事件處理機制。Eventing 模塊的核心能力分成四大塊。

• 外部事件接入

Eventing 有很強的擴(kuò)展機制，可以接入任何外部事件源的事件，比如 github 里面的 commit、pull request 等事件；Kubernetes 里面的事件；消息系統(tǒng)里面的消息；以及 OSS、表格存儲、Redis 等系統(tǒng)的事件。

• CloudEvent 標(biāo)準(zhǔn)

Eventing 接入外部事件以后會轉(zhuǎn)換成 CloudEvent 格式，事件在內(nèi)部的流轉(zhuǎn)都是通過 CloudEvent 事件標(biāo)準(zhǔn)完成的。

• 事件在內(nèi)部的處理

Eventing 模塊引入的 Broker 、Trigger 模型，不僅將事件復(fù)雜的處理實現(xiàn)給用戶屏蔽起來，更提供了豐富的事件訂閱、過濾機制。

• 事件處理事務(wù)管理

Eventing 基于可靠的消息系統(tǒng)，可以對事件進(jìn)行事務(wù)管理。如果事件消費失敗可以進(jìn)行重試或者重新分發(fā)等操作。

Serving

Serving 核心的 CRD 就是 Service，Knative Controller 通過 Service 的配置自動操作 Kubernetes 的 Ingress、K8s Service 和 Deployment 從而實現(xiàn)簡化應(yīng)用管理的目標(biāo)。

Knative Service 對應(yīng)一個叫做 Configuration 的資源，每次 Service 變化如果需要創(chuàng)建新的 Workload 就更新 Configuration，然后每次 Configuration 更新都會創(chuàng)建一個唯一的 Revision，Revision 可以認(rèn)為是 Configuration 的版本管理機制。理論上 Revision 創(chuàng)建完以后是不會修改的，不同的 Revision 一般用于灰度發(fā)布。

Route 是 Knative 管理流量的核心邏輯，Knative 是建立在 Istio 之后的，Knative Route Controller 通過 Route 的配置自動生成 Istio 的 VirtualService 資源，從而實現(xiàn)了流量的管理。

Knative Serving 對應(yīng)用 Workload 的 Serverless 編排是從流量開始的。

流量首先達(dá)到 Knative 的 Gateway，Gateway 根據(jù) Route 的配置自動把流量根據(jù)百分比拆分到不同的 Revision 上，然后每一個 Revision 都有一個自己獨立的彈性策略。當(dāng)過來的流量請求變多的時候當(dāng)前 Revision 就開始自動擴(kuò)容。每一個 Revision 的擴(kuò)容策略都是獨立的，相互不影響。

基于流量百分比對不同的 Revision 進(jìn)行灰度，每一個 Revision 都有一個自己獨立的彈性策略。Knative Serving 通過對流量的控制實現(xiàn)了流量管理、彈性和灰度三者的完美結(jié)合。

Knative 的云原生特性

Kubernetes 是業(yè)界公認(rèn)的云原生操作系統(tǒng)，作為云原生的 Serverless 編排引擎 Knative 當(dāng)然是兼容 Kubernetes API 的。

Knative 本身就是開源的，你可以在任何 Kubernetes 集群上面部署一套 Knative 。同樣，你在任何 Knative 集群里面的服務(wù)都可以無縫遷移到另外一個 Knative 集群。如果你的服務(wù)是搭建在 Knative 之上，那么你的服務(wù)就可以像水一樣在各個云廠商流通，任何一個云廠商的 Kubernetes 搭建好 Knative 就能輕松地把你的服務(wù)部署起來。咱們透過下面這個支持列表可以看到 Knative 已經(jīng)被大量的廠商或平臺支持：

• Google 的 CloudRun 是基于 Knative 的
• IBM 公有云已經(jīng)支持 Knative
• 阿里云已經(jīng)支持 Knative
• Pivotal 的 Riff 是建立在 Knative 之上的 FaaS 系統(tǒng)
• OpenShift 的 Knative 支持
• Rancher RIO 是基于 Knative 的
• kubeflow 社區(qū)基于 Knative 的 KFServing，正在用 Knative 做 AI 相關(guān)的框架

云原生的力量就在于此，開放的標(biāo)準(zhǔn)得到了廣泛的支持。作為使用云的客戶，基于這種開放的標(biāo)準(zhǔn)其實就是始終保有和服務(wù)商議價的權(quán)利，哪里的服務(wù)好就到哪里去，否則就有可能會被一家鎖定。對于云廠商而言，通過開放的標(biāo)準(zhǔn)可以接入更多的客戶，而這個標(biāo)準(zhǔn)之下的具體實現(xiàn)，每家都會根據(jù)自身特點進(jìn)行支持，這也是云廠商的核心競爭力。

Knative 的典型應(yīng)用場景

介紹了這么多，接下來咱們就捋一捋 Knative 都適合在哪些場景中使用。

應(yīng)用 Serverless 編排場景

Knative Serving 從流量入手對應(yīng)用進(jìn)行 Serverless 編排。

首先 Knative 基于 Istio Gateway 來接管服務(wù)的流量，可以做到按百分比對流量進(jìn)行切分。切分的流量可以直接用于灰度發(fā)布，比如把按百分比切分的流量直接轉(zhuǎn)給一個 Revision，精準(zhǔn)地控制每一個 Revision 承接的流量百分比，從而達(dá)到精準(zhǔn)控制灰度版本對線上服務(wù)應(yīng)用的范圍。

Knative 的彈性策略是作用在每一個 Revision 之上的，不同的 Revision 根據(jù)“自己的節(jié)奏”獨自伸縮，實現(xiàn)了從流量到灰度灰度再到彈性這三者的完美結(jié)合，所有應(yīng)用彈性托管訴求都可以通過 Knative 來實現(xiàn)。下面這些場景非常適合使用 Knative 來解決：

• 比如托管微服務(wù)應(yīng)用
• 比如托管 Web 服務(wù)
• 比如托管 gRPC 服務(wù)

事件驅(qū)動

Knative 的 Eventing 提供了完整的事件模型，可以很容易地接入各個外部系統(tǒng)的事件。事件接入以后通過 CloudEvent 標(biāo)準(zhǔn)在內(nèi)部流轉(zhuǎn)，Broker/Trigger 機制給事件處理提供了非常好的方式。

這套完備的事件系統(tǒng)可以比較容易的實現(xiàn)事件驅(qū)動的服務(wù)，比如：

• IOT 場景
• 比如和各種云產(chǎn)品的事件對接，從而實現(xiàn)云產(chǎn)品狀態(tài)更新自動觸發(fā)一個服務(wù)等

基于 Tekton 的 Pipeline

基于 Tekton 構(gòu)建 CICD 系統(tǒng)等，比如：

• 當(dāng) gihub 有代碼提交以后自動觸發(fā)鏡像構(gòu)建、服務(wù)發(fā)布流程
• 當(dāng) docker 鏡像倉庫有鏡像提交的時候，自動對鏡像進(jìn)行測試以及發(fā)布成服務(wù)等

MicroPaaS

基于 Knative Servering 部署服務(wù)，你就無需手動操作 Kubernetes 資源，這樣可以大大降低使用 Kubernetes 的門檻。所以如果不是維護(hù) Kubernetes 系統(tǒng)、或者要基于 Kubernetes 做復(fù)雜的開發(fā)，就可以使用 Knative 來管理自己的服務(wù)，非常便捷。

客戶案例

阿里云 Knative 現(xiàn)在都有哪些典型的客戶案例？

Web 服務(wù)托管

Web 托管服務(wù)其實就是前面介紹的 MicroPaaS 類型的場景，客戶使用 Knative 是為了簡化使用 Kubernetes 的復(fù)雜度。即便不使用 Knative 的彈性也可以帶來應(yīng)用托管效率的提升。

應(yīng)用 Serverless 編排

• 微服務(wù)托管場景
• web 應(yīng)用托管和彈性
• 小程序、公眾號后臺
• 電商服務(wù)后臺

AI 服務(wù)托管

• 基于任務(wù)隊列的彈性伸縮
• 使用 ECI 做彈性，有效降低長期保有資源的成本

SaaS 服務(wù)托管

• SaaS 用戶提交代碼之后自動給用戶構(gòu)建鏡像
• SaaS 用戶自己推送了一個鏡像之后自動幫助用戶發(fā)布服務(wù)
• CMS 系統(tǒng) SaaS 提供商可以通過 Helm Chart 非常方便地給用戶部署一套全新的服務(wù)

SpringCloud 微服務(wù)托管

把 Knative Service 的地址注冊到注冊中心，通過 Knative 的能力實現(xiàn)微服務(wù)的流量切分、灰度發(fā)布和彈性。這樣 Knative 就給普通的微服務(wù)應(yīng)用賦予了 Serverless 能力。

構(gòu)建 CICD 系統(tǒng)

• 基于 git 代碼倉庫的自動構(gòu)建、服務(wù)發(fā)布的 CICD 系統(tǒng)
• 當(dāng) docker 鏡像倉庫有新鏡像的時候自動執(zhí)行測試或者服務(wù)發(fā)布

OSS 事件

• 當(dāng) OSS 中新增一個文件自動觸發(fā)機器學(xué)習(xí)任務(wù)的執(zhí)行，對圖片進(jìn)行分析、識別等
• 當(dāng) OSS 中新增一個視頻文件，自動觸發(fā)一個任務(wù)處理視頻，比如視頻內(nèi)容識別等

TableStore 事件

• Feed 流系統(tǒng)設(shè)計
• 社交信息發(fā)送通知等

Demo 演示

Demo 執(zhí)行的命令如下：

https://help.aliyun.com/document_detail/126413.html https://github.com/knative-sample/cloud-native-go-weather 縮容到零的場景 http://weather-web.default.live.kuberun.com/#/ https://tracing-analysis.console.aliyun.com/#/appList/cn-shenzhen registry.cn-hangzhou.aliyuncs.com/knative-sample/weather-detail:limit-v1 hey -z 60s -c 30 http://weather-web.default.live.kuberun.com/api/city/detail/010/2019-12-05 helm install ./chart --name live-weather --namespace live helm delete live-weather --purge

關(guān)注“阿里巴巴云原生”公眾號，回復(fù)關(guān)鍵詞“1205”即可觀看演示視頻。

歡迎加入釘釘交流群

Q & A

Q1：開發(fā)怎么遠(yuǎn)程調(diào)試 K8s 中的應(yīng)用？
A1：Kubernetes 底層首先是一個容器，那咱們就從容器談起。容器相對于宿主機來說其實只是把業(yè)務(wù)進(jìn)程限制在一個更合理的權(quán)限范圍內(nèi)，在調(diào)試容器里面的業(yè)務(wù)進(jìn)程時可以直接 docker exec 到容器內(nèi)。到了容器內(nèi)部就和一個 vm 沒有什么差別了。而 Kubernetes 的 Deployment 可以認(rèn)為是編排很多容器，每一個容器都可以通過 宿主機 docker exec 進(jìn)去。當(dāng)然也可以通過 Kubernetes 的方式 kubectl exec 到容器內(nèi)進(jìn)行調(diào)試。如果實在初期調(diào)試階段建議使用比較完整的 CentOS 或者 Ubuntu 鏡像，基礎(chǔ)鏡像內(nèi)要有一些基本的調(diào)試工具。摸索熟悉了之后可以使用精簡的基礎(chǔ)鏡像，這樣更經(jīng)濟(jì)。

Q2：Knative 的 build 和開發(fā)流程管理可以代替 jenkins 嗎？
A2：Knative 的 Build 現(xiàn)在是 Tekton 。Tekton 本身的定位不是替換 Jenkins，它的核心理念是建立在 Kubernetes 生態(tài)之上。比如 Pod 的執(zhí)行力度，每一個 Pod 內(nèi)可以包含很多容器，每一個容器是一個 step，這樣我們就可以使用不同的鏡像驅(qū)動容器，每一個容器內(nèi)部的環(huán)境都是可以完全自定義的。并且容器之間以及 Pod 之間共享資源都是通過 Kubernetes 的模式提供的。另外我們知道 CICD 系統(tǒng)一般都會被運維系統(tǒng)集成，在被集成的的場景中 Tekton 的優(yōu)勢是比較大的。Tekton 是可以通過 Kubernetes API 進(jìn)行操作的，而 Jenkins 的 API 以及設(shè)計理念都是需要單獨學(xué)習(xí)的，這些都是成本。核心還是在于 Kubernetes 這個生態(tài)比較強大，而未來的趨勢 Kubernetes 將是一個必備技能。在這個大環(huán)境下掌握 Tekton 的成本就更低，向前看 Tekton 正在成為主流。

Q3：Knative 編排和 K8s 應(yīng)用編排的區(qū)別及應(yīng)用場景?
A3：Kubernetes 的最大價值是把對 IaaS 資源的操作標(biāo)準(zhǔn)化了，比如無論是在 AWS 還是在阿里云上面使用計算、存儲、網(wǎng)絡(luò)等資源，都可以直接通過 Kubernetes 語義完成，不需要關(guān)系不同廠商底層差異化的實現(xiàn)。而 Knative 才是面向應(yīng)用的編排。Knative 對應(yīng)用的 Serverless 編排主要體現(xiàn)在：對流量、灰度策略以及彈性的管理，并且流量、灰度和彈性這三者是完美契合在一起的。從另一個角度來說 Knative 是建立在 Kubernetes 之上的，Knative 需要使用 Kubernetes 提供的對 IaaS 的標(biāo)準(zhǔn)化服務(wù)。這二者是上下層的依賴和被依賴的關(guān)系，不是競爭關(guān)系。

Q4：Knative 有哪些成功的行業(yè)應(yīng)用實踐？A4：在阿里云上面已經(jīng)有很多用戶在使用了。另外 Google 的 CloudRun 產(chǎn)品完全是建立在 Knative 之上的。

Q5：Knative 的現(xiàn)狀和預(yù)期達(dá)到的目的?
A5：Knative 現(xiàn)在已經(jīng)被眾多廠商開始支持了，Knative 的目標(biāo)是標(biāo)準(zhǔn)化應(yīng)用 Serverless 編排模型。比如：通過 Knative 對應(yīng)用進(jìn)行編排、通過 Knative 支撐上層 faas 系統(tǒng)實現(xiàn)。這里說的應(yīng)用其實不限于在線服務(wù)，很多 AI 任務(wù)也是通過 Knative 驅(qū)動的，比如分享中提到的 KFServing。

Q6：縮容時，怎么才能當(dāng) pod 內(nèi)的流量消耗完，再銷毀？
A6：Kubernetes 中 Pod 是可以設(shè)置 Prestop 的，Prestop 可以保證先卸載流量，然后再摘除服務(wù)。

Q7：在企業(yè)私有云環(huán)境部署knative會有哪些挑戰(zhàn)？
A7：只要是標(biāo)準(zhǔn)的 Kubernetes 集群之上就能部署 Knative，不過很多鏡像需要翻墻。

Q8：Istio 層面的管控和維護(hù)成本比較高，如 envoy 性能問題、網(wǎng)絡(luò)問題等，這部分工作是由云平臺負(fù)責(zé)的嗎？Knative 這邊有沒有相應(yīng)措施？A8：目前阿里云容器服務(wù) Kubernetes 集群控制臺可以通過 UI 管理 Istio 和 Knative，可以快速上手。控制臺也提供了很多便捷操作降低運維成本。Knative 主要依賴了 Istio 的 Gateway，Gateway 本身是可以橫向擴(kuò)展的，不會有太大影響。

Q9：容器的冷啟動問題如何解決，第一個流量豈不是延時很高?
A9：如果縮容到零以后，到一個請求的延時是會很高。第一個請求冷啟動的問題是一個公認(rèn)的業(yè)界難題，這也是各大云廠商在競相解決的問題。相比使用云的客戶而言，云廠商自己其實更迫切解決這個問題，敬請關(guān)注。

Q10：Knative 的組件本身怎么部署？如何保證 HA？
A10：Knative 是建立在 Kubernetes 之上的，Knative 組件其實就是 CRD 的 Controller。在 Kubernetes 中 Controller 是可以部署多個實例，通過搶鎖保證只有一個 Controller 可以執(zhí)行寫操作，HA 的問題容易解決。

“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)公眾號。”

總結(jié)

以上是生活随笔為你收集整理的Knative Serverless 之道：如何 0 运维、低成本实现应用托管？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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