Knative Serverless 之道：如何 0 運維、低成本實作應用托管？雲的核心驅動力雲原生應用Knative 應運而生Demo 示範Q & A

作者 | 牛秋霖（冬島）  阿裡雲容器平台技術專家

關注“阿裡巴巴雲原生”公衆号，回複關鍵詞“1205”即可觀看 Knative-Demo 示範視訊。

導讀：Serverless 無疑是目前最熱的雲原生話題，那麼作為業務的開發人員或者運維人員咱們應該怎麼看待這個事情？雲原生和 Serverless 到底有什麼關系？通過本次分享咱們将逐一揭開這些神秘的面紗。

通過本文您将了解到：

1. Knative 是如何讓普通的應用具備 Serverless 能力的？
2. 為什麼說 Knative 是雲原生的應用 Serverless 編排引擎？
3. Knative 為什麼是由 Tekton 、Eventing 和 Serving 三個子產品組成，以及這三個子產品的協作方式。

本文共有四部分内容：首先咱們一起來看一下雲的核心驅動力是什麼，接着從這個核心驅動力出發看一下雲原生應用是什麼樣子。然後咱們再一起來看看 Knative 到底給應用的雲原生化帶來了什麼價值，最後咱們通過一個 Demo 親身感受一下 Knative 帶來的這些能力。

雲的核心驅動力

在讨論雲原生之前我們先來思考一下：為什麼企業要上雲、為什麼技術人員要學習面向雲的程式設計思維以及咱們應該怎麼看待雲這件事兒。

咱們先來剖析一下發生這些事情的核心驅動力，然後通過這個核心驅動力出發看看整個雲原生技術棧是什麼樣子。

社會分工

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

我小時候在内蒙的農村長大，大家都知道，内蒙很大。村裡每戶人家都有一個大園子，夏天的時候家家戶戶都會在園子裡種植各種蔬菜，如蕃茄、黃瓜、茄子、辣椒等；但到了冬天，由于天氣很冷，根本見不到新鮮的蔬菜，大家吃的都是鹹菜、酸菜，或者是秋天晾曬的一些幹菜。我們可以發現：一個地域非常容易受到季節的影響，雖然夏天可以種植各種蔬菜，但是到了冬天就什麼都沒有了。但是現在就不同了，全國各地随處都能非常容易地買到新鮮蔬菜，這其實是社會分工的結果、是不同地域、不同角色之間通過市場互相協作的成果。

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

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

應用上雲

接着咱們再來看看一個應用都是由哪些部分構成的。

應用要提供服務首先要有計算、存儲和網絡資源才能把程序跑起來。當然這些也僅僅是把程序跑起來，如果要承接具體的業務還需要依賴資料庫等服務；如果要做分布式架構還需要做微服務拆分，這時候就需要緩存、注冊中心、消息各種中間件的服務。

以上的情況都是程式已經存在，如何把程式跑起來承接業務的部分。還有一部分是如何把代碼變成可啟動的程式，這就是 CICD 部分了。從代碼到應用啟動再到應用依賴的周邊系統支撐都說完了，還有一部分就是日常運維相關的：

• 比如日志收集、分析
• 比如監控和告警

雖然我們本來隻是想要寫一個應用，來為業務提供服務。但是應用周邊的這些支撐系統比這個應用自身的消耗還要高上很多。這其實不是我們期望的結果，讓業務團隊更多的聚焦在業務邏輯本身，而不是周邊的這些系統上，這才是我們希望看到的。

實際上有一定規模的公司，内部的組織架構基本也都是由一個基礎平台團隊和多個業務團隊構成的，基礎平台團隊負責提供這些應用需要的公共能力支撐，業務團隊更聚焦在業務上，直接使用基礎平台團隊的能力即可。這其實就是社會分工在 IT 組織中的展現，專業的人做專業的事兒，分工提升效率。

現在我們再回顧一下剛才吃火鍋的例子。

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

那麼對于一家企業而言，也是一樣的。雖然每個企業都有自己的基礎平台團隊，但是由于規模或者資金投入等原因，不可能提供像雲這麼豐富的平台支撐。如果有，那一定也是一個雲廠商。是以對于業務來說，把所有和應用相關的周邊系統都使用雲的初始設施搭建，把這些周邊系統承包給雲廠商才是高效率的做法。我了解為這就是雲原生出現的背景。

