作者 | 鄧洪超，阿裡雲容器平台工程師， 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 等功能。站在巨人的肩膀上，未來的應用釋出平台将會更加強大。