Knative Serverless 之道：如何 0 運維、低成本實現應用託管？

時間 2019-12-31

標籤 knative serverless 之道如何低成本實現應用託管简体版

原文原文鏈接

導讀：Serverless 無疑是當前最熱的雲原生話題，那麼做爲業務的開發人員或者運維人員我們應該怎麼看待這個事情？雲原生和 Serverless 到底有什麼關係？經過本次分享我們將逐一揭開這些神祕的面紗。

經過本文您將瞭解到：html

Knative 是如何讓普通的應用具有 Serverless 能力的？
爲何說 Knative 是雲原生的應用 Serverless 編排引擎？
Knative 爲何是由 Tekton 、Eventing 和 Serving 三個模塊組成，以及這三個模塊的協做方式。

本文共有四部份內容：首先我們一塊兒來看一下雲的核心驅動力是什麼，接着從這個核心驅動力出發看一下雲原生應用是什麼樣子。而後我們再一塊兒來看看 Knative 到底給應用的雲原生化帶來了什麼價值，最後我們經過一個 Demo 親身感覺一下 Knative 帶來的這些能力。git

雲的核心驅動力

在討論雲原生以前咱們先來思考一下：爲何企業要上雲、爲何技術人員要學習面向雲的編程思惟以及我們應該怎麼看待雲這件事兒。github

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

社會分工

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

我小時候在內蒙的農村長大，你們都知道，內蒙很大。村裏每戶人家都有一個大園子，夏天的時候家家戶戶都會在園子裏種植各類蔬菜，如西紅柿、黃瓜、茄子、辣椒等；但到了冬天，因爲天氣很冷，根本見不到新鮮的蔬菜，你們吃的都是鹹菜、酸菜，或者是秋天晾曬的一些乾菜。咱們能夠發現：一個地域很是容易受到季節的影響，雖然夏天能夠種植各類蔬菜，可是到了冬天就什麼都沒有了。可是如今就不一樣了，全國各地隨處都能很是容易地買到新鮮蔬菜，這實際上是社會分工的結果、是不一樣地域、不一樣角色之間經過市場相互協做的成果。數據庫

如今由於有專業的人在作這些事情，因此咱們大多數人都無需勞心蔬菜是怎麼種植的。而咱們工程師所作的和計算機打交道的事情也能經過其餘的渠道反過來幫助那些種菜的人。編程

分工提升效率，這是現代經濟學之父亞當斯密 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 相關的框架

雲原生的力量就在於此，開放的標準獲得了普遍的支持。做爲使用雲的客戶，基於這種開放的標準其實就是始終保有和服務商議價的權利，哪裏的服務好就到哪裏去，不然就有可能會被一家鎖定。對於雲廠商而言，經過開放的標準能夠接入更多的客戶，而這個標準之下的具體實現，每家都會根據自身特色進行支持，這也是雲廠商的核心競爭力。