分工提高效率這是大家使用雲的根本動力。雲原生理念是在各大企業上雲的過程中逐漸形成和完善的。這套理念是協調所有參與方對服務上雲逐漸形成的統一标準，這個統一的标準可以很好地幫助企業上雲、幫助雲廠商釋放雲的能力。從雲的客戶角度來講，這個統一标準就是避免雲廠商鎖定。比如 Kubernetes 就是一個非常好的統一共識，因為所有雲平台都支援 Kubernetes。

那麼這個标準的價值是什麼呢？為什麼雲廠商和上雲的企業都積極參與這個标準的“制定”呢？這其實是一個互利互惠的結果。在具體談論這個标準的作用之前，我們先來聊聊兩種資源配置設定模式的差别。

排隊（先到先得）

這部分咱們以就醫為例進行說明。

去醫院看病需要提前挂号，醫生的号源這是一種先到先得的資源配置設定方式。特别是在北上廣這些大城市，好醫生的号源更是一号難求。如果想保證一定要拿到某個醫生的就診号，就要保證比别人都更早地到醫院排隊，提前排隊可以優先拿到就診号。我們現在來分析一下，提前排隊的人所付出的努力都有什麼價值。

• 對于排隊的當事人：當事人付出的努力對于自己是有意義的，自己拿到了就診号，得到了回報；
• 對于其他的排隊者而言，是沒有任何好處的。早來的人拿到了就診号，這就給别的競争号源的人發出了一個信号——來的越早就越有可能得到号源。這有可能引發更多人更早的前來排隊，這是一個惡性循環；
• 對于醫生來說，沒有任何意義，誰來看病都是一樣，誰得到這個号對醫生來說差别不大。很多時候甚至患者要求加号，但醫生其實是不願意的，因為每增加一個号源就意味着醫生要付出一點兒休息的時間。對于醫生而言，多付出的休息時間是不能換來更多報酬的，因為這是一個先到先得的排隊秩序規則，每一個号源的價格都是一樣的。

有沒有發現在排隊的過程中所做出的付出隻對排隊的當事人是有意義的，對于醫生以及其他排隊者都沒有任何意義，甚至會帶來惡性競争，造成社會資源的巨大浪費。在排隊的過程中，大量的資源都白白地流失，沒有給社會帶來任何價值。

市場經濟

這部分我們以購買雲伺服器 ECS 為例進行說明。

假設目前阿裡雲的 ECS 是成本效益最高的，大家上雲都優先選擇使用阿裡雲的 ECS，那麼如果出現供不應求的情況就可能會導緻 ECS 價格上漲，而價格上漲就會導緻更多的雲廠商供應 ECS ，最終導緻價格又回落下來。我們分析一下在這個過程中購買 ECS 的人和提供 ECS 的雲廠商之間的關系：

• 我們發現大量客戶選購 ECS 這件事情本身對于上雲的客戶是有益無害的，因為大量的需求會導緻雲廠商做更多的供應，價格不可能持續高攀。是以 ECS 需求的競争者之間其實不是零和博弈，而是一個互相合作的關系。大家一起把餅做大，就讓整個供應鍊更穩定、便宜。就好比我買蘋果手機，你也買蘋果手機，但是咱倆不是競争關系，而且買的人越多，蘋果手機的品質就會越來越好；
• 大量的 ECS 需求會促使 ECS 技術的成熟。對于 ECS 的提供者雲廠商而言，越多的人購買自己的服務就越好，所有的客戶和雲廠商之間都是互相促進的關系。

市場經濟這種基于價格的自由交易能夠非常高效地促進大家的合作，任何一方的努力對于其他的參與者而言都是有價值的。和醫院排隊中先到的人付出的努力隻對自己産生價值相比較，市場經濟的自由交易方式中，每一方的付出都讓整個系統得到了優化，這是社會資源合理利用、合理配置設定的一種非常好的方式。

是不是感覺扯遠了，這和雲計算有什麼關系？我們繼續來剖析一下市場經濟，就可以看到和雲計算的密切關系了。

我們先來看一下這個場景：如果雲廠商 A 提供的服務成本效益很高，但是有一天雲廠商 B 提供了成本效益更高的服務，客戶會不會立即把服務遷移到雲廠商 B 上去？答案是客戶想要遷移，但是比較難遷移。因為每一個雲廠商提供的服務标準都不太一樣，服務遷移的過程需要适配大量差異化的底層基礎設施，這給遷移帶來了巨大的成本，甚至抵消了雲廠商 B 提供的高成本效益，是以平常比較少見到這種遷移。

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

