本文转载自微信公众号「新钛云服」，作者张春 翻译。转载本文请联系新钛云服公众号。
我们都知道每个重大的项目都需要CI/CD，我很确定没有必要解释为什么。不过，在决定在何处构建CI/CD时，有很多工具、平台和解决方案可供选择。您可以选择Jenkins、Travis、CircleCI、Bamboo和许多其他的，但是如果您正在为运行在Kubernetes上的云本地应用程序构建CI/CD，那么使用适当的工具同时运行云本地CI/CD是很有意义的。
其中一个允许您在Kubernetes上本机运行CI/CD的解决方案是Tekton，因此在本文中，我们将开始关于使用Tekton构建CI/CD的系列文章，首先介绍、安装和定制Tekton，以开始我们在Kubernetes上使用云本地CI/CD的旅程。
TL;DR:使用Tekton启动您的CI/CD所需的所有资源、脚本和文件都可以在https://github.com/MartinHeinz/tekton-kickstarter找到。
正如标题和介绍所暗示的，Tekton是云原生CI/CD工具。它最初是在谷歌开发的，被称为Knative管道。它在Kubernetes上作为一组自定义资源(crd)运行，如管道或任务，其生命周期由Tekton的控制器管理。事实上，它本机运行在Kubernetes上，这使它成为管理/构建/部署任何部署在Kubernetes上的应用程序和资源的理想选择。
这表明它适合管理Kubernetes的工作负载，但是为什么不使用其他更流行的工具呢?
常用的CI/CD解决方案，如Jenkins、Travis或Bamboo并不是为了在Kubernetes上运行而构建的，或者缺乏与Kubernetes的适当集成。这使得部署、维护和管理CI/CD工具本身以及使用它来部署任何kubernetes本地应用程序变得困难和/或令人烦恼。
另一方面，由于Kubernetes运营商与所有其他容器化应用程序并排在一起，因此Tekton可以非常轻松地进行部署，并且每个Tekton管道都是另一个Kubernetes资源，其管理方式与旧式Pod或Deployments相同。
这也使Tekton可以很好地与GitOps做法配合使用，因为您可以采用所有管道和配置并以git的形式进行维护，而对于至少一种上述工具则不能这么说。资源消耗也是如此-考虑到整个Tekton部署只是几个pod-与其他CI / CD工具相比，在管道不运行时消耗很少的内存和CPU。
话虽如此，很显然，如果您要在Kubernetes上运行所有工作负载，那么最好在CI / CD中使用一些Kubernetes原生工具。Tekton是唯一的选择吗?不，当然，您可以使用其他工具，其中之一就是JenkinsX，这是从本地开始使用Kubernetes进行持续交付的一种自以为是的方式。
它包含许多工具，如果您对替代工具没有强烈的偏好，可以使您的生活更轻松，但是如果您要自定义技术堆栈，也可能会很烦人。尽管JenkinsX仍然在后台使用Tekton，所以您最好还是学习使用Tekton，然后再决定是否还需要JenkinsX提供的所有其他组件
另一个选择是Spinnaker，它是一个多云解决方案，已经存在了很长一段时间。它使用插件来集成各种各样的提供商，其中之一就是Kubernetes。但是，它不是一个构建引擎——它不提供测试代码、构建应用程序映像或将它们推送到registry的工具，对于这些任务，您仍然需要一些其他CI工具。
现在，让我们仔细看看Tekton的组成-Tekton的核心仅包含几个CustomResourceDefinitions(CRD)，它们是Tasks和Pipelines，它们充当TaskRuns和PipelineRuns的蓝图。这四个(加上其他一些即将被弃用或现在不相关的)足以开始运行一些管道和任务。
但是，考虑到大多数设置都需要构建，部署以及因此还需要由某些事件触发的管道，通常这还不够。因此，我们还安装了Tekton触发器，该触发器提供了其他资源，即-EventListener，TriggerBinding和TriggerTemplate。这三个资源为我们提供了侦听特定事件(例如(GitHub)webhooks，CloudEvents或cron作业发送的事件)的方式，并启动了特定的管道。
最后一个(也是非常可选的组件)是Tekton Dashboard，它是一个非常简单的GUI，但是却是检查所有CRD(包括任务，管道和触发器)的非常方便的工具。它还允许搜索和过滤，这在查找TaskRun和PipelineRun时会很有帮助。您还可以使用它从现有的任务和管道创建TaskRun和PipelineRun。所有这些部分都由控制器部署和Pod管理，这些部署和Pod负责上述CRD的生命周期。
##Setting
考虑到Tekton由多个组件组成，安装可能会有些复杂，并且可以通过多种方式完成。 通常，您至少要安装管道和触发器，最明显的方法是使用原始Kubernetes清单安装它，但是您可以采用更简单的方法，并从OperatorHub安装Tekton Operator，后者已经包括所有部分。
作为任何安装方法的前提，我们显然需要一个集群，在这里，我们将使用KinD(Docker中的Kubernetes)进行本地管道开发。 我们将为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
我们可以使用以下命令创建集群:
- ~ $ 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
现在，对于Tekton Pipeline和Triggers的实际部署-我提到了通过Tekton Operator进行安装，这似乎是最快和最好的方式来启动和运行预先配置的所有内容，但是，该操作员(在撰写本文时)没有任何东西。实际文档，因此您需要进行大量挖掘才能找到有关工作方式的任何解释，对于我个人而言，这并不是什么大问题。但是，这里真正的问题是，OperatorHub中的Operator不是最新的，我找不到当前的构建/映像，这或多或少地使它无用。
我敢肯定，当Tekton Operator更成熟时，这种情况会在某个时候改变(因此请注意它的存储库)，但是在那之前，应该使用其他安装选项。如果您恰巧在OpenShift上运行，则可以使用的选项是Red Hat Pipeline Operator，它也是-Kubernetes Operator，但在这种情况下，由Red Hat策划并为OpenShift定制。只需单击几下即可在Web控制台中安装它，因此，如果您可以访问OpenShift群集，则应尝试一下。
使用此功能的一个缺点是发行周期较慢，因此您将不得不使用最新版本的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仪表板，那么您需要再应用一组清单
- ~ $ 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
除此之外，我们还需要额外的入口才能到达仪表盘:
- 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
默认情况下，先前应用的仪表板资源默认情况下是在tekton-pipelines命名空间中创建的，并且包括使用端口9097的名为tekton-dashboard的服务，这是上面Ingress中引用的值。 此Ingress还具有重写规则，以在/ dashboard / ...路径而不是/处显示仪表板。
这是因为我们要对事件侦听器的Webhook使用默认的/(根)路径(后面将介绍主题)。要验证Dashboard是否确实处于活动状态并且一切都在运行，您可以浏览到localhost / dashboard /(假设您正在使用KinD)，并且应该看到类似以下内容(减去实际管道)：
如果所有这些设置似乎都花了很多力气，那么您可以获取tekton-kickstarter存储库并运行make，一分钟之内即可完成所有上述准备。部署完成后，我们已经完成所有(非常)基本的工作，因此，让我们在CLI中四处看看，看看我们实际使用您所命令的内容进行了部署...
探索自定义资源如果按照上述步骤进行操作(或仅使用了启动存储库中的make target)，那么您的集群中现在应该有很多新资源。Tekton的所有组件将位于tekton-pipelines名称空间中，并应包括以下内容：
- ~ $ 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
这些包括所有部署，服务以及自动扩展程序，在请求数量更多的情况下，它们可以帮助提高可用性。 如果需要HA，那么您也可以查看docs部分，其中介绍了如何配置Tekton for HA。
除了上面显示的资源之外，您还可以在默认名称空间中找到事件侦听器及其资源。 它们可以与核心组件共享名称空间，但是像这样拆分它们可以使您根据使用的应用程序/项目来保持管道及其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用于管理所有任务，管道和触发器：
- 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列出和检查任务和管道。对于Kubernetes的每个用户，与资源进行交互的自然方法是使用kubectl，但是Tekton也拥有自己的CLI工具tkn。 您可以从此发行页面下载它。此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
正如您在上面看到的，如果您一开始没有指定参数，它甚至会提示您输入参数!
不过，有一件事让我非常恼火，那就是与kubectl相比，这个CLI工具使用的参数顺序相反。kubectl的顺序是kubectl ，而tkn是tkn ，这是一个非常方便的工具。
*本文翻译自https://martinheinz.dev/blog/45
