作者 | 鄧洪超，阿里云容器平臺工程師， 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 等功能。站在巨人的肩膀上，未來的應用發布平臺將會更加強大。

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的基于 K8s 做应用发布的工具那么多, 阿里为啥选择灰姑娘般的 Tekton ？的全部內容，希望文章能夠幫你解決所遇到的問題。

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