[[399353]]

本文轉(zhuǎn)載自微信公眾號「新鈦云服」，作者張春 翻譯。轉(zhuǎn)載本文請聯(lián)系新鈦云服公眾號。

我們都知道每個重大的項目都需要CI/CD，我很確定沒有必要解釋為什么。不過，在決定在何處構(gòu)建CI/CD時，有很多工具、平臺和解決方案可供選擇。您可以選擇Jenkins、Travis、CircleCI、Bamboo和許多其他的，但是如果您正在為運行在Kubernetes上的云本地應(yīng)用程序構(gòu)建CI/CD，那么使用適當(dāng)?shù)墓ぞ咄瑫r運行云本地CI/CD是很有意義的。

其中一個允許您在Kubernetes上本機運行CI/CD的解決方案是Tekton，因此在本文中，我們將開始關(guān)于使用Tekton構(gòu)建CI/CD的系列文章，首先介紹、安裝和定制Tekton，以開始我們在Kubernetes上使用云本地CI/CD的旅程。

TL;DR:使用Tekton啟動您的CI/CD所需的所有資源、腳本和文件都可以在https://github.com/MartinHeinz/tekton-kickstarter找到。

正如標(biāo)題和介紹所暗示的，Tekton是云原生CI/CD工具。它最初是在谷歌開發(fā)的，被稱為Knative管道。它在Kubernetes上作為一組自定義資源(crd)運行，如管道或任務(wù)，其生命周期由Tekton的控制器管理。事實上，它本機運行在Kubernetes上，這使它成為管理/構(gòu)建/部署任何部署在Kubernetes上的應(yīng)用程序和資源的理想選擇。

這表明它適合管理Kubernetes的工作負(fù)載，但是為什么不使用其他更流行的工具呢?

常用的CI/CD解決方案，如Jenkins、Travis或Bamboo并不是為了在Kubernetes上運行而構(gòu)建的，或者缺乏與Kubernetes的適當(dāng)集成。這使得部署、維護和管理CI/CD工具本身以及使用它來部署任何kubernetes本地應(yīng)用程序變得困難和/或令人煩惱。

另一方面，由于Kubernetes運營商與所有其他容器化應(yīng)用程序并排在一起，因此Tekton可以非常輕松地進行部署，并且每個Tekton管道都是另一個Kubernetes資源，其管理方式與舊式Pod或Deployments相同。

這也使Tekton可以很好地與GitOps做法配合使用，因為您可以采用所有管道和配置并以git的形式進行維護，而對于至少一種上述工具則不能這么說。資源消耗也是如此-考慮到整個Tekton部署只是幾個pod-與其他CI / CD工具相比，在管道不運行時消耗很少的內(nèi)存和CPU。

話雖如此，很顯然，如果您要在Kubernetes上運行所有工作負(fù)載，那么最好在CI / CD中使用一些Kubernetes原生工具。Tekton是唯一的選擇嗎?不，當(dāng)然，您可以使用其他工具，其中之一就是JenkinsX，這是從本地開始使用Kubernetes進行持續(xù)交付的一種自以為是的方式。

它包含許多工具，如果您對替代工具沒有強烈的偏好，可以使您的生活更輕松，但是如果您要自定義技術(shù)堆棧，也可能會很煩人。盡管JenkinsX仍然在后臺使用Tekton，所以您最好還是學(xué)習(xí)使用Tekton，然后再決定是否還需要JenkinsX提供的所有其他組件

另一個選擇是Spinnaker，它是一個多云解決方案，已經(jīng)存在了很長一段時間。它使用插件來集成各種各樣的提供商，其中之一就是Kubernetes。但是，它不是一個構(gòu)建引擎——它不提供測試代碼、構(gòu)建應(yīng)用程序映像或?qū)⑺鼈兺扑偷絩egistry的工具，對于這些任務(wù)，您仍然需要一些其他CI工具。

現(xiàn)在，讓我們仔細(xì)看看Tekton的組成-Tekton的核心僅包含幾個CustomResourceDefinitions(CRD)，它們是Tasks和Pipelines，它們充當(dāng)TaskRuns和PipelineRuns的藍(lán)圖。這四個(加上其他一些即將被棄用或現(xiàn)在不相關(guān)的)足以開始運行一些管道和任務(wù)。

