Tekton Pipeline是一个新项目，可让您使用Kubernetes本机方法运行CI / CD管道。 Tekton Pipelines最初是“ Knative build”项目的一部分。 如果您想了解更多有关该项目的信息，我强烈建议您访问他们的网站，该网站可从此处的链接获得。
在我们开始讨论“ Kubernetes原生”的含义以及Tekton Pipeline的工作方式之前，我想退后一步，简要解释为什么在容器而不是在主机上运行管道如此重要和有用：我们开始将使用的应用程序传输到容器。 我们之所以这样做是由于诸如隔离，透明依赖关系，可伸缩性和不变性之类的好处。 这样对CI / CD管道有用吗？ 考虑一下“构建主机”，它将为一项特定的构建任务提供所需的工具和依赖项。 关于一个环境，该环境在每次启动时都是相同的，并且对其他项目没有任何依赖关系，这可能会导致问题。 而且，关于易于扩展的管道。 这就是为什么我们可以并且应该运行容器化管道的原因！
既然我们已经简短地讨论了管道的容器化，那么让我们来谈谈采用Kubernetes原生方法的Tekton Pipeline项目将如何提供帮助：
Tekton Pipeline允许我们在现有Kubernetes集群中运行容器化管道。 这意味着我们不需要其他机器来运行我们的管道，因此我们可以更好地使用现有机器。
很好，但老实说，这并不会使Tekton Pipeline独树一帜。 因此，Tekton Pipeline更进一步，并将与我们的管道相关的所有内容存储在Kubernetes中-作为Kubernetes资源。 这使我们可以使用输送机以及任何其他资源。 考虑部署或服务，您可以使用kubectl和YAML文件创建和管理它们。
从哪里开始
如上所述，Tekton管道位于Kubernetes集群内部。 它基于5个自定义资源定义（CRD），部署，ConfigMap和服务。 您可以运行以下命令来启动：
kubectl apply -f https://storage.googleapis.com/tekton-releases/latest/release.yaml
除上述资源外，他还将创建命名空间，Pod安全策略，服务帐户和ClusterRoles。 新创建的命名空间（默认名称为tekton-pipelines）中的所有Pod都准备就绪后，Tekton Pipeline即可使用。
当然，您可以查看此YAML文件并根据需要对其进行自定义。
如果需要在任务之间共享工件或其他管道资源，则需要为其设置存储。 您可以使用PVC，它在每次必要时都会被请求（动态卷初始化是关键！）或Blob存储。 您可以在此处找到有关此任务的更多信息。
第一条管道
那么Tekton Pipelines如何工作？ 我将在小示例中解释Tekton Pipelines自定义资源定义之间的区别。 Pipeline将在Go上创建（构建）一个小型应用程序，创建所需的映像，然后将其推送到注册表中。 您可以在此处找到所有相关文件。
首先，我们创建两个PipelineResouce定义，我们将使用它们来定义Git存储库和Registry作为源代码的最终目标。 管道资源是可选的，因此对于使用相同的管道但源和目的地不同的情况非常有用。
apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: git-repo spec: type: git params: - name: revision value: master - name: url value: https://gitlab.com/nmeisenzahl/tekton-demo --- apiVersion: tekton.dev/v1alpha1 kind: PipelineResource metadata: name: image-registry spec: type: image params: - name: url value: registry.gitlab.com/nmeisenzahl/tekton-demo/demo:latest
现在，我们需要创建一个Task资源来确定管道中步骤的顺序。 当然，如有必要，您可以创建多个任务。 在我们的示例中，我们将使用Kaniko创建图像。 像该应用程序的其他资源一样，此Dockerfile位于Git存储库中。
apiVersion: tekton.dev/v1alpha1 kind: Task metadata: name: build-docker-image spec: inputs: resources: - name: git-repo type: git params: - name: pathToDockerFile description: Path to Dockerfile default: /workspace/git-repo/Dockerfile - name: pathToContext description: The build context used by Kaniko default: /workspace/git-repo outputs: resources: - name: image-registry type: image steps: - name: build-and-push image: gcr.io/kaniko-project/executor:v0.10.0 env: - name: "DOCKER_CONFIG" value: "/builder/home/.docker/" command: - /kaniko/executor args: - --dockerfile=${inputs.params.pathToDockerFile} - --destination=${outputs.resources.image-registry.url} - --context=${inputs.params.pathToContext}
现在，我们可以创建TaskRun资源来启动上述任务的实例。 但是，在此示例中，我们使用Pipeline ，我们可以使用它来连续组合多个任务（任务）：
apiVersion: tekton.dev/v1alpha1 kind: Pipeline metadata: name: demo-pipeline spec: resources: - name: git-repo type: git - name: image-registry type: image tasks: - name: build-docker-image taskRef: name: build-docker-image params: - name: pathToDockerFile value: /workspace/git-repo/Dockerfile - name: pathToContext value: /workspace/git-repo resources: inputs: - name: git-repo resource: git-repo outputs: - name: image-registry resource: image-registry
由于我们将创建的Image放在注册表中，因此您需要通过为所需的serviceaccount设置ImagePullSecrets （在我们的示例中为serviceaccount-默认值）来确保可以对管道进行身份验证。
现在，我们拥有启动管道所需的一切。 为此，我们需要为PipelineRun资源指定最后一个定义：
apiVersion: tekton.dev/v1alpha1 kind: PipelineRun metadata: name: demo-pipeline-run-1 spec: pipelineRef: name: demo-pipeline resources: - name: git-repo resourceRef: name: git-repo - name: image-registry resourceRef: name: image-registry
您可以使用kubectl get pipelineruns -o yaml检查管道的状态。
况且
除了Tekton Pipeline项目本身之外，还有一个CLI项目，它使使用管道更加容易。 您还可以设置基于Web的仪表板，以通过浏览器查看和管理管道。
此外，同一团队正在从事另一个名为Tekton Triggers的项目。 该项目是一个相当新的项目（第一次提交是在4周前），并且仍在开发中。 Tekton触发器允许您基于“触发器”调用Tekton Pipelines。 它可以是git-commits，git-issues或任何其他webhooks（网络挂钩）。 可在此处获得更多信息。
另请阅读我们博客上的其他文章：