基於 K8s 作應用發佈的工具那麼多, 阿里爲啥選擇灰姑娘般的 Tekton ？

導讀：近年來，愈來愈多專門給 Kubernetes 作應用發佈的工具開始繽紛呈現，幫助你們管理和發佈不斷增多的 Kubernetes 應用。在作技術選型的時候，咱們須要給業務選擇一個最好的工具、最穩的底座。那麼又該如何比較和衡量這些工具呢？本篇文章中阿里雲技術專家鄧洪超將會和你們分享本身獨特的體驗，幫助讀者初步瞭解 Tekton 項目。

背景

近年來，伴隨着雲原生社區 (CNCF Community) 的迅猛發展，愈來愈多的應用跑在了 K8s 上。慢慢地，你們的關注點也逐漸從資源層轉移到應用層。一方面，咱們看到在有愈來愈多新的 K8s Operators 出現，用來自動化應用的部署和運維。另外一方面，隨着各路大型雲廠商入場，K8s 服務之後就會像家裏的水和電同樣爲所欲爲可用，本身再去動手搭建已經沒有了意義。因而人們提出了「K8s 將會消失」，這其實指的是以 k8s 爲底座來面向全世界任何一個雲以及數據中心交付應用，會是接下來的必然趨勢。關於這個趨勢，咱們團隊的同窗專門寫過一篇關於《K8s 多集羣/多雲技術與發展》的文章，歡迎你們進一步閱讀。

相關連接:

• Why Kubernetes will disappear: levelup.gitconnected.com/why-kuberne…
• 雲原生時代， Kubernetes 多集羣架構初探: www.infoq.cn/article/sbw…

Tekton 項目有什麼特殊之處？

基於 k8s 作應用發佈的工具，咱們有着許多選擇，其中不乏業界知名項目 Jenkins X、Spinnaker，也有創業公司出來的小工具好比 Argo Rollout。不過在這其中，咱們團隊如今主要使用的是 Tekton。這裏也有個重要的背景，那就是咱們團隊要面向多雲/多集羣交付的，是複雜有狀態的阿里巴巴中間件應用。這因素我立刻會詳細介紹到。

可能還有部分同窗還不瞭解 Tekton 項目是什麼？這裏我先簡單介紹下。Tekton 是一款 k8s 原生的應用發佈框架，主要用來構建 CI/CD 系統。它本來是 knative 項目裏面一個叫作 build-pipeline 的子項目，用來做爲 knative-build 的下一代引擎。然而，隨着 k8s 社區裏各類各樣的需求涌入，這個子項目慢慢成長爲一個通用的框架，可以提供靈活強大的能力去作基於 k8s 的構建發佈。

可能很多同窗會感到疑惑，有這麼多功能豐富、聲名遠揚的項目，爲何咱們選擇了灰姑娘般的 Tekton？客官別急，容咱們先來梳理一下這個平臺底座的要求：

1. K8s 原生：流程和概念，尤爲是面向用戶的部分，須要融入到 k8s 體系中。此外，最好能跟生態裏的其餘工具互相連通，成爲生態的一環。

   • 舉個例子：Spinnaker 這個項目是很強大的，但它的設計初衷，是面向公有云進行應用交付用的（以虛擬機爲運行時），Kubernetes 只是它所支持的一種 Provider，而且 Provider 還得用 Groovy 寫集成插件。這就使得它跟 K8s 的協做是比較彆扭的。

2. 靈活擴展：基本上全部工具都不可以知足咱們複雜多變的業務需求。這些工具架構自己須要提供足夠靈活的擴展性，來快速定製實現所需功能。

   • 舉個例子：Argo Rollout 自己的應用發佈，是跟 K8s 的 Workload （好比 Deployment ）耦合在一塊兒的。這就不是一個很具有擴展性的作法。最簡單的例子：對於複雜有狀態應用來講，大多都是用 Operator 或者 OpenKruise 管理的，這時候 Argo Rollout 該怎麼辦呢？

3. 輕量級：工具自己不能作得「過重」，即不能有太多的組件或太多的概念。小而輕的項目初期易上手、中期易交付、後期易維護。

   • 舉個例子：Spinnaker 雖然功能強大，可是這也就意味着它把全部的事情都幫你作了。而咱們團隊要發佈的應用是複雜有狀態的中間件應用， 是須要咱們寫本身的 Rollout Controller 來控制發佈流程的。這個要基於 Spinnaker 來作，還得大量作二次開發了，因而原有的衆多功能和組件反而成了負擔。

