一、Tekton与Kubernetes集成的常见难题
1.1 资源调度与适配难题
很多刚接触Tekton的开发者，在把流水线和K8s集群绑定后，常会遇到流水线任务莫名失败的问题，大概率是资源没配对。比如团队用Tekton做微服务镜像构建，Node.js项目的镜像构建需要至少500MB内存，但Tekton的Pod默认继承K8s集群的通用资源配额（通常是256MB内存），导致Pod因为内存不足被集群强行杀掉，构建过程直接中断。这种问题本质是Tekton任务没有匹配到K8s集群的实际资源需求，默认的通用资源配置无法适配不同场景的任务负载。
1.2 权限配置的混乱问题
K8s里的ServiceAccount相当于Pod的“身份凭证”，要让Tekton流水线能拉私有镜像、读取集群资源，就需要给对应的ServiceAccount配置权限。很多新手要么直接给ServiceAccount赋予集群管理员权限（ClusterRole），完全忽略最小安全原则；要么只给了基础权限，导致流水线拉私有镜像时因为没有Secret读取权限而报错。比如要拉企业私有镜像仓库Harbor的镜像，需要把Harbor的认证信息存在K8s Secret里，再挂载到Tekton的Pod，但新手常忘记挂载Secret或者没给ServiceAccount加Secret的读取权限，导致流水线一直卡在镜像拉取步骤。
1.3 流水线执行状态追踪不清晰
Tekton的流水线由多个Task组成，构建、测试、部署每个步骤都对应一个K8s Pod。新手刚用的时候，经常不知道怎么快速找到某个步骤的日志，也看不出哪个环节卡了很久。比如测试环节的Pod执行超时，但不知道是测试脚本有问题还是资源不够，只能一个个去查K8s Pod的日志，效率极低，这就是Tekton和K8s联动时的状态追踪痛点。
二、对应解决方案及实践
2.1 精准配置资源请求与限制
解决资源调度问题的核心是给Tekton的Task明确指定资源配额，让K8s能给流水线Pod分配足够的CPU和内存，避免被集群回收。下面是完整的示例：
# 技术栈：Kubernetes Tekton
# 这个Task用于构建Node.js应用的Docker镜像，明确指定资源配额
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: build-node-app
spec:
# 定义该Task的资源需求：requests是保证能拿到的资源，limits是最多能用的资源
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "1Gi"
cpu: "500m"
steps:
- name: build
image: gcr.io/kaniko-project/executor:v1.9.0
# 挂载存放Harbor认证信息的Secret，用于拉私有镜像
volumeMounts:
- name: harbor-auth
mountPath: /kaniko/.docker
args:
- --dockerfile=./Dockerfile
- --context=$(workspace.source.path)
- --destination=harbor.example.com/my-node-app:latest
# 定义需要的工作区（存放应用代码）和卷（存放认证信息）
workspaces:
- name: source
volumes:
- name: harbor-auth
secret:
secretName: harbor-secret
这个示例里，requests的512Mi内存能保证Pod不会因为内存不足被集群杀掉，limits的1Gi内存避免该Pod过度占用集群资源，平衡了稳定性和资源利用率。
2.2 遵循最小必要权限原则配置ServiceAccount
权限混乱的解决方案是只给ServiceAccount分配刚好需要的权限，不用集群级的宽权限。比如只让Tekton流水线有权限读取指定Namespace里的Pod和Secret，不需要全集群权限，示例如下：
# 技术栈：Kubernetes Tekton
# 自定义ServiceAccount，给Tekton流水线用
apiVersion: v1
kind: ServiceAccount
metadata:
name: tekton-pipeline-sa
namespace: default
---
# 自定义Role，只赋予Pod和Secret的查看权限（最小必要）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: tekton-pipeline-role
namespace: default
rules:
- apiGroups: [""]
resources: ["pods", "secrets"]
verbs: ["get", "list"]
---
# 绑定Role和ServiceAccount，让这个账号拥有对应的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tekton-pipeline-binding
namespace: default
subjects:
- kind: ServiceAccount
name: tekton-pipeline-sa
roleRef:
kind: Role
name: tekton-pipeline-role
apiGroup: rbac.authorization.k8s.io
配置完后，在Tekton的PipelineRun里指定这个ServiceAccount，就能避免权限过大的风险，同时满足流水线的基本权限需求。
2.3 用Tekton工具链实现状态可视化追踪
解决状态追踪问题的方法是用Tekton官方的Dashboard，它能把流水线的每个步骤、每个Pod的状态可视化，不用手动查K8s日志。另外，用tkn命令行工具（Tekton的CLI）可以快速查看流水线日志：
# 获取指定流水线的运行日志
tkn pipelinerun logs my-pipeline-run -n default
这个命令会直接输出对应流水线的所有步骤日志，不用再一个个找K8s Pod，大大提升了调试效率。
三、适用场景分析
Tekton和K8s集成的适用场景非常明确：
- K8s原生微服务集群：团队的所有应用都部署在K8s上，不想维护额外的CI/CD工具（比如Jenkins），希望用和集群无缝联动的原生工具；
- 需要灵活定制CI/CD流程：Tekton的Task可以自由组合，比如构建、测试、部署、镜像扫描等步骤都能拆分，适合复杂的流水线需求；
- 有一定K8s基础的团队：需要理解K8s的ServiceAccount、RBAC、资源配额等概念，能快速定位和解决集成时的小问题。
四、技术优缺点总结
Tekton与K8s集成的核心优点：
- 完全贴合K8s生态，不需要额外的服务器，集群扩容时Tekton流水线也能自动扩容；
- 遵循K8s的安全最佳实践，ServiceAccount、RBAC等机制能保障流水线的安全性；
- 开源社区活跃，更新频繁，支持K8s的最新特性。 缺点也很明显：
- 配置门槛比Jenkins高，需要手动编写YAML文件，新手需要花时间学习Tekton的资源定义；
- 没有可视化拖拽界面，复杂流水线的配置需要手动组合多个Task；
- 日志和监控的集成需要额外配置，不像Jenkins有开箱即用的监控面板。
五、实践注意事项
- 资源配置要合理：根据Task的实际需求设置requests和limits，比如构建镜像需要大内存，测试步骤用小一点的资源；
- 权限配置坚持最小必要：不要给ServiceAccount赋予ClusterRole，只在需要的Namespace里配置Role；
- 版本兼容要注意：Tekton的版本和K8s版本需要兼容，比如Tekton v0.50+支持K8s 1.25以上版本，避免版本不兼容导致的错误；
- 私有镜像Secret定期更新：Harbor的账号密码要定期更换，避免Secret泄露；
- 设置流水线超时时间：Tekton的PipelineRun可以设置超时，避免因为异常导致Pod长时间占用资源。
六、文章总结
Tekton作为K8s原生的CI/CD工具，和K8s集成时遇到的资源、权限、追踪问题，都可以通过精准配置、最小权限、工具链辅助解决。对于想要搭建原生K8s CI/CD的团队来说，只要遵循K8s的最佳实践，Tekton能很好地满足持续集成、持续部署的需求，虽然配置门槛稍高，但灵活性和安全性都优于传统的CI工具。
Comments