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

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

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

通過本文您將了解到：

Knative 是如何讓普通的應用具備 Serverless 能力的？

為什么說 Knative 是云原生的應用 Serverless 編排引擎？

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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號。”

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。