营销型网站建设品牌,长沙制作公司宣传片哪家好,公众号编辑器怎么使用,深圳做棋牌网站建设找哪家公司好简介
Tekton 是一个功能强大且灵活的Kubernetes 原生开源框架#xff0c;用于创建持续集成和交付#xff08;CI/CD#xff09;系统。 关于Tekton#xff0c; 网上可以搜到很多很多介绍文档#xff0c;本文主要阐述我对Tekton的实现原理和背后的技术逻辑的一点理解。tekto…简介
Tekton 是一个功能强大且灵活的Kubernetes 原生开源框架用于创建持续集成和交付CI/CD系统。 关于Tekton 网上可以搜到很多很多介绍文档本文主要阐述我对Tekton的实现原理和背后的技术逻辑的一点理解。tekton.dev
Tekton定义了Task, TaskRun, Pipeline, PipelineRun, PipelineResource 五类核心对象。Tekton通过对Task和Pipeline的抽象我们可以定义出任意组合的pipeline模板来完成各种各样的CICD任务。通过TaskRun,PipelineRun,PipelineResource可以将这些模板套用到各个实际的项目中。
实现原理
高度抽象的结构化设计使得Tekton具有非常灵活的特性。那么Tekton是如何实现workflow的流转的呢。Tekton利用Kubernetes的List-Watch机制在启动时初始化了2个Controller PipelineRunController和TaskRunController。
PipelineRunController监听PipelineRun对象的变化。在它的reconcile逻辑中将pipeline中所有的Task构建为一张有向无环图(DAG)通过遍历DAG找到当前可被调度的Task节点创建对应的TaskRun对象。
TaskRunController监听TaskRun对象的变化。在它的reconcile逻辑中将TaskRun和对应Task转化为可执行的Pod由kubernetes调度执行。利用Kubernetes的OwnerReference机制pipelinerun own taskrun, taskrun own pod。pod状态变更时触发taskrun的reconcile逻辑taskrun状态变更时触发pipelinerun的reconcile逻辑。 DAG支持
Tekton对DAG的支持相对比较简单。在Tekton中一个Pipeline就是一张DAGPipeline中的多个Task可是DAG中的节点。Task默认并发执行可以通过 RunAfter 和 From 关键字控制执行顺序。
示例
- name: lint-repotaskRef:name: pylintresources:inputs:- name: workspaceresource: my-repo
- name: test-apptaskRef:name: make-testresources:inputs:- name: workspaceresource: my-repo
- name: build-apptaskRef:name: kaniko-build-apprunAfter:- test-appresources:inputs:- name: workspaceresource: my-repooutputs:- name: imageresource: my-app-image
- name: build-frontendtaskRef:name: kaniko-build-frontendrunAfter:- test-appresources:inputs:- name: workspaceresource: my-repooutputs:- name: imageresource: my-frontend-image
- name: deploy-alltaskRef:name: deploy-kubectlresources:inputs:- name: my-app-imageresource: my-app-imagefrom:- build-app- name: my-frontend-imageresource: my-frontend-imagefrom:- build-frontend
渲染出的执行顺序为 | |v vtest-app lint-repo/ \v v
build-app build-frontend\ /v vdeploy-all
相比于Argo等专注在workflow的项目而言Tekton支持的任务编排方式是非常有限的。常见的循环递归重试超时等待等策略都是没有的。
条件判断
Tekton支持 condition 关键字来进行条件判断。Condtion只支持判断当前Task是否执行不能作为DAG的分支条件来进行动态DAG的渲染。
* condition检查失败(exitCode ! 0)task不会被执行pipelineRun状态不会因为condition检查失败而失败。
* 多个条件之间 “与” 逻辑关系PipelineResource在Task间数据交换
作为CICD的工具代码在什么时候Clone到WorkSpace中如何实现的 Tekton中抽象了PipelineResource进行任务之间的数据交换GitResource是其中最基础的一种。用法如下。
声明一个Git类型的PipelineResource:
kind: PipelineResource
metadata:name: skaffold-git-build-push-kaniko
spec:type: gitparams:- name: revisionvalue: v0.32.0- name: urlvalue: https://github.com/GoogleContainerTools/skaffold
在Task中引用这个Resource做为输入
kind: Task
metadata:name: build-push-kaniko
spec:inputs:resources:- name: workspacetype: gitsteps:- name: build-and-pushimage: registry.cn-shanghai.aliyuncs.com/kaniko-project-edas/executor:v0.17.1
代码会被clone在/workspace目录。
Tekton是如何处理这些PipelineResource的呢这就要从Taskrun Controller如何创建Pod说起。
Tekton中一个TaskRun对应一个Pod每个Pod有一系列init-containers和step-containers组成。init-container中完成认证信息初始化workspace目录初始化等初始化工作。
在处理step-container时会根据这个Task引用的资源 Append或者Insert一个step-container来处理对应的输和输出如下图所示。 Task中Step执行顺序控制
Tekton源自Knative Build在Knative Build中使用Init-container来串联Steps保证Steps顺序执行在上面的分析中我们知道Tekton是用Containers来执行StepsPod的Containers是并行执行的Tekton是如何保证Steps执行顺序呢
这是一个TaskRun创建的Pod的部分描述信息可以看到所有的Step都是被/tekton/tools/entrypoints封装起来执行的。 -wait_file指定一个文件通过监听文件句柄在探测到文件存在时执行被封装的Step任务。 -post_file指定一个文件在Step任务完成后创建这个文件。通过文件序列/tekton/tools/${index}来对Step进行排序。
- args:- -wait_file- /tekton/tools/0- -post_file- /tekton/tools/1- -termination_path- /tekton/termination- -entrypoint- /ko-app/git-init- --- -url- https://github.com/GoogleContainerTools/skaffold- -revision- v0.32.0- -path- /workspace/workspacecommand:- /tekton/tools/entrypointimage: registry.cn-shanghai.aliyuncs.com/kaniko-project-edas/git-init:v0.10.2name: step-git-source-skaffold-git-build-push-kaniko-rz765- args:- -wait_file- /tekton/tools/1- -post_file- /tekton/tools/2- -termination_path- /tekton/termination- -entrypoint- /kaniko/executor- --- --dockerfileDockerfile- --destinationlocalhost:5000/leeroy-web- --context/workspace/workspace/examples/microservices/leeroy-web- --oci-layout-path$(inputs.resources.builtImage.path)command:- /tekton/tools/entrypointimage: registry.cn-shanghai.aliyuncs.com/kaniko-project-edas/executorsha256:565d31516f9bb91763dcf8e23ee161144fd4e27624b257674136c71559ce4493name: step-build-and-push- args:- -wait_file- /tekton/tools/2- -post_file- /tekton/tools/3- -termination_path- /tekton/termination- -entrypoint- /ko-app/imagedigestexporter- --- -images- [{name:skaffold-image-leeroy-web-build-push-kaniko,type:image,url:localhost:5000/leeroy-web,digest:,OutputImageDir:/workspace/output/builtImage}]command:- /tekton/tools/entrypointimage: registry.cn-shanghai.aliyuncs.com/kaniko-project-edas/imagedigestexporter:v0.10.2name: step-image-digest-exporter-lvlj9
实践
使用Tekton构建代码并部署到SAE
Serverless 应用引擎 SAE 是阿里云上一款面向应用的 Serverless PaaS 平台帮助 PaaS 层用户免运维 IaaS按需使用按量计费实现低门槛微服务应用上云有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架真正实现了 Serverless 架构和微服务架构的完美融合。
接下来将使用Tekton部署一个Spring Cloud微服务应用到SAE平台。
示例中的演示代码地址https://github.com/alicloud-demo/spring-cloud-demo前置条件 在Kubernetes集群上安装Tekton创建一个SAE应用定义一个Git资源
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:name: spring-cloud-demo
spec:type: gitparams:- name: urlvalue: https://github.com/alicloud-demo/spring-cloud-demo
定义构建和部署Task
根据SAE官方文档进行部署。
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:name: build-deploy-sae
spec:inputs:resources:- name: sourcetype: gitsteps:- name: build-and-deployimage: maven:3.3-jdk-8command: [mvn, clean, package, -f, source, toolkit:deploy, -Dtoolkit_profiletoolkit_profile.yaml, -Dtoolkit_packagetoolkit_package.yaml, -Dtoolkit_deploytoolkit_deploy.yaml]securityContext:runAsUser: 0
定义TaskRun运行任务
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:name: build-deploy-sae
spec:taskRef:name: build-deploy-saeinputs:resources:- name: sourceresourceRef:name: spring-cloud-demo
导入到kubernetes中运行
kubectl apply -f source-2-service-taskrun.yaml 查看日志
kubectl logs build-deploy-sae-pod-85xdk step-build-and-deploy
构建日志
部署日志
[INFO] Start to upload [provider3-1.0-SNAPSHOT.jar] using [Sae uploader].
[INFO] [##################################################] 100.0%
[INFO] Upload finished in 3341 ms, download url: [https://edas-hz.oss-cn-hangzhou.aliyuncs.com/apps/K8S_APP_ID/37adb12b-5f0c-4711-98ec-1f1e91e6b043/provider3-1.0-SNAPSHOT.jar]
[INFO] Begin to trace change order: e2499b9a-6a51-4904-819c-1838c1dd62cb
[INFO] PipelineName: Batch: 1, PipelineId:f029314a-88bb-450b-aa35-7cc550ff1329
[INFO] Waiting...
[INFO] Waiting...
[INFO] Waiting...
[INFO] Waiting...
[INFO] Waiting...
[INFO] Waiting...
[INFO] Waiting...
[INFO] Waiting...
[INFO] Deploy application successfully!
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 32:41 min
[INFO] Finished at: 2020-04-15T10:09:3900:00
[INFO] Final Memory: 47M/190M
[INFO] ------------------------------------------------------------------------
验证部署结果
在SAE控制台查看变更记录
验证应用访问
总结
区别于传统的CICD工具JenkinsTekton是一套构建CICD系统的框架。Tekton不能使你立即获得CICD的能力。但是基于Tekton可以设计出各种花式的构建部署流水线。得益于Tekton良好的抽象这些设计出的流水线可以作为模板在多个组织项目间共享。 Tekton源自Knative的Build-Template项目设计之初的一个重要目标就是使人们能够共享和重用构成pipeline的组件以及Pipeline本身。在Tekton的RoadMap中Tekton Catelog就是为了实现这一目标而提出的。
区别于Argo这种基于Kubernetes的Workflow工具Tekton在工作流控制上的支持是比较弱的。一些复杂的场景比如循环递归等都是不支持的。更不用说Argo在高并发和大集群调度下的性能优化。这和Tekton的定位有关Tekton定位于实现CICD的框架对于CICD不需要过于复杂的流程控制。大部分的研发流程可以被若干个最佳实践来覆盖。而这些最佳实践应该也必须可以在不同的组织间共享为此Tekton设计了PipelineResource的概念。PipelineResource是Task间交互的接口也是跨平台跨组织共享重用的组件在PipelineResource上还可以有很多想象空间。
作者信息九辩阿里巴巴高级开发工程师负责阿里云EDAS(企业级分布式应用服务)应用生命周期研发工作长期关注云时代微服务的部署和治理工作。
原文链接 本文为云栖社区原创内容未经允许不得转载。
