【編者的話】“人間四月芳菲盡，山寺桃花始盛開。” 越來越多專門給 Kubernetes 做應用發布的工具開始繽紛呈現，幫助大家管理和發布不斷增多的 Kubernetes 應用。在做技術選型的時候，我們需要給業務選擇一個最好的工具、最穩的底座。那我們又該如何比較和衡量這些工具的呢？在這篇文章中阿里一線工程師給大家分享自己獨特的體驗。洗盡鉛華，一起品味這“山寺桃花”。

背景

近年來，伴隨著云原生社區（CNCF Community）的迅猛發展，越來越多的應用跑在了 Kubernetes 上。慢慢地，大家的關注點也逐漸從資源層轉移到應用層。一方面，我們看到在有越來越多新的 Kubernetes Operators 出現，用來自動化應用的部署和運維。另一方面，隨著各路大型云廠商入場，Kubernetes 服務以后就會像家里的水和電一樣隨心所欲可用，自己再去動手搭建已經沒有了意義。于是人們提出了“Kubernetes 將會消失”，這其實指的是以 Kubernetes 為底座來面向全世界任何一個云以及數據中心交付應用，會是接下來的必然趨勢。關于這個趨勢，我們團隊的同學專門寫過一篇關于《云原生時代， Kubernetes 多集群架構初探》的文章，歡迎大家進一步閱讀。

Tekton 項目有什么特殊之處？

基于 Kubernetes 做應用發布的工具，我們有著許多選擇，其中不乏業界知名項目 Jenkins X、Spinnaker，也有創業公司出來的小工具比如 Argo Rollout。不過在這其中，我們團隊現在主要使用的是 Tekton。這里也有個重要的背景，那就是我們團隊要面向多云/多集群交付的，是復雜有狀態的阿里巴巴中間件應用。這因素我馬上會詳細介紹到。

可能還有部分同學還不了解 Tekton 項目是什么？這里我先簡單介紹下。Tekton 是一款 Kubernetes 原生的應用發布框架，主要用來構建 CI/CD 系統。它原本是 Knative 項目里面一個叫做 build-pipeline 的子項目，用來作為 knative-build 的下一代引擎。然而，隨著 Kubernetes 社區里各種各樣的需求涌入，這個子項目慢慢成長為一個通用的框架，能夠提供靈活強大的能力去做基于 Kubernetes 的構建發布。

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

• Kubernetes 原生：流程和概念，尤其是面向用戶的部分，需要融入到 Kubernetes 體系中。此外，最好能跟生態里的其他工具互相連通，成為生態的一環。
  舉個例子：Spinnaker 這個項目是很強大的，但它的設計初衷，是面向公有云進行應用交付用的（以虛擬機為運行時），Kubernetes 只是它所支持的一種 Provider，并且 Provider 還得用 Groovy 寫集成插件。這就使得它跟 Kubernetes 的協作是比較別扭的。
• 靈活擴展：基本上所有工具都不能夠滿足我們復雜多變的業務需求。這些工具架構本身需要提供足夠靈活的擴展性，來快速定制實現所需功能。
  舉個例子：Argo Rollout 本身的應用發布，是跟 Kubernetes 的 Workload （比如 Deployment ）耦合在一起的。這就不是一個很具備擴展性的做法。最簡單的例子：對于復雜有狀態應用來說，大多都是用 Operator 或者 OpenKruise 管理的，這時候 Argo Rollout 該怎么辦呢？
• 輕量級：工具本身不能做得“太重”，即不能有太多的組件或太多的概念。小而輕的項目初期易上手、中期易交付、后期易維護。
  舉個例子：Spinnaker 雖然功能強大，但是這也就意味著它把所有的事情都幫你做了。而我們團隊要發布的應用是復雜有狀態的中間件應用， 是需要我們寫自己的 Rollout Controller 來控制發布流程的。這個要基于 Spinnaker 來做，還得大量做二次開發了，于是原有的眾多功能和組件反而成了負擔。
• 白盒化：運行中的管道、步驟等需要“白盒化”，即對外暴露狀態。這樣才能跟前端工具聯通，給用戶展示實時狀態信息。
  舉個例子：Tekton 其實只提供 Pipeline 這個一個功能，Pipeline 會被直接映射成 Kubernetes Pod 等 API 資源。而比如應用發布過程的控制，灰度和上線策略，都是我們自己編寫 Kubernetes Controller 來實現的，這個可控度其實是我們比較喜歡的。另外，這種設計，也就意味著 Tekton 不會在 Kubernetes 上蓋一個“大帽子”，比如我們想看發布狀態、日志，就等是直接通過 Kubernetes 查看這個 Pipeline 對應的 Pod 的狀態和日志，不需要再面對另外一個 API。

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

可以看到，Tekton 在靈活實現定制化功能、Kubernetes 原生性、以及社區里的受歡迎程度等方面可以說還是優勢明顯的。這也是為什么，我們團隊在負責阿里中間件復雜有狀態應用的交付工作時，選擇了在 Tekton 之上構建應用交付體系。

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

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

一個基于 Tekton 的應用發布平臺的架構如下：

這里的流程大致是：

用戶把需要部署的應用先按照一套標準的應用定義寫成 YAML 文件（類似 Helm Chart）；

用戶把應用定義 YAML 推送到 Git 倉庫里；

Tekton CD（一個 Kubernetes Operator）會監聽到相應的改動，根據不同條件生成不同的 Tekton Pipelines。

Tekton CD 里的操作具體分為以下幾種情況：