如果把客戶要在雲上托管的應用比喻成水的話，那麼雲服務的價格就是海拔的高度。哪裡海拔低，水就很自然的流到哪裡去。無限降低遷移的成本，對于客戶和雲廠商來說都是非常有價值的一件事情。雲原生旨在以标準化雲服務的提供方式銜接雲廠商和客戶。這種方式對于客戶而言降低了上雲和跨雲遷移的成本，讓客戶始終保有和雲廠商議價的能力；對雲廠商而言，因為客戶跨雲遷移的成本低，是以隻要能提供成本效益更高的雲服務，就能很容易的聚集大量使用者。

雲原生是在不斷促進整個系統的良性循環：既能讓客戶始終保有選擇的能力，又能讓優秀的雲廠商快速服務更多的客戶。如果客戶的業務服務能像水一樣低成本在不同雲廠商之間流通，那麼雲廠商提供的服務就能像貨币一樣在客戶之間流通。這是一個多赢的局面。

雲原生應用

說完雲原生這個理念，我們來看一下雲原生應用，以及在雲原生的這個大背景下，如何看待傳統的應用架構？

雲上基礎設施

無論是雲上的應用，還是雲下的應用，其實依賴的核心要素都沒有變，隻是這些核心要素的提供形式發生了變化。

如上圖所示，共有 7 個核心要素。這 7 個要素中日常運維這一塊其實不是強依賴的，雖然它對業務的穩定性影響極大，但是這并不是業務跑起來的核心鍊路，沒有這些業務也能跑，而其它的幾塊都是核心鍊路。那麼我們就來看一下在雲原生架構下，這些核心鍊路的要素都處于什麼位置？然後剖析一下雲原生應用的基本範式。

雲原生技術棧

我們先來看看最右邊的中間件這一塊，裡面有資料庫、Redis 以及消息中間件元件。而這一塊其實是應用代碼裡面直接調用的，并且這裡包含的所有能力都有标準的協定，比如無論是使用 SQL Server 還是使用 MySQL，我們程式裡都可以使用 SQL 規範進行操作。這部分其實早就被标準化了。 

如圖所示，計算、存儲和網絡這三個核心要素已經被 Kubernetes 層統一了。很多雲服務已經實作了計算、存儲和網絡資源的無伺服器化，比如阿裡雲的 ECI 和 ASK(Aliyun Serverless Kubernetes)。那麼還有兩塊 CICD 和應用托管沒有标準化，這就是應用編排這一層需要标準化的事情。Serverless 其實不單單是無伺服器，還包括應用本身的編排，這也是應用編排這一層的價值所在。

雲原生應用 Serverless 編排

Serverless Kubernetes 已經提供了 Pod 的無伺服器支援，而應用層想要用好這個能力其實還有很多事情需要處理。

• 彈性：
  • 縮容到零
  • 突發流量
• 灰階釋出
  • 如何實作灰階釋出
  • 灰階釋出和彈性的關系
• 流量管理
  • 灰階釋出的時候如何在 v1 和 v2 之間動态調整流量比例
  • 流量管理和彈性是怎樣一個關系
  • 當有突發流量的時候如何和彈性配合，做到突發請求不丢失

我們發現雖然基礎資源可以動态申請，但是應用如果要做到實時彈性、按需配置設定和按量付費的能力還是需要有一層編排系統來完成應用和 Kubernetes 的适配。這個适配不單單要負責彈性，還要有能力同時管理流量和灰階釋出。

Knative 應運而生

上文中的内容就是 Knative 要解決的問題，這也是 Knative 出現的背景。接下來咱們來看看 Knative 。

Knative 是什麼

我們先看看官方給出的定義：“基于 Kubernetes 平台，用于建構、部署和管理現代 Serverless 工作負載”。Knative 就是基于 Kubernetes 的應用 Serverless 編排系統。實際上 Knative 包含的不單單是 Workload，它還有 Kubernetes 原生的流程編排引擎和完備的事件系統。

前面提到 Kubernetes 實作了計算、存儲和網絡的标準化，而 Knative 目标基于 Kubernetes 提供了應用 Serverless 工作負載編排的标準化。

Knative 核心子產品

Knative 由三個核心子產品構成：Tekton、Eventing 和 Serving。

• Tekton 是 Kubernetes 原生的流程編排架構，主要用于建構 CICD 系統；
• Eventing 主要負責事件處理功能，可以接入外部系統的事件，事件接入以後進行一系列的流程處理以及觸發 Serving 消費事件；
• Serving 是應用運作工作負載的核心管理子產品，主要負責流量排程、彈性以及灰階釋出等職責。

