【編者的話】“人間四月芳菲盡，山寺桃花始盛開。” 越來越多專門給 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/7aDijN9月2日前，使用任意語言開發一個可以被容器化、運作在 K8s 上的應用，并把該應用做成 Helm Charts 格式送出即可參賽！蘋果 Airpods，Cherry鍵盤、天貓精靈等豐厚禮品等你拿！