• 如果 Git 改動里有一個應用 YAML 且該應用不存在，那么將渲染和生成 Tekton Pipelines 用來創建應用。
• 如果 Git 改動里有一個應用 YAML 且該應用存在，那么將渲染和生成 Tekton Pipelines 用來升級應用。這里我們會根據應用定義 YAML 里的策略來做升級，比如做金絲雀發布、灰度升級。
• 如果 Git 改動里有一個應用 YAML 且該應用存在且標記了“被刪除”，那么將渲染和生成 Tekton Pipelines 用來刪除應用。確認應用被刪除后，我們才從 Git 里刪除這個應用的 YAML。

接下來，我們看一個創建應用的簡單例子：

這個例子里面我們生成了一個 Tekton Pipeline。運行這個 Pipeline 就可以將應用發布到 Kubernetes 集群上。

用戶操作的邊界就是 Git，之后所有流程都是自動化的。那么整個過程中用戶怎么得到反饋信息呢？這里主要有：

• 過程狀態：Tekton Pipeline 本身就是 Kubernetes API object，我們通過匯總 Status 將過程狀態信息透出給前端。
• 日志和監控：由于 Tekton Pipeline 啟動的都是 Kubernetes Pod，我們可以復用原有的基礎設施去收集，然后做一遍匯總。

經驗總結

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

復用開源技術。少去做造輪子的事情就意味著能夠多專注更具價值的事情。

不要只著眼于眼前的需求，還要關注定制化和擴展性，多考慮未來的場景。

Kubernetes 應用層接下來將會加速發展。幫助開發者在 Kubernetes 上更好地開發、部署、管理應用，把相關流程標準化，是未來的重要趨勢。

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

Q&A

Q：請比較一下 Drone 和 Tekton，thx！
A：Drone 是一個 CI/CD 工具，Tekton 是用來做 CI/CD 的框架。Tekton 在更底層，也更為靈活。

Q：Tekton 作為一個執行引擎，可能會有很多執行節點串聯運行，不同節點中運行狀態和日志是如何反饋的？
A：Tekton Pipeline 本身就是 Kubernetes API object，我們通過匯總 Status 來透出運行狀態。由于 Tekton Pipeline 啟動的都是 Kubernetes Pod，我們可以復用原有的基礎設施去收集，然后做一遍匯總。

Q：Tekton 如何與 GitOps 結合？
A：我們做了一個類似于 flux（https://github.com/fluxcd/flux）的 Operator，通過監聽 webhook 事件等來觸發操作。

Q：Tekton 集成方面有哪些特性？
A：靈活以及非常云原生。比傳統工具更好在 Kubernetes 跟其他組件做集成。比方說，跟 Flagger 等在 Kubernetes 提供金絲雀發布策略的組件結合，做云原生應用發布。

Q： Tekton 既然作為 Knative 項目里面一個叫做 build-pipeline 的子項目，那請問下 Tekton 和 Knative 有什么不同或者對比優缺點嗎，我最近有準備做 Knative，今天有幸看到這個分享，正好請教一下？
A：Knative 是 Serverless Framework，跟 Tekton 解決的不是一個層面的事情，沒有比較性。相反，他們可以 inter-operate，Knative 里就使用了 Tekton。

Q：我的看法是 CD 和 CI 都只是 Tekton 的 Task，能否講下你們的 CI？
A：你好，我們做的是 CD。不只是 Tekton Task，也用了其他的 Tekton 原生功能，比如 Pipeline、PipelineResource 等。我們做的是面向多云/多集群交付的、面向復雜有狀態的阿里巴巴中間件應用的發布平臺。

Q：你們做的這個和 Jenkins X Pipeline Operator and Tekton 的區別和兩者的優缺點？
A：Jenkins X 是 CloudBees 團隊基于原來 Jenkins 的需求，再使用 Tekton、Prow 等搭建的 CI/CD 平臺。這也側面說明了 Tekton 等云原生工具的優勢。但 Jenkins X 做的比較重。而且以 CI 端為主，不支持復雜的發布策略。

Q：請問有什么好的 GitOps trigger？我們使用的的是 Phabricator， 一直沒有找到適合的trigger。
A：這個主要看工具本身（比如 Phabricator）提供什么樣的 Git trigger，然后才能集成到如 flux 這樣的 GitOps 工具中。

Q：請比較一下 Prow 和 Tekton，發現 Kubernetes，Prometheus 以及 Tenkton 本身都是使用了 Prow。
A：Prow 是一款基于 GitHub 做的 Chatbot 工具。Tekton 則是用來實現后面對接的 CI/CD 的底層框架。本人恰好也是早期參與 Prow 項目，所以多說一點這個工具的歷史。一開始 GitHub 功能不夠強大，這個工具只是為了彌補 GitHub 的不足之處，主要是要經過 review 不能讓人手動合并代碼。后來功能做著做著變多了，有些被 GitHub 重復了。但是功能集合還是比 GitHub 多，而且 CNCF 里的 infra 默認使用。

活動推薦

【首屆云原生應用大賽火熱報名中】報名鏈接：http://t.tb.cn/7aDijN

9月2日前，使用任意語言開發一個可以被容器化、運行在 K8s 上的應用，并把該應用做成 Helm Charts 格式提交即可參賽！蘋果 Airpods，Cherry鍵盤、天貓精靈等豐厚禮品等你拿！

總結

以上是生活随笔為你收集整理的初探云原生应用管理之：聊聊 Tekton 项目的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。