基於 K8s 做應用釋出的工具那麼多, 阿里為啥選擇灰姑娘般的 Tekton ？
作者 | 鄧洪超，阿里雲容器平臺工程師， Kubernetes Operator 第二人，雲原生應用標準交付與管理領域知名技術專家
導讀：近年來，越來越多專門給 Kubernetes 做應用釋出的工具開始繽紛呈現，幫助大家管理和釋出不斷增多的 Kubernetes 應用。在做技術選型的時候，我們需要給業務選擇一個最好的工具、最穩的底座。那麼又該如何比較和衡量這些工具呢？本篇文章中阿里雲技術專家鄧洪超將會和大家分享自己獨特的體驗，幫助讀者初步瞭解 Tekton 專案。
背景
近年來，伴隨著雲原生社群 (CNCF Community) 的迅猛發展，越來越多的應用跑在了 K8s 上。慢慢地，大家的關注點也逐漸從資源層轉移到應用層。一方面，我們看到在有越來越多新的 K8s Operators 出現，用來自動化應用的部署和運維。另一方面，隨著各路大型雲廠商入場，K8s 服務以後就會像家裡的水和電一樣隨心所欲可用，自己再去動手搭建已經沒有了意義。於是人們提出了“K8s 將會消失”，這其實指的是以 k8s 為底座來面向全世界任何一個雲以及資料中心交付應用，會是接下來的必然趨勢。關於這個趨勢，我們團隊的同學專門寫過一篇關於《K8s 多叢集/多雲技術與發展》的文章，歡迎大家進一步閱讀。
相關連結:
- Why Kubernetes will disappear: https://levelup.gitconnected.com/why-kubernetes-will-disappear-10ffcfb39f01
- 雲原生時代， Kubernetes 多叢集架構初探: https://www.infoq.cn/article/sbwSX8ypxgID2-SB723K
Tekton 專案有什麼特殊之處？
基於 k8s 做應用釋出的工具，我們有著許多選擇，其中不乏業界知名專案 Jenkins X、Spinnaker，也有創業公司出來的小工具比如 Argo Rollout。不過在這其中，我們團隊現在主要使用的是 Tekton。這裡也有個重要的背景，那就是我們團隊要面向多雲/多叢集交付的，是複雜有狀態的阿里巴巴中介軟體應用。這因素我馬上會詳細介紹到。
可能還有部分同學還不瞭解 Tekton 專案是什麼？這裡我先簡單介紹下。Tekton 是一款 k8s 原生的應用釋出框架，主要用來構建 CI/CD 系統。它原本是 knative 專案裡面一個叫做 build-pipeline 的子專案，用來作為 knative-build 的下一代引擎。然而，隨著 k8s 社群裡各種各樣的需求湧入，這個子專案慢慢成長為一個通用的框架，能夠提供靈活強大的能力去做基於 k8s 的構建釋出。
可能不少同學會感到疑惑，有這麼多功能豐富、聲名遠揚的專案，為什麼我們選擇了灰姑娘般的 Tekton？客官別急，容我們先來梳理一下這個平臺底座的要求：
- K8s 原生：流程和概念，尤其是面向使用者的部分，需要融入到 k8s 體系中。此外，最好能跟生態裡的其他工具互相連通，成為生態的一環。
- 舉個例子：Spinnaker 這個專案是很強大的，但它的設計初衷，是面向公有云進行應用交付用的（以虛擬機器為執行時），Kubernetes 只是它所支援的一種 Provider，並且 Provider 還得用 Groovy 寫整合外掛。這就使得它跟 K8s 的協作是比較彆扭的。
- 靈活擴充套件：基本上所有工具都不能夠滿足我們複雜多變的業務需求。這些工具架構本身需要提供足夠靈活的擴充套件性，來快速定製實現所需功能。
- 舉個例子：Argo Rollout 本身的應用釋出，是跟 K8s 的 Workload （比如 Deployment ）耦合在一起的。這就不是一個很具備擴充套件性的做法。最簡單的例子：對於複雜有狀態應用來說，大多都是用 Operator 或者 OpenKruise 管理的，這時候 Argo Rollout 該怎麼辦呢？
- 輕量級：工具本身不能做得“太重”，即不能有太多的元件或太多的概念。小而輕的專案初期易上手、中期易交付、後期易維護。
- 舉個例子：Spinnaker 雖然功能強大，但是這也就意味著它把所有的事情都幫你做了。而我們團隊要釋出的應用是複雜有狀態的中介軟體應用， 是需要我們寫自己的 Rollout Controller 來控制釋出流程的。這個要基於 Spinnaker 來做，還得大量做二次開發了，於是原有的眾多功能和元件反而成了負擔。
- 白盒化：執行中的管道、步驟等需要“白盒化”，即對外暴露狀態。這樣才能跟前端工具聯通，給使用者展示實時狀態資訊。
- 舉個例子：Tekton 其實只提供 Pipeline 這個一個功能，Pipeline 會被直接對映成 K8s Pod 等 API 資源。而比如應用釋出過程的控制，灰度和上線策略，都是我們自己編寫 K8s Controller 來實現的，這個可控度其實是我們比較喜歡的。另外，這種設計，也就意味著 Tekton 不會在K8s 上蓋一個”大帽子“，比如我們想看釋出狀態、日誌，就等是直接通過 K8s 檢視這個 Pipeline 對應的 Pod 的狀態和日誌，不需要再面對另外一個 API。
接下來我們在幾個候選專案之間做比較：
可以看到，Tekton 在靈活實現定製化功能、K8s 原生性、以及社群裡的受歡迎程度等方面可以說還是優勢明顯的。這也是為什麼，我們團隊在負責阿里中介軟體複雜有狀態應用的交付工作時，選擇了在 Tekton 之上構建應用交付體系。
實踐案例：使用 Tekton 自動化應用釋出
接下來我們將分享使用 Tekton 自動化應用釋出的實踐案例。
一個基於 Tekton 的應用釋出平臺的架構如下：
這裡的流程大致是：
- 使用者把需要部署的應用先按照一套標準的應用定義寫成 YAML 檔案（類似 Helm Chart）；
- 使用者把應用定義 YAML 推送到 Git 倉庫裡；
- 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 做底座進行應用釋出的主要流程。在這裡總結一些經驗體會：
- 複用開源技術。少去做造輪子的事情就意味著能夠多專注更具價值的事情；
- 不要只著眼於眼前的需求，還要關注定製化和擴充套件性，多考慮未來的場景；
- K8s 應用層接下來將會加速發展。幫助開發者在 k8s 上更好地開發、部署、管理應用，把相關流程標準化，是未來的重要趨勢。
另外，Tekton 2019 發展規劃中還包括了 conditional execution, cancelling or pausing a workflow, resuming a paused or failed workflow, enforcing timeouts on Tasks and Pipelines 等功能。站在巨人的肩膀上，未來的應用釋出平臺