但是，考慮到大多數(shù)設(shè)置都需要構(gòu)建，部署以及因此還需要由某些事件觸發(fā)的管道，通常這還不夠。因此，我們還安裝了Tekton觸發(fā)器，該觸發(fā)器提供了其他資源，即-EventListener，TriggerBinding和TriggerTemplate。這三個資源為我們提供了偵聽特定事件(例如(GitHub)webhooks，CloudEvents或cron作業(yè)發(fā)送的事件)的方式，并啟動了特定的管道。

最后一個(也是非常可選的組件)是Tekton Dashboard，它是一個非常簡單的GUI，但是卻是檢查所有CRD(包括任務(wù)，管道和觸發(fā)器)的非常方便的工具。它還允許搜索和過濾，這在查找TaskRun和PipelineRun時會很有幫助。您還可以使用它從現(xiàn)有的任務(wù)和管道創(chuàng)建TaskRun和PipelineRun。所有這些部分都由控制器部署和Pod管理，這些部署和Pod負(fù)責(zé)上述CRD的生命周期。

##Setting

考慮到Tekton由多個組件組成，安裝可能會有些復(fù)雜，并且可以通過多種方式完成。 通常，您至少要安裝管道和觸發(fā)器，最明顯的方法是使用原始Kubernetes清單安裝它，但是您可以采用更簡單的方法，并從OperatorHub安裝Tekton Operator，后者已經(jīng)包括所有部分。

作為任何安裝方法的前提，我們顯然需要一個集群，在這里，我們將使用KinD(Docker中的Kubernetes)進行本地管道開發(fā)。 我們將為KinD使用以下自定義配置，因為我們將需要部署Ingress控制器并公開端口80/443，以便能夠訪問Tekton Triggers事件偵聽器。

# kind-tekton.yaml 
kind: Cluster 
apiVersion: kind.x-k8s.io/v1alpha4 
nodes: 
- role: control-plane 
  kubeadmConfigPatches: 
  - | 
    kind: InitConfiguration 
    nodeRegistration: 
      kubeletExtraArgs: 
        node-labels: "ingress-ready=true" 
  extraPortMappings: 
  - containerPort: 80 
    hostPort: 80 
    protocol: TCP 
  - containerPort: 443 
    hostPort: 443 

我們可以使用以下命令創(chuàng)建集群:

~ $ kind create cluster --name tekton --image=kindest/node:v1.20.2 --config=kind-tekton.yaml 
~ $ kubectl cluster-info --context kind-tekton 
~ $ kubectl config set-context kind-tekton 
~ $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml 
~ $ kubectl wait --namespace ingress-nginx --for=condition=ready pod --selector=app.kubernetes.io/component=controller --timeout=90s 

現(xiàn)在，對于Tekton Pipeline和Triggers的實際部署-我提到了通過Tekton Operator進行安裝，這似乎是最快和最好的方式來啟動和運行預(yù)先配置的所有內(nèi)容，但是，該操作員(在撰寫本文時)沒有任何東西。實際文檔，因此您需要進行大量挖掘才能找到有關(guān)工作方式的任何解釋，對于我個人而言，這并不是什么大問題。但是，這里真正的問題是，OperatorHub中的Operator不是最新的，我找不到當(dāng)前的構(gòu)建/映像，這或多或少地使它無用。

我敢肯定，當(dāng)Tekton Operator更成熟時，這種情況會在某個時候改變(因此請注意它的存儲庫)，但是在那之前，應(yīng)該使用其他安裝選項。如果您恰巧在OpenShift上運行，則可以使用的選項是Red Hat Pipeline Operator，它也是-Kubernetes Operator，但在這種情況下，由Red Hat策劃并為OpenShift定制。只需單擊幾下即可在Web控制臺中安裝它，因此，如果您可以訪問OpenShift群集，則應(yīng)嘗試一下。

使用此功能的一個缺點是發(fā)行周期較慢，因此您將不得不使用最新版本的Tekton。如果不能選擇OpenShift或只想在Kubernetes上運行，則使用原始清單進行安裝就可以了，這是這樣做的方式：

~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml  # Deploy pipelines 
~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/latest/release.yaml  # Deploy triggers 
~ $ kubectl get svc,deploy --namespace tekton-pipelines --selector=app.kubernetes.io/part-of=tekton-pipelines 
NAME                                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                              AGE 
service/tekton-pipelines-controller   ClusterIP   10.106.114.94   <none>        9090/TCP,8080/TCP                    2m13s 
service/tekton-pipelines-webhook      ClusterIP   10.105.247.0    <none>        9090/TCP,8008/TCP,443/TCP,8080/TCP   2m13s 
  
NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE 
deployment.apps/tekton-pipelines-controller   1/1     1            1           2m13s 
deployment.apps/tekton-pipelines-webhook      1/1     1            1           2m13s 

如果您希望在此安裝中也包含Tekton儀表板，那么您需要再應(yīng)用一組清單

~ $ kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/latest/tekton-dashboard-release.yaml  # Deploy dashboard 
~ $ kubectl get svc,deploy -n tekton-pipelines --selector=app=tekton-dashboard 
NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE 
service/tekton-dashboard   ClusterIP   10.111.144.87   <none>        9097/TCP   25s 
  
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE 
deployment.apps/tekton-dashboard   1/1     1            1           25s 

除此之外，我們還需要額外的入口才能到達(dá)儀表盤:

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: dashboard 
  namespace: tekton-pipelines 
  annotations: 
    nginx.ingress.kubernetes.io/rewrite-target: '/$2' 
spec: 
  rules: 
    - http: 
        paths: 
          - path: /dashboard(/|$)(.*) 
            pathType: Prefix 
            backend: 
              service: 
                name: tekton-dashboard 
                port: 
                  number: 9097 

默認(rèn)情況下，先前應(yīng)用的儀表板資源默認(rèn)情況下是在tekton-pipelines命名空間中創(chuàng)建的，并且包括使用端口9097的名為tekton-dashboard的服務(wù)，這是上面Ingress中引用的值。 此Ingress還具有重寫規(guī)則，以在/ dashboard / ...路徑而不是/處顯示儀表板。

這是因為我們要對事件偵聽器的Webhook使用默認(rèn)的/(根)路徑(后面將介紹主題)。要驗證Dashboard是否確實處于活動狀態(tài)并且一切都在運行，您可以瀏覽到localhost / dashboard /(假設(shè)您正在使用KinD)，并且應(yīng)該看到類似以下內(nèi)容(減去實際管道)：

如果所有這些設(shè)置似乎都花了很多力氣，那么您可以獲取tekton-kickstarter存儲庫并運行make，一分鐘之內(nèi)即可完成所有上述準(zhǔn)備。部署完成后，我們已經(jīng)完成所有(非常)基本的工作，因此，讓我們在CLI中四處看看，看看我們實際使用您所命令的內(nèi)容進行了部署...

探索自定義資源如果按照上述步驟進行操作(或僅使用了啟動存儲庫中的make target)，那么您的集群中現(xiàn)在應(yīng)該有很多新資源。Tekton的所有組件將位于tekton-pipelines名稱空間中，并應(yīng)包括以下內(nèi)容：

~ $ kubectl get deploy,service,ingress,hpa -n tekton-pipelines 
NAME                                                READY   UP-TO-DATE   AVAILABLE   AGE 
deployment.apps/tekton-dashboard                    1/1     1            1           2m24s 
deployment.apps/tekton-pipelines-controller         1/1     1            1           6m57s 
deployment.apps/tekton-pipelines-webhook            1/1     1            1           6m57s 
deployment.apps/tekton-triggers-controller          1/1     1            1           6m56s 
deployment.apps/tekton-triggers-core-interceptors   1/1     1            1           6m56s 
deployment.apps/tekton-triggers-webhook             1/1     1            1           6m56s 
  
NAME                                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                              AGE 
service/tekton-dashboard                    ClusterIP   10.108.143.42    <none>        9097/TCP                             2m24s 
service/tekton-pipelines-controller         ClusterIP   10.98.218.218    <none>        9090/TCP,8080/TCP                    6m57s 
service/tekton-pipelines-webhook            ClusterIP   10.101.192.94    <none>        9090/TCP,8008/TCP,443/TCP,8080/TCP   6m57s 
service/tekton-triggers-controller          ClusterIP   10.98.189.205    <none>        9090/TCP                             6m56s 
service/tekton-triggers-core-interceptors   ClusterIP   10.110.47.172    <none>        80/TCP                               6m56s 
service/tekton-triggers-webhook             ClusterIP   10.111.209.100   <none>        443/TCP                              6m56s 
  
NAME                                  CLASS    HOSTS   ADDRESS     PORTS   AGE 
ingress.networking.k8s.io/dashboard   <none>   *       localhost   80      2m24s 
  
NAME                                      REFERENCE                            TARGETS               MINPODS  MAXPODS  REPLICAS  AGE 
hpa.autoscaling/tekton-pipelines-webhook  Deployment/tekton-pipelines-webhook  <unknown>/100%  1        5        1         6m57s 

