TAP 文章系列-13 | 基於 Knative 的 TAP 雲原生執行時

當前CNCF主導的雲原生以及相應生態發展如火如荼，企業IT和研發部門都在花大力氣嘗試通過K8S進行微服務應用的部署、編排和生命週期的管理，進而解放開發和運維，使開發者真正聚焦在業務程式碼的設計開發和創新上。但是實際具體落地的過程中都受到了巨大挑戰。

首先是K8S的複雜性。開發和運維部署應用時，使用者至少深入學習和掌握下面幾個部分，而每個部分又會關聯引出更多的K8S知識點。

此外，還包括以下生產環境中實際相關的問題：

• K8S應用部署後怎麼訪問？找誰配DNS和負載均衡？
• 怎麼實現靈活的部署模式，比如藍綠、灰度、A/B測試、按微服務版本，進行比例限流等？
• 容量規劃總是估不準，只好估高點，多留點buffer，資源利用率過低會不會有問題？但如果估算的過低，到時不夠的話，擴容快不快？

因為以上的諸多問題，企業使用者通常在自行構建基於開源Kubernetes實現的容器平臺上碰到諸多繁瑣的配置和運維工作，並時常會因為手動操作帶來很多潛在的問題。

VMware推出第三代雲原生平臺Tanzu Application Platform – TAP，是面向企業級的PaaS平臺解決方案；而TAP的雲原生應用執行時抽象層 - Cloud Native Runtimes（CNR），能夠幫助提升應用開發者和應用運維者效率，有效地解決在本文中剛開始時提到的諸多環境配置和運維相關聯難題，通過自動化的平臺方式，能夠大大降低使用者的使用複雜度：

圖中紅色標註部分就是Cloud Native Runtimes。

作為TAP平臺執行時基礎層,當前版本是version1.2。其中Knative Runtime和K8S Jobs作為核心基礎已經生產就緒，Batch Runtime和Stream Runtime是路線圖中的規劃。CNR本身獨立釋出，並且內建包含在TAP的釋出包。Knative是CNR的核心之一，下面首先介紹一下無伺服器運算Serverless和Knative，以及Cloud Native Runtimes在此基礎上的整合和增強。

Serverless無服務運算和Knative

在大型軟體系統設計和規劃中，增加抽象層是其中一種經典方法。如下所示,虛擬化->容器->K8S->Serverless的抽象層的引入對業務、開發和運維提供積極的促進。

Serverless是一種架構理念，其核心思想是將提供服務資源的基礎設施抽象成各種服務，以API介面的方式供給使用者按需呼叫，真正做到按需伸縮。目前業界公認的無伺服器架構主要包含兩個方面， FaaS和BaaS-Backend as a Service:

1. 函式即服務（Function as a Service）

函式即服務，是一項基於事件驅動的函式託管計算服務。通過函式服務，開發者只需編寫業務函式程式碼並設定執行的條件，無需配置和管理伺服器等基礎設施。開發交付更加敏捷，資源利用更加高效。

1. 後端即服務（Backend as a Service）

BaaS的概念涵蓋範圍較廣，覆蓋了應用有可能依賴的所有第三方服務，如雲資料庫、物件儲存等服務。開發人員通過API整合所需的後端功能，不必管理虛擬機器或容器等基礎設施。BaaS服務大多有云服務商提供，目前常見的BaaS服務包括：資料庫管理,雲端儲存,使用者認證,推送通知,遠端更新,訊息佇列等。

傳統的 Serverless 方案優點很明顯，但平臺和服務均由雲廠商負責維護，使無伺服器架構的廠商繫結現象非常嚴重。目前存在以下問題：

• 缺乏統一標準。呈現碎片化，各家都有各自的實現。
• 廠商鎖定。比如使用 AWS Lambda 就必須配套使用 AWS 的 DB, S3 等產品。
• 應用遷移或多雲成本極高。