Tekton

Tekton 是一套 Kubernetes 原生的流程編排架構，主要用于建構 CICD 系統。比如從源碼編譯成鏡像，以及對鏡像裡的服務進行測試、把鏡像釋出成應用等一系列的操作都可以基于 Tekton 完成。

Tekton 裡面基本的執行單元是 Task。>

• Task 裡面可以包含多個順序執行的 Step。一個 Task 最終就是一個 Pod，裡面的每一個 Step 最終執行的時候就是一個 Container 。每送出一個 TaskRun CRD 到 Kubernetes 就會觸發一次 Task 的執行；
• Pipeline 可以編排多個 Task，Pipeline 中的 Task 是可以設定依賴關系。Pipeline 會根據依賴關系生成一個有向無環圖，然後生成的根據有向無環圖并發或者串行執行一系列的 Task。每送出一個 PipelineRun CRD 就會觸發 Pipeline 的一次執行；
• PipelineResource 代表 Pipeline 使用或者生成的資源，比如：github 代碼倉庫、依賴或者使用的鏡像等等；
• Tekton 是 Kubernetes 原生的實作，是以資源鑒權的秘鑰等資訊都可以通過 Kubernetes 的 Secret 進行管理。

Eventing

Eventing 子產品基于 CloudEvent 标準實作了一系列的事件處理機制。Eventing 子產品的核心能力分成四大塊。

• 外部事件接入

Eventing 有很強的擴充機制，可以接入任何外部事件源的事件，比如 github 裡面的 commit、pull request 等事件；Kubernetes 裡面的事件；消息系統裡面的消息；以及 OSS、表格存儲、Redis 等系統的事件。

• CloudEvent 标準

Eventing 接入外部事件以後會轉換成 CloudEvent 格式，事件在内部的流轉都是通過 CloudEvent  事件标準完成的。

• 事件在内部的處理

Eventing 子產品引入的 Broker 、Trigger 模型，不僅将事件複雜的處理實作給使用者屏蔽起來，更提供了豐富的事件訂閱、過濾機制。

• 事件處理事務管理

Eventing 基于可靠的消息系統，可以對事件進行事務管理。如果事件消費失敗可以進行重試或者重新分發等操作。

Serving

Serving 核心的 CRD 就是 Service，Knative Controller 通過 Service 的配置自動操作 Kubernetes 的 Ingress、K8s Service 和 Deployment 進而實作簡化應用管理的目标。

Knative Service 對應一個叫做 Configuration 的資源，每次 Service 變化如果需要建立新的 Workload 就更新 Configuration，然後每次 Configuration 更新都會建立一個唯一的 Revision，Revision 可以認為是 Configuration 的版本管理機制。理論上 Revision 建立完以後是不會修改的，不同的 Revision 一般用于灰階釋出。

Route 是 Knative 管理流量的核心邏輯，Knative 是建立在 Istio 之後的，Knative  Route Controller 通過 Route 的配置自動生成 Istio 的 VirtualService 資源，進而實作了流量的管理。

Knative  Serving 對應用 Workload 的 Serverless 編排是從流量開始的。

流量首先達到 Knative 的 Gateway，Gateway 根據 Route 的配置自動把流量根據百分比拆分到不同的 Revision 上，然後每一個 Revision 都有一個自己獨立的彈性政策。當過來的流量請求變多的時候目前 Revision 就開始自動擴容。每一個 Revision 的擴容政策都是獨立的，互相不影響。

基于流量百分比對不同的 Revision 進行灰階，每一個 Revision 都有一個自己獨立的彈性政策。Knative Serving 通過對流量的控制實作了流量管理、彈性和灰階三者的完美結合。

Knative 的雲原生特性

Kubernetes 是業界公認的雲原生作業系統，作為雲原生的 Serverless 編排引擎 Knative 當然是相容 Kubernetes API 的。

Knative 本身就是開源的，你可以在任何 Kubernetes 叢集上面部署一套 Knative 。同樣，你在任何 Knative 叢集裡面的服務都可以無縫遷移到另外一個 Knative 叢集。如果你的服務是搭建在 Knative 之上，那麼你的服務就可以像水一樣在各個雲廠商流通，任何一個雲廠商的 Kubernetes 搭建好 Knative 就能輕松地把你的服務部署起來。咱們透過下面這個支援清單可以看到 Knative 已經被大量的廠商或平台支援：