這些包括所有部署，服務(wù)以及自動擴展程序，在請求數(shù)量更多的情況下，它們可以幫助提高可用性。 如果需要HA，那么您也可以查看docs部分，其中介紹了如何配置Tekton for HA。

除了上面顯示的資源之外，您還可以在默認(rèn)名稱空間中找到事件偵聽器及其資源。 它們可以與核心組件共享名稱空間，但是像這樣拆分它們可以使您根據(jù)使用的應(yīng)用程序/項目來保持管道及其webhooks的劃分：

kubectl get deploy,service,ingress,hpa -n default 
NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE 
deployment.apps/el-cron-listener         1/1     1            1           8m40s 
deployment.apps/el-http-event-listener   1/1     1            1           8m40s 
  
NAME                             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE 
service/el-cron-listener         ClusterIP   10.100.238.60   <none>        8080/TCP   8m40s 
service/el-http-event-listener   ClusterIP   10.98.88.164    <none>        8080/TCP   8m40s 
  
NAME                                      CLASS    HOSTS   ADDRESS     PORTS   AGE 
ingress.networking.k8s.io/http-listener   <none>   *       localhost   80      8m40s 

Tekton的安裝還帶來了幾個CRD，這些CRD用于管理所有任務(wù)，管道和觸發(fā)器：

kubectl get crd | grep tekton 
clustertasks.tekton.dev                      2021-02-27T20:23:35Z 
clustertriggerbindings.triggers.tekton.dev   2021-02-27T20:23:36Z 
conditions.tekton.dev                        2021-02-27T20:23:35Z 
eventlisteners.triggers.tekton.dev           2021-02-27T20:23:36Z 
extensions.dashboard.tekton.dev              2021-02-27T20:28:08Z 
pipelineresources.tekton.dev                 2021-02-27T20:23:35Z 
pipelineruns.tekton.dev                      2021-02-27T20:23:35Z 
pipelines.tekton.dev                         2021-02-27T20:23:35Z 
runs.tekton.dev                              2021-02-27T20:23:35Z 
taskruns.tekton.dev                          2021-02-27T20:23:35Z 
tasks.tekton.dev                             2021-02-27T20:23:35Z 
triggerbindings.triggers.tekton.dev          2021-02-27T20:23:36Z 
triggers.triggers.tekton.dev                 2021-02-27T20:23:36Z 
triggertemplates.triggers.tekton.dev         2021-02-27T20:23:36Z 

您可以使用這些CRD使用kubectl get或kubectl describe列出和檢查任務(wù)和管道。對于Kubernetes的每個用戶，與資源進行交互的自然方法是使用kubectl，但是Tekton也擁有自己的CLI工具tkn。 您可以從此發(fā)行頁面下載它。此CLI允許您與Tekton資源進行交互，而不必處理CRD。 例如，您可以列出或檢查管道：

~ $ tkn pipeline list 
NAME              AGE            LAST RUN    STARTED          DURATION    STATUS 
database-backup   12 hours ago   job-qxcwc   39 minutes ago   8 minutes   Failed 
deploy            12 hours ago   ---         ---              ---         --- 
  
~ $ tkn pipeline describe deploy 
# ... Long and verbose output 

除了檢查資源，你還可以使用它來啟動taskrun或PipelineRuns，然后讀取日志，而不需要查找單個的pod:

~ $ tkn task start send-to-webhook-slack 
? Value for param `webhook-secret` of type `string`? slack-webhook 
? Value for param `message` of type `string`? Hello There! 
TaskRun started: send-to-webhook-slack-run-d5sxv 
  
In order to track the TaskRun progress run: 
tkn taskrun logs send-to-webhook-slack-run-d5sxv -f -n default 
  
~ $ tkn taskrun logs send-to-webhook-slack-run-d5sxv -f -n default 
[post]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current 
[post]                                  Dload  Upload   Total   Spent    Left  Speed 
100    23    0     0  100    23      0    111 --:--:-- --:--:-- --:--:--   111 

正如您在上面看到的，如果您一開始沒有指定參數(shù)，它甚至?xí)崾灸斎雲(yún)?shù)!

不過，有一件事讓我非常惱火，那就是與kubectl相比，這個CLI工具使用的參數(shù)順序相反。kubectl的順序是kubectl ，而tkn是tkn ，這是一個非常方便的工具。

*本文翻譯自https://martinheinz.dev/blog/45