云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载Tekton 生态中的多个应用Pipelines、Triggers、Dashboard 等经常需要互相发现和访问对方管理的资源——例如 Dashboard 需要调用 Pipelines 的 APITriggers 需要把请求转发给 Pipelines。为了避免依赖脆弱的资源名Tekton 在发布的每个资源上统一打上 Kubernetes 官方推荐的app.kubernetes.io/*标签。本文基于 resources-labelling.md 展开结合仓库内的真实 YAML 清单与发布脚本完整讲解这些标签的语义、设置原则、查找方法及参考取值表读完后你将能准确识别、查询并复用 Tekton 部署中的各类资源。为什么 Tekton 需要一套资源标签规范Tekton 不是一个孤立的单体应用而是一组相互协作的应用集合Tekton Pipelines负责创建、调度并执行 PipelineRun / TaskRunTekton Triggers监听事件并触发 PipelineRun需要把请求转交给 PipelinesTekton Dashboard作为 Web UI 需要与 Pipelines、Triggers 的 API 交互。这类应用之间互相查找资源的场景决定了资源标识必须稳定、可预测、与应用名解耦。直接按资源名如tekton-pipelines-controller硬编码查找存在两个问题一是资源名可能随发布方式变化二是无法区分同一集群中部署的多套实例。因此 Tekton 遵循 Kubernetes 官方的 推荐标签Recommended Labels 约定为发布清单中的每一个资源统一附加标签。归纳起来这些标签承担两个职责识别Identity标识资源属于哪个应用、哪个组件查找Lookup允许在需要时通过标签选择器label selector快速定位资源。同时规范强调一个克制原则标签集合不应超出实际需要。例如某个资源不需要被其他应用查找就不必为其设置app.kubernetes.io/name标签——少设标签既减少维护负担也避免误导消费者。支持的标签及其语义Tekton 采用以下五个app.kubernetes.io/*推荐标签每个标签都有明确的职责边界标签语义是否必须说明app.kubernetes.io/part-of资源所属的应用是取值如tekton-pipelines、tekton-dashboard、tekton-triggers等app.kubernetes.io/component资源所属的应用内组件按需取值如controller、webhook应用只有一个组件或资源不属于某特定组件时可不设置app.kubernetes.io/instance应用实例标识总是设置多个实例部署在同一集群/命名空间时尤其有用app.kubernetes.io/name资源自身的唯一名称按需与part-of、component、instance组合后应能唯一确定一个资源无需被查找的资源可不设置app.kubernetes.io/version资源的版本按发布填充在发布清单中以devel占位发布时被替换为真实版本号见下文几点需要强调app.kubernetes.io/instance是唯一一个应该总是设置的标签。文档特别指出使用 releases 中提供的 YAML 清单部署时该标签固定为defaultapp.kubernetes.io/instance: default。当你在同一集群/命名空间部署多套 Tekton 实例时可将其改为自定义实例名以区分彼此。app.kubernetes.io/component不一定始终存在一个应用可能不包含多个组件或者某个资源并不隶属于某个特定组件。原文档此处有一句未写完的注释结合仓库清单可以看出实际组件取值覆盖controller、webhook、events、resolvers、dashboard等。app.kubernetes.io/name的作用是组合唯一性它自己并不全局唯一而是与part-ofcomponentinstance一起构成资源的唯一标识只有当资源确实需要被外部查找时才设置。通过标签查找资源不要依赖资源名规范给出的查找准则是查找资源应使用标签选择器而不是硬编码资源名。以最典型的场景为例假设 Tekton Pipelines 部署在tekton-pipelines命名空间需要查找 webhook 对应的Service。正确的做法是在该命名空间内用以下四元组标签组合筛选labelvalueapp.kubernetes.io/part-oftekton-pipelinesapp.kubernetes.io/componentwebhookapp.kubernetes.io/instancedefaultapp.kubernetes.io/namewebhook等价的kubectl命令标签选择器使用逗号分隔的keyvalue列表kubectl --namespacetekton-pipelines get svc -l app.kubernetes.io/part-oftekton-pipelines,app.kubernetes.io/componentwebhook,app.kubernetes.io/instancedefault,app.kubernetes.io/namewebhook这条命令把筛选条件全部收敛到标签上不依赖tekton-pipelines-webhook之类的具体资源名因此无论资源名如何调整、是否由 Helm/Kustomize/裸 YAML 部署只要标签约定不变查找结果就稳定可靠。常用资源参考表下表列出了最常见资源的part-of、component、name取值来自原文档并依据仓库清单补充了本仓库实际存在的resolvers与events组件resourcetypeapp.kubernetes.io/part-ofapp.kubernetes.io/componentapp.kubernetes.io/namepipelines controller deploymentDeploymenttekton-pipelinescontrollercontrollerpipelines controller serviceServicetekton-pipelinescontrollercontrollerpipelines webhook serviceServicetekton-pipelineswebhookwebhooktriggers controller deploymentDeploymenttekton-triggerscontrollercontrollertriggers controller serviceServicetekton-triggerscontrollercontrollertriggers webhook serviceServicetekton-triggerswebhookwebhookdashboard controller deploymentDeploymenttekton-dashboarddashboarddashboarddashboard controller serviceServicetekton-dashboarddashboarddashboardpipelines resolvers deploymentDeploymenttekton-pipelinesresolversresolverspipelines resolvers serviceServicetekton-pipelinesresolversresolverspipelines events controller deploymentDeploymenttekton-pipelineseventseventsNOTE使用 releases 提供的 YAML 清单部署时所有资源的app.kubernetes.io/instance标签均为default。表内涉及tekton-triggers、tekton-dashboard的资源属于姊妹项目本文仅引用原文档结论仓库内可直接验证的是tekton-pipelines相关条目。仓库源码中的标签落地情况标签规范并非仅停留在文档层面仓库的每一份发布清单都严格贯彻了这套约定。以下取自仓库实际文件。Controller Deployment 与 Serviceconfig/controller.yamlDeployment 与 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-controllerDeployment 与 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: resolversinstance: defaultpart-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-pipelinesClusterRole 还按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。在集成开发中如何正确使用这套标签把上述规范落到实际集成开发中可以归纳为三条可执行建议查找优先用标签选择器任何跨应用访问Dashboard → Pipelines、Triggers → Pipelines、自定义控制器 → Tekton 组件都应采用kubectl get 资源 -l app.kubernetes.io/part-oftekton-pipelines,app.kubernetes.io/component组件,app.kubernetes.io/instancedefault,app.kubernetes.io/name名称形式而不是写死资源名。组合标签保证唯一性app.kubernetes.io/name必须在part-ofcomponentinstance的组合语境下才唯一在只部署单实例instance 为default时四元组通常可简化为part-ofcomponentname三元组但跨实例场景必须带上instance。遵守克制原则如果你扩展或封装 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/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐actions-runner-controller 资源标签规范ADR用 Kubernetes 推荐标签与 actions.github.com 标签实现日志筛选与故障排查actions runner controller 资源标签规范ADR用 Kubernetes 推荐标签与 actions.github.com 标签实现后端云原生容器编排CI/CD弹性伸缩云资源标签管理规范 v2.1云资源标签管理规范 v2.1 1. 强制标签 | 标签键 | 允许值 | 说明 | 责任部门 | | | | | | | Environment | produ知识库运维Rook 资源标签体系解析Rook-Ceph 推荐标签Recommended Labels的语义、实现与使用Rook 资源标签体系解析Rook Ceph 推荐标签Recommended Labels的语义、实现与使用 本篇技术指南聚焦 Rook 项目为 Rook云原生存储容器编排运维上一篇WeKan 无障碍Accessibility实践指南从可访问性声明页到键盘与屏幕阅读器支持下一篇cm6-graphql 完整能力指南基于 CodeMirror 6 的 GraphQL 语言扩展演进与源码解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考