• Google 的 CloudRun 是基于 Knative 的
• IBM 公有雲已經支援 Knative
• 阿裡雲已經支援 Knative
• Pivotal 的 Riff 是建立在 Knative 之上的 FaaS 系統
• OpenShift 的 Knative 支援
• Rancher RIO 是基于 Knative 的
• kubeflow 社群基于 Knative 的 KFServing ，正在用 Knative 做 AI 相關的架構

雲原生的力量就在于此，開放的标準得到了廣泛的支援。作為使用雲的客戶，基于這種開放的标準其實就是始終保有和服務商議價的權利，哪裡的服務好就到哪裡去，否則就有可能會被一家鎖定。對于雲廠商而言，通過開放的标準可以接入更多的客戶，而這個标準之下的具體實作，每家都會根據自身特點進行支援，這也是雲廠商的核心競争力。

Knative 的典型應用場景

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

應用 Serverless 編排場景 

Knative Serving 從流量入手對應用進行 Serverless 編排。

首先 Knative 基于 Istio Gateway 來接管服務的流量，可以做到按百分比對流量進行切分。切分的流量可以直接用于灰階釋出，比如把按百分比切分的流量直接轉給一個 Revision，精準地控制每一個 Revision 承接的流量百分比，進而達到精準控制灰階版本對線上服務應用的範圍。

Knative 的彈性政策是作用在每一個 Revision 之上的，不同的 Revision 根據“自己的節奏”獨自伸縮，實作了從流量到灰階灰階再到彈性這三者的完美結合，所有應用彈性托管訴求都可以通過 Knative 來實作。下面這些場景非常适合使用 Knative 來解決：

• 比如托管微服務應用
• 比如托管 Web 服務
• 比如托管 gRPC 服務

事件驅動

Knative 的 Eventing 提供了完整的事件模型，可以很容易地接入各個外部系統的事件。事件接入以後通過 CloudEvent 标準在内部流轉，Broker/Trigger 機制給事件處理提供了非常好的方式。

這套完備的事件系統可以比較容易的實作事件驅動的服務，比如：

• IOT 場景
• 比如和各種雲産品的事件對接，進而實作雲産品狀态更新自動觸發一個服務等

基于 Tekton 的 Pipeline

基于 Tekton 建構 CICD 系統等，比如：

• 當 gihub 有代碼送出以後自動觸發鏡像建構、服務釋出流程
• 當 docker 鏡像倉庫有鏡像送出的時候，自動對鏡像進行測試以及釋出成服務等

MicroPaaS

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

客戶案例

阿裡雲 Knative 現在都有哪些典型的客戶案例？

Web 服務托管

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

應用 Serverless 編排

• 微服務托管場景
• web 應用托管和彈性
• 小程式、公衆号背景
• 電商服務背景

AI 服務托管

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

SaaS 服務托管

• SaaS 使用者送出代碼之後自動給使用者建構鏡像
• SaaS 使用者自己推送了一個鏡像之後自動幫助使用者釋出服務
• CMS 系統 SaaS 提供商可以通過 Helm Chart 非常友善地給使用者部署一套全新的服務

SpringCloud 微服務托管

把 Knative Service 的位址注冊到注冊中心，通過 Knative 的能力實作微服務的流量切分、灰階釋出和彈性。這樣 Knative 就給普通的微服務應用賦予了 Serverless 能力。

建構 CICD 系統

• 基于 git 代碼倉庫的自動建構、服務釋出的 CICD 系統
• 當 docker 鏡像倉庫有新鏡像的時候自動執行測試或者服務釋出

OSS 事件

• 當 OSS 中新增一個檔案自動觸發機器學習任務的執行，對圖檔進行分析、識别等
• 當 OSS 中新增一個視訊檔案，自動觸發一個任務處理視訊，比如視訊内容識别等

TableStore 事件

• Feed 流系統設計
• 社交資訊發送通知等

Demo 示範

Demo 執行的指令如下：

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            

關注“阿裡巴巴雲原生”公衆号，回複關鍵詞“1205”即可觀看示範視訊。

歡迎加入釘釘交流群

Q & A

Q1：開發怎麼遠端調試 K8s 中的應用？

A1：Kubernetes 底層首先是一個容器，那咱們就從容器談起。容器相對于主控端來說其實隻是把業務程序限制在一個更合理的權限範圍内，在調試容器裡面的業務程序時可以直接 docker exec 到容器内。到了容器内部就和一個 vm 沒有什麼差别了。而 Kubernetes 的 Deployment 可以認為是編排很多容器，每一個容器都可以通過 主控端 docker exec 進去。當然也可以通過 Kubernetes 的方式 kubectl exec 到容器内進行調試。如果實在初期調試階段建議使用比較完整的 CentOS 或者 Ubuntu 鏡像，基礎鏡像内要有一些基本的調試工具。摸索熟悉了之後可以使用精簡的基礎鏡像，這樣更經濟。