此時伴隨K8S的廣泛應用和探索,Knative受到國內外大廠關注，其定位是基於 K8S的 Serverless 解決方案，旨在標準化 Serverless，簡化學習成本。Knative目前已成為CNCF孵化專案，後續生態和前景必將更加廣闊。

Knative兩個關鍵元件：Serving（服務）和Eventing（事件）。

Serving（服務）：基於負載自動伸縮，包括在沒有負載時縮減到零。允許你為多個修訂版本（revision）應用建立流量策略，從而能夠通過 URL 輕鬆路由到目標應用程式。

Eventing（事件）：使得生產和消費事件變得容易。抽象出事件源，並允許操作人員使用自己選擇的訊息傳遞層。是事件驅動開發的一種實現。

Cloud Native Runtimes的核心功能和元件

Cloud Native Runtimes（CNR）的核心是Knative，並提供工具整合和能力擴充套件。它提供了一個Runtime執行時層，即支援使用者使用K8S Deployment和Service,也可以使用Knative Serving, Scale From/To Zero,Eventing和Streaming等。

如圖所示，

1) CNR包括核心Knative Serving、Eventing，並且繼續提供Streaming和Batch多種型別Runtime支援；

2）CNR與Contour，Avi和Tanzu Service Mesh有很多好的整合，提供高階Ingress的能力（預設安裝使用Contour作為Ingress Controller）；

3）CNR提供Eventing整合支援vSphere Events,AWS Events，RabbitMQ，Kafka。預設使用IMC(InMemoryChannel);

4）TAP中的CNR提供通過Carvel和TanzuBuildService整合做打包、部署；

5）最後，我們可以看到CNR底層是基於VMware TKG或者其它雲服務廠商的K8S發行版本。

我們一起回顧下Knative Serving和Eventing的主要能力：

1.Serving：目標是為 Kubernetes 提供擴充套件功能，用於部署和執行 Serverless 工作負載。Knative Servic管理Routes和Configuration,Route負責將流量根據需要指向Revision的例項。可縮放至零、請求驅動的計算執行環境。

Knative Serving 與Activator和Knative Pod Autoscaler共同完成自動擴縮、從零擴充套件和縮減到零等能力和控制。對於預熱、Graceful shutdown， window-size都有考慮和設計。

2.Eventing：提供用來使用和生成符合 CloudEvents 規範的事件的構建塊。它包括對來自事件源的資訊流的抽象，以及通過由可插拔髮布/訂閱代理服務提供支援的訊息傳遞通道實現交付解耦

Cloud Native Runtimes社群影響力和核心價值

Cloud Native Runtimes 是開源方案Knative的商業化和產品化實現

• VMware是Knative的主要創始成員之一，VMware 一直是主要的貢獻者
• VMware 研發團隊有專門的全職員工支援Knative
• Knative 社群的領導力

• Knative steering committee 的5名成員中的2位來自VMware
  • Brenda Chan and Ville Aikas

• Knative technical oversight committee 的5名成員中的2位來自VMware
  • Evan Anderson and Dave Protasowski

CNR核心價值主要從開發者和運維管理角度體現便捷與高效

開發角度：大幅提升開發和部署業務邏輯程式碼的效率

 

通過K8S進行應用開發者需要學習掌握並管理：	通過CNR/Knative進行應用開發者需要學習掌握並管理:
Pods Deployment Process Rollout Progress Labels and selectors Service (networking model) Ingress	Pods CNR/Knative Service

運維和管理角度：CNR優化運維和Admin的體驗

• 通過請求驅動的自動擴縮容來管理和控制基礎設施成本；
• 按照軟體程式的程式碼版本來劃分流量的測試部署；
• 通過Carvel簡化部署；
• 整合Ingress(Contour/Avi/Tanzu service mesh)和 Eventing(RabbitMQ,kafka或AWS Events,vSphere Events)
• 提供企業級的7x24技術支援保證

Cloud Native Runtimes的關鍵場景

1.自動釋出URL，CNR自動完成DNS和負載均衡的配置

