企业官网建设流程全解析

• 云原生
• CI/CD
• DevOps
• 后端

Tekton 生态中的多个应用（Pipelines、Triggers、Dashboard 等）经常需要互相发现和访问对方管理的资源——例如 Dashboard 需要调用 Pipelines 的 API，Triggers 需要把请求转发给 Pipelines。为了避免依赖脆弱的资源名，Tekton 在发布的每个资源上统一打上 Kubernetes 官方推荐的app.kubernetes.io/*标签。本文基于 resources-labelling.md 展开，结合仓库内的真实 YAML 清单与发布脚本，完整讲解这些标签的语义、设置原则、查找方法及参考取值表，读完后你将能准确识别、查询并复用 Tekton 部署中的各类资源。

为什么 Tekton 需要一套资源标签规范

Tekton 不是一个孤立的单体应用，而是一组相互协作的应用集合：

• Tekton Pipelines：负责创建、调度并执行 PipelineRun / TaskRun；
• Tekton Triggers：监听事件并触发 PipelineRun，需要把请求转交给 Pipelines；
• Tekton Dashboard：作为 Web UI 需要与 Pipelines、Triggers 的 API 交互。

这类"应用之间互相查找资源"的场景决定了资源标识必须稳定、可预测、与应用名解耦。直接按资源名（如tekton-pipelines-controller）硬编码查找存在两个问题：一是资源名可能随发布方式变化，二是无法区分同一集群中部署的多套实例。因此 Tekton 遵循 Kubernetes 官方的 推荐标签（Recommended Labels） 约定，为发布清单中的每一个资源统一附加标签。

归纳起来，这些标签承担两个职责：

1. 识别（Identity）：标识资源属于哪个应用、哪个组件；
2. 查找（Lookup）：允许在需要时通过标签选择器（label selector）快速定位资源。

同时规范强调一个克制原则：标签集合不应超出实际需要。例如某个资源不需要被其他应用查找，就不必为其设置app.kubernetes.io/name标签——少设标签既减少维护负担，也避免误导消费者。

支持的标签及其语义

Tekton 采用以下五个app.kubernetes.io/*推荐标签，每个标签都有明确的职责边界：

几点需要强调：

• app.kubernetes.io/instance是唯一一个"应该总是设置"的标签。文档特别指出，使用 releases 中提供的 YAML 清单部署时，该标签固定为default（app.kubernetes.io/instance: default）。当你在同一集群/命名空间部署多套 Tekton 实例时，可将其改为自定义实例名以区分彼此。
• app.kubernetes.io/component不一定始终存在：一个应用可能不包含多个组件，或者某个资源并不隶属于某个特定组件。原文档此处有一句未写完的注释，结合仓库清单可以看出，实际组件取值覆盖controller、webhook、events、resolvers、dashboard等。
• app.kubernetes.io/name的作用是"组合唯一性"：它自己并不全局唯一，而是与part-of+component+instance一起构成资源的唯一标识；只有当资源确实需要被外部查找时才设置。

通过标签查找资源：不要依赖资源名

规范给出的查找准则是：查找资源应使用标签选择器，而不是硬编码资源名。

以最典型的场景为例：假设 Tekton Pipelines 部署在tekton-pipelines命名空间，需要查找 webhook 对应的Service。正确的做法是在该命名空间内，用以下四元组标签组合筛选：

等价的kubectl命令（标签选择器使用逗号分隔的key=value列表）：

kubectl --namespace=tekton-pipelines get svc -l "app.kubernetes.io/part-of=tekton-pipelines,app.kubernetes.io/component=webhook,app.kubernetes.io/instance=default,app.kubernetes.io/name=webhook"

这条命令把筛选条件全部收敛到标签上，不依赖tekton-pipelines-webhook之类的具体资源名，因此无论资源名如何调整、是否由 Helm/Kustomize/裸 YAML 部署，只要标签约定不变，查找结果就稳定可靠。

常用资源参考表

下表列出了最常见资源的part-of、component、name取值（来自原文档，并依据仓库清单补充了本仓库实际存在的resolvers与events组件）：

NOTE：使用 releases 提供的 YAML 清单部署时，所有资源的app.kubernetes.io/instance标签均为default。表内涉及tekton-triggers、tekton-dashboard的资源属于姊妹项目，本文仅引用原文档结论，仓库内可直接验证的是tekton-pipelines相关条目。

仓库源码中的标签落地情况

标签规范并非仅停留在文档层面，仓库的每一份发布清单都严格贯彻了这套约定。以下取自仓库实际文件。

Controller Deployment 与 Service（config/controller.yaml）

Deployment 与 Service 的元数据都带完整标签集，例如 Deployment 部分（第 18-29 行）：

metadata: name: tekton-pipelines-controller namespace: tekton-pipelines labels: app.kubernetes.io/name: controller app.kubernetes.io/component: controller app.kubernetes.io/instance: default app.kubernetes.io/version: "devel" app.kubernetes.io/part-of: tekton-pipelines # tekton.dev/release value replaced with inputs.params.versionTag in pipeline/tekton/publish.yaml pipeline.tekton.dev/release: "devel" # labels below are related to istio and should not be used for resource lookup version: "devel"

值得注意的细节：

• spec.selector.matchLabels与 Pod template 的标签同样使用这四元组（name/component/instance/part-of），确保 Service 的 selector（第 196-199 行）与 Deployment 保持一致，标签既服务外部查找，也驱动内部的负载均衡与反亲和调度（PodAntiAffinity 同样用app.kubernetes.io/name: controller等做选择）。
• 文件注释明确区分了两类标签：app.kubernetes.io/*与pipeline.tekton.dev/release用于资源标识；而app: tekton-pipelines-controller与version: "devel"是istio 相关标签，"不应被用于资源查找"。这一点再次印证了规范"标签集合不应超过实际需要"的克制原则——查找资源时请只使用app.kubernetes.io/*组合。

Webhook 与 Events、Resolvers 组件

• config/500-webhooks.yaml 中的 webhook 资源统一携带app.kubernetes.io/component: webhook、app.kubernetes.io/instance: default、app.kubernetes.io/part-of: tekton-pipelines（其中 Deployment/Service 额外带app.kubernetes.io/name: webhook）。
• config/events.yaml 中tekton-events-controller（Deployment 与 Service，第 18-45 行）使用app.kubernetes.io/name: events、app.kubernetes.io/component: events。
• 远程解析器（remote resolvers）清单位于 config/resolvers/，其中 resolvers-deployment.yaml 与 resolvers-service.yaml 使用app.kubernetes.io/name: resolvers、app.kubernetes.io/component: resolvers；同目录下的 Namespace、ServiceAccount、ClusterRole、Role、ClusterRoleBinding、RoleBinding 等资源也都带有app.kubernetes.io/component: resolvers+instance: default+part-of: tekton-pipelines。

命名空间与 RBAC 等基础资源

连命名空间与 RBAC 资源也遵循规范，例如 config/100-namespace/100-namespace.yaml（第 20-21 行）与 config/200-clusterrole.yaml（第 20-22 行）分别携带app.kubernetes.io/instance: default、app.kubernetes.io/part-of: tekton-pipelines，ClusterRole 还按controller/webhook/events组件分别标注。这意味着"用标签查找资源"的做法对 ServiceAccount、RBAC 等非工作负载资源同样适用。

版本标签如何从 "devel" 变成真实版本号

仓库清单中app.kubernetes.io/version的占位值是"devel"，它由发布流水线在打包 release 时统一替换为真实版本号。证据位于 tekton/publish.yaml 的发布步骤（第 205-207 行）：

sed -i -e 's/\(pipeline.tekton.dev\/release\): "devel"/\1: "$(params.versionTag)"/g' \ -e 's/\(app.kubernetes.io\/version\): "devel"/\1: "$(params.versionTag)"/g' \ -e 's/\(version\): "devel"/\1: "$(params.versionTag)"/g' ${OUTPUT_RELEASE_DIR}/release.yaml

可见发布时会对pipeline.tekton.dev/release、app.kubernetes.io/version以及 istio 相关的version三个标签执行同样的字符串替换。这解释了为什么从 releases 下载的 YAML 中app.kubernetes.io/version是具体的版本号（如v0.xx.y），而仓库源码中始终是devel。

在集成开发中如何正确使用这套标签

把上述规范落到实际集成开发中，可以归纳为三条可执行建议：

1. 查找优先用标签选择器：任何跨应用访问（Dashboard → Pipelines、Triggers → Pipelines、自定义控制器 → Tekton 组件）都应采用kubectl get <资源> -l "app.kubernetes.io/part-of=tekton-pipelines,app.kubernetes.io/component=<组件>,app.kubernetes.io/instance=default,app.kubernetes.io/name=<名称>"形式，而不是写死资源名。
2. 组合标签保证唯一性：app.kubernetes.io/name必须在part-of+component+instance的组合语境下才唯一；在只部署单实例（instance 为default）时，四元组通常可简化为part-of+component+name三元组，但跨实例场景必须带上instance。
3. 遵守克制原则：如果你扩展或封装 Tekton 清单，只为"需要被识别"和"需要被查找"的资源设置相应标签，component与name均按需取舍，且不要用 istio 相关的app、version标签（见 config/controller.yaml 注释）参与资源查找。

小结

Tekton Pipelines 将 Kubernetes 官方推荐的app.kubernetes.io/*标签作为跨应用资源发现的事实标准：part-of界定应用归属、component界定应用内组件、instance界定部署实例、name界定资源个体、version界定发布版本。这套规范在仓库的每一份清单（config/ 下的 Deployment、Service、Namespace、RBAC 等）中都有完整落地，并由 tekton/publish.yaml 在发布时把版本占位符替换为真实版本号。对开发者而言，只要遵循"用标签查找、组合保证唯一、克制设置"三条原则，就能在 Tekton 生态及你自己的扩展组件之间建立稳定、可维护的资源发现机制。

• 云原生
• CI/CD
• DevOps
• 后端