Q2：Knative 的 build 和開發流程管理可以代替 jenkins 嗎？

A2：Knative 的 Build 現在是 Tekton 。Tekton 本身的定位不是替換 Jenkins，它的核心理念是建立在 Kubernetes 生态之上。比如 Pod 的執行力度，每一個 Pod 内可以包含很多容器，每一個容器是一個 step，這樣我們就可以使用不同的鏡像驅動容器，每一個容器内部的環境都是可以完全自定義的。并且容器之間以及 Pod 之間共享資源都是通過 Kubernetes 的模式提供的。另外我們知道 CICD 系統一般都會被運維系統內建，在被內建的的場景中 Tekton 的優勢是比較大的。Tekton 是可以通過 Kubernetes API 進行操作的，而 Jenkins 的 API 以及設計理念都是需要單獨學習的，這些都是成本。核心還是在于 Kubernetes 這個生态比較強大，而未來的趨勢 Kubernetes 将是一個必備技能。在這個大環境下掌握 Tekton 的成本就更低，向前看 Tekton 正在成為主流。

Q3：Knative 編排和 K8s 應用編排的差別及應用場景?

A3：Kubernetes 的最大價值是把對 IaaS 資源的操作标準化了，比如無論是在 AWS 還是在阿裡雲上面使用計算、存儲、網絡等資源，都可以直接通過 Kubernetes 語義完成，不需要關系不同廠商底層差異化的實作。而 Knative 才是面向應用的編排。Knative 對應用的 Serverless 編排主要展現在：對流量、灰階政策以及彈性的管理，并且流量、灰階和彈性這三者是完美契合在一起的。從另一個角度來說 Knative 是建立在 Kubernetes 之上的，Knative 需要使用 Kubernetes 提供的對 IaaS 的标準化服務。這二者是上下層的依賴和被依賴的關系，不是競争關系。

Q4：Knative 有哪些成功的行業應用實踐？A4：在阿裡雲上面已經有很多使用者在使用了。另外 Google 的 CloudRun 産品完全是建立在 Knative 之上的。

Q5：Knative 的現狀和預期達到的目的?

A5：Knative 現在已經被衆多廠商開始支援了，Knative 的目标是标準化應用 Serverless 編排模型。比如：通過 Knative 對應用進行編排、通過 Knative 支撐上層 faas 系統實作。這裡說的應用其實不限于線上服務，很多 AI 任務也是通過 Knative 驅動的，比如分享中提到的 KFServing。

Q6：縮容時，怎麼才能當 pod 内的流量消耗完，再銷毀？

A6：Kubernetes 中 Pod 是可以設定 Prestop 的，Prestop 可以保證先解除安裝流量，然後再摘除服務。

Q7：在企業私有雲環境部署knative會有哪些挑戰？

A7：隻要是标準的 Kubernetes 叢集之上就能部署 Knative。

Q8：Istio 層面的管控和維護成本比較高，如 envoy 性能問題、網絡問題等，這部分工作是由雲平台負責的嗎？Knative 這邊有沒有相應措施？A8：目前阿裡雲容器服務 Kubernetes 叢集控制台可以通過 UI 管理 Istio 和 Knative，可以快速上手。控制台也提供了很多便捷操作降低運維成本。Knative 主要依賴了 Istio 的 Gateway，Gateway 本身是可以橫向擴充的，不會有太大影響。

Q9：容器的冷啟動問題如何解決，第一個流量豈不是延時很高?

A9：如果縮容到零以後，到一個請求的延時是會很高。第一個請求冷啟動的問題是一個公認的業界難題，這也是各大雲廠商在競相解決的問題。相比使用雲的客戶而言，雲廠商自己其實更迫切解決這個問題，敬請關注。

Q10：Knative 的元件本身怎麼部署？如何保證 HA？

A10：Knative 是建立在 Kubernetes 之上的，Knative 元件其實就是 CRD 的 Controller。在 Kubernetes 中 Controller 是可以部署多個執行個體，通過搶鎖保證隻有一個 Controller 可以執行寫操作，HA 的問題容易解決。

“ 阿裡巴巴雲原生 微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”