4. 白盒化：運行中的管道、步驟等須要「白盒化」，即對外暴露狀態。這樣才能跟前端工具聯通，給用戶展現實時狀態信息。

   • 舉個例子：Tekton 其實只提供 Pipeline 這個一個功能，Pipeline 會被直接映射成 K8s Pod 等 API 資源。而好比應用發佈過程的控制，灰度和上線策略，都是咱們本身編寫 K8s Controller 來實現的，這個可控度實際上是咱們比較喜歡的。另外，這種設計，也就意味着 Tekton 不會在K8s 上蓋一個」大帽子「，好比咱們想看發佈狀態、日誌，就等是直接經過 K8s 查看這個 Pipeline 對應的 Pod 的狀態和日誌，不須要再面對另一個 API。

接下來咱們在幾個候選項目之間作比較：

能夠看到，Tekton 在靈活實現定製化功能、K8s 原生性、以及社區裏的受歡迎程度等方面能夠說仍是優點明顯的。這也是爲何，咱們團隊在負責阿里中間件複雜有狀態應用的交付工做時，選擇了在 Tekton 之上構建應用交付體系。

實踐案例：使用 Tekton 自動化應用發佈

接下來咱們將分享使用 Tekton 自動化應用發佈的實踐案例。

一個基於 Tekton 的應用發佈平臺的架構以下：

這裏的流程大體是：

1. 用戶把須要部署的應用先按照一套標準的應用定義寫成 YAML 文件（相似 Helm Chart）；
2. 用戶把應用定義 YAML 推送到 Git 倉庫裏；
3. Tekton CD (一個 K8s Operator) 會監聽到相應的改動，根據不一樣條件生成不一樣的 Tekton Pipelines；

Tekton CD 裏的操做具體分爲如下幾種狀況：

• 若是 Git 改動裏有一個應用 YAML 且該應用不存在，那麼將渲染和生成 Tekton Pipelines 用來建立應用。
• 若是 Git 改動裏有一個應用 YAML 且該應用存在，那麼將渲染和生成 Tekton Pipelines 用來升級應用。這裏咱們會根據應用定義 YAML 裏的策略來作升級，好比作金絲雀發佈、灰度升級。
• 若是 Git 改動裏有一個應用 YAML 且該應用存在且標記了「被刪除」，那麼將渲染和生成 Tekton Pipelines 用來刪除應用。確認應用被刪除後，咱們才從 Git 裏刪除這個應用的 YAML。

接下來，咱們看一個建立應用的簡單例子:

這個例子裏面咱們生成了一個 Tekton Pipeline。運行這個 pipeline 就能夠將應用發佈到 K8s 集羣上。

用戶操做的邊界就是 Git，以後全部流程都是自動化的。那麼整個過程當中用戶怎麼獲得反饋信息呢？這裏主要有：

• 過程狀態：Tekton Pipeline 自己就是 K8s API object，咱們經過彙總 Status 將過程狀態信息透出給前端。
• 日誌和監控：因爲 Tekton Pipeline 啓動的都是 K8s Pod，咱們能夠複用原有的基礎設施去收集，而後作一遍彙總。

經驗總結

上面給你們介紹了 Tekton 項目的基本原理、以及使用 Tekton 作底座進行應用發佈的主要流程。在這裏總結一些經驗體會：

1. 複用開源技術。少去作造輪子的事情就意味着可以多專一更具價值的事情；
2. 不要只着眼於眼前的需求，還要關注定製化和擴展性，多考慮將來的場景；
3. K8s 應用層接下來將會加速發展。幫助開發者在 k8s 上更好地開發、部署、管理應用，把相關流程標準化，是將來的重要趨勢。

另外，Tekton 2019 發展規劃中還包括了 conditional execution, cancelling or pausing a workflow, resuming a paused or failed workflow, enforcing timeouts on Tasks and Pipelines 等功能。站在巨人的肩膀上，將來的應用發佈平臺將會更增強大。

本文做者：鄧洪超

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。