TAP平臺的雲原生執行時CNR通過Knative Runtime自動生成Route，直接通過域名訪問，可以在介面監控應用負載的執行時資源物件的狀態資訊。自動完成Source2URL，開發者無需管理K8S中Ingress/Service/Deployment/Label等資源物件。

通過TAP GUI檢視資源使用和資源物件狀態,可以從應用層面理解從應用->Knative資源物件->K8S資源物件，各個層面看到關聯關係。

2.實現靈活的容器應用部署模式，並且方便的提供流量分配和控制

TAP平臺CNR包括K8S Runtime和Knative Runtime等支援，無論是微服務還是函式應用，或事件驅動架構的應用，都能部署。您可以:

• 通過K8S的deployment yaml直接定義和部署應用；
• 也可以通過Knative service建立應用服務；
• 亦或是TAP的workload去建立應用

而且利用Knative高層抽象比如service和revision就能實現零停機部署；多版本部署；按比例分配流量等部署和流量相關場景。下圖中可見設定流量比例和執行結果。

3.基於資源和實際請求負載演算法的自動擴縮容

CNR除了簡單的通過資源使用情況CPU/MEM等進行擴縮容，更多是通過請求的負載壓力演算法進行自動擴縮容。包括：從零擴容（Scale From Zero）；縮容到零（Scale To Zero）；設定服務擴縮容的上限和下限引數（比如配置Pod數量最少為1個,min=1，max=5）；Auto-Scaling等。並可以通過CNR命令列或者TAP介面應用執行詳細頁面進行觀測。

下圖示左側用siege或hey工具持續以200個併發來連續傳送請求，圖示右側視窗可以看到在tap-tanzu-java-web-app-0006這個應用的Deployment中的Pod數量會根據流量壓力增加到1,2,3個Pods。整個過程完全根據流量和Pod狀態通過演算法，進行自動排程擴縮容；當流量傳送停止，Pod數量會從3，2，1逐漸降低直至為零。

結論

VMware Cloud Native Runtimes是Tanzu產品組合中的重要基礎軟體，是TAP產品的核心雲原生應用執行時基礎。特點總結如下幾個方面：

展望與發展

Cloud Native Runtimes將伴隨著K8S、Knative和TAP演進和發展,不斷滿足企業環境下雲原生應用的構建、執行和管理需求。

• 不斷完善對於TAP的支援和整合，更好的融合buildservice能力；
• 提供和完善Streaming,Batch等Runtime；
• 更多型別Event Sources支援，比如Azure，GCP Event Sources；
• 結合TAP平臺支援Streaming Supply Chain,Batch Supply Chain；
• 基於Tanzu Service Mesh的CNR Routes支援；

敬請期待和試用最新版本CNR！

參考

1: Knative community, http://knative.dev/docs/

2:Knative in Action, JACQUES CHESTER

3: Gartner,Innovation Insight for Internal Developer Portals http://tanzu.vmware.com/content/analyst-reports/innovation-insight-for-internal-developer-portals 

4: Cloud Native Runtime Document

http://docs.vmware.com/en/Cloud-Native-Runtimes-for-VMware-Tanzu/1.2/tanzu-cloud-native-runtimes/GUID-cnr-overview.html

5: 13 challenges creating an open, scalable, and secure serverless platform

6: Proposal for Autoscaling of Knative Eventing

7: http://tanzu.vmware.com/content/blog/join-cloud-native-runtimes-vmware-tanzu-serverless-public-beta

作者：劉鵬

VMware資深雲原生應用架構師，20年軟體開發設計和產品管理經驗。在VMware/Pivotal之前曾就職於IBM中國實驗室、Oracle、大唐電信和Ericsson等國內外IT企業，從事企業級平臺和雲端計算相關軟體的系統架構、產品管理和研發等工作。具有豐富的電信和銀行、交通等行業經驗。擁有Spring Core professional, Kubernetes CKA, AWS Solution Architect, CloudFoundry和軟體架構師認證，目前主要專注企業級PaaS和容器雲平臺產品及雲原生微服務應用架構設計。

 

來源｜公眾號：VMwareTanzu雲原生