Tekton Pipelines 中 PipelineResources 的弃用之路：现状、原因与迁移替代方案

云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载阅读对象正在使用或即将使用 Tekton Pipelines 的开发者、平台工程师。本文以仓库内 docs/resources.md 为核心骨架结合 docs/deprecations.md、docs/migrating-v1alpha1-to-v1beta1.md 以及pkg/apis下的源码实现完整梳理PipelineResource这一 CRD 的定位、为何始终停留在 Alpha 级别、最终被弃用并移除的完整脉络以及迁移到Tasks、workspaces等替代方案的实操路径。读完本文你将能够判断现有工作负载是否依赖PipelineResources理解其被替代的底层原因并掌握向v1beta1/v1生态迁移的具体步骤。一、PipelineResources 是什么一个为 Task 制造副作用的 CRDPipelineResource是 Tekton Pipelines 中描述作为 Task 输入或输出的外部资源的一种 CRD。在仓库源码中它的类型定义位于 pkg/apis/resource/v1alpha1/pipeline_resource_types.go注释明确写着PipelineResource describes a resource that is an input to or output from a Task.描述一个作为 Task 输入或输出的资源。从源码结构看一个PipelineResource由以下部分组成见 pipeline_resource_types.goType资源类型标识源码中定义了git、storage、gcs等常量Params一组ResourceParamname/value键值对用于描述 URL、revision 等参数SecretParams可选的SecretParamfieldName/secretKey/secretName用于从 Kubernetes Secret 中取字段填充资源属性Description面向用户的描述信息可用于填充 UI。原文档对这套机制做了精准的概括——也许唯一能确定的就是PipelineResourceCRD 可以为你的Task制造副作用Perhaps the one thing you can say about thePipelineResourceCRD is that it can create side-effects for yourTasks.。原文档列举了各类资源的具体行为逐条罗列如下类型行为git从远端仓库拉取文件写入 Task 磁盘pull-request与 Pull Request 交互写入文件到 Task 磁盘gcs与 Google Cloud Storage 交互写入文件到 Task 磁盘gcs-build与 GCS 构建产物交互写入文件到 Task 磁盘cluster向 Task 磁盘写入一份供 Task 使用的集群配置cloudEvent告知 Pipelines controller 向特定端点发射 CloudEventsimage在一个 Task 中写入 digest在另一个 Task 中读回它其中四种类型git、pull-request、gcs、gcs-build与外部系统交互五种类型git、pull-request、gcs、gcs-build、cluster会把文件写到 Task 的磁盘上cloudEvent触发控制器行为cluster为 Task 写配置image跨 Task 传递 digest。这种类型各干各的事的形态正是后续一系列设计问题的根源。二、为什么 PipelineResources 始终没能进入 Beta原文档开篇就给出了一条醒目结论PipelineResources已弃用deprecated且从未随 Pipeline 的其他 CRD 一起晋升到 Beta其支持级别始终停留在 Alpha。这条警告同样记录在 docs/deprecations.md 的弃用表中。为什么 Tekton 开发者不愿意给PipelineResources一个 Beta 级别的支持承诺原文档给出了完整的多维论证这也是理解整套弃用决策的关键。2.1 行为不透明Their behaviour can be opaquePipelineResource的实现方式是注入 Task Steps、卷配置与控制器内类型特定代码的混合体。这意味着来自PipelineResources的错误会以多种不同方式显现你往往很难判断某个报错是否真的与PipelineResource行为直接相关文档只解释了每种资源类型的快乐路径错误场景下的可诊断信息长期不足。这一点可以从源码中得到印证在 pkg/apis/pipeline/v1beta1/resource_types.go 中PipelineResourceInterface定义了GetInputTaskModifier(ts *TaskSpec, path string)与GetOutputTaskModifier(ts *TaskSpec, path string)两个方法返回TaskModifier而TaskModifier接口恰恰暴露了GetStepsToPrepend()、GetStepsToAppend()、GetVolumes()见 resource_types.go。也就是说每种资源类型本质上是在运行时向 Task 的 Step 列表前置/追加额外的步骤、并注入额外的卷——这就是原文档所说混合了注入的 Task Steps、卷配置和类型特定代码的代码级证据。2.2 失败时难以调试When they fail theyre difficult to debug多种PipelineResource会在Task自身的 Steps之前注入自己的 Steps。若你想在这些前置步骤运行前手动插入步骤去检查容器状态几乎不可能做到——因为你无法在注入的步骤和Task 自己的步骤之间自由插入调试代码。这种注入式设计使排查成本显著上升。2.3 类型覆盖远远不够There arent enough of them已有的六种原文档此处写为 six types但其后行为清单实际列举了git、pull-request、gcs、gcs-build、cluster、cloudEvent、image七种行为PipelineResources只覆盖了 Tekton Pipelines 希望支持的外部系统与副作用集合中极小的一部分。面对日益多样的 CI/CD 场景这套机制在广度上先天不足。2.4 可扩展性让它们和 Tasks 高度相似原文档指出一旦为PipelineResource加入扩展能力它就会变得与Task几乎一样用户自定义的Steps这正是Task提供的用户自定义的 paramsTask早已具备用户自定义的资源结果Task有Task Results用 PVC 在Task之间共享数据workspaces已经为Task提供。换言之PipelineResources试图解决的可扩展资源问题Tasks体系以更成熟、更一致的方式覆盖了。既然两者功能大量重叠保留一套平行机制就不再合理。2.5 它们让 Task 变得更难复用这是原文档中非常关键的工程论证一个Task必须选择它接受哪种type的PipelineResource。如果一个Task接受git类型的PipelineResource那么它就无法再从TaskRun或PipelineRun接受一个gcs类型的PipelineResource尽管git和gcs本质上都是把远端文件写到本地磁盘理论上应当可以互换但在现有实现下它们完全不互换——类型耦合破坏了资源抽象的本意。2.6 文档视角的难题从文档维护角度PipelineResources同样棘手这个 CRD 的目的本身模糊难以精确说明它究竟是什么它的行为横跨外部系统交互、磁盘写入、控制器事件发射、配置落盘、digest 传递等多种模式难以用统一叙述讲清楚。综合以上原因原文档的结论是PipelineResources尚未做好接受 Beta 支持承诺的准备。三、仍有哪些值得留下的价值Whats still missing弃用不等于毫无价值。原文档明确列出PipelineResources依然存在价值的几个方面这对理解为什么是渐进式弃用、而不是一夜删除至关重要可以增强 Task-only 工作流。例如你想在测试 Task 前先检出 git 仓库有两种做法方案 A使用gitPipelineResource直接附加到测试Task上方案 B编写一个Pipeline用git-cloneTask 把代码检出到 PersistentVolumeClaimworkspace上再把该 PVCworkspace传给测试 Task。原文档指出对很多用户而言方案 B 完全可接受但对另一部分用户不是典型原因包括部分平台无法分配存储PersistentVolumeClaims根本不可用把单个Task工作流扩展成一个Pipeline工作量大且显得没必要。单个类型容易理解。尽管整套 CRD 难以用一句话讲清楚但每一种具体类型如git都很直观——用户几乎不用读文档就能对git resource 是什么建立合理直觉。配置由 Tekton Pipelines controller 发射 CloudEvents。原文档提到相关工作正在进行中希望为 Pipelines controller 引入 notifications 支持以替代cloudEventsPipelineResource。仓库现状与此呼应cloudEvents相关的能力已由 config/config-events.yaml 等配置承载并且 docs/deprecations.md 弃用表中记录了config-defaults中的default-cloud-events-sink设置已被新的config-eventsconfigMap 取代。针对以上每一项社区都有持续的讨论与工作PipelineResources被正式弃用后替代特性的覆盖仍在推进中。四、弃用与移除时间线与波及面4.1 从弃用到移除根据 docs/deprecations.md 的记录PipelineResources的弃用提议来自TEP-00742023 年 3 月 8 日随 PR [TEP074] Remove Generic PipelineResources with Rest of Resources Types 完成了移除最后提供支持的 LTS 版本为v0.44.0其 EOL 为 2024 年 1 月 24 日在这之后发布的、且未达到 EOL 的旧版本可能仍保留该能力但新版本中已不再提供。也就是说当前仓库对应的主线版本中PipelineResources已经从 API 表面消失只保留少量向后兼容的类型定义见下文。4.2 随之一并移除的关联特性docs/deprecations.md 的 Removed PipelineResources related features 一节完整列出了波及面被移除的字段task.spec.resourcestaskRun.spec.resourcespipeline.spec.resourcespipelineRun.spec.resourcestaskRun.status.cloudEvents依赖 PipelineResources 构建的镜像kubeconfigwriter用于 Cluster PipelineResourceimagedigestexporter用于 Image PipelineResourcepullrequest-init用于 Pullrequest PipelineResourcegsutil用于 Storage PipelineResource其他连带移除项tekton_pipelines_controller_cloudevent_count指标详见 docs/metrics.md由pkg/artifacts包为 Storage PipelineResources 建立的 artifacts bucket/PVC通用的 pipelineResources 函数包括 inputs/outputs resources 与from类型TaskRun.Status.ResourcesResult被弃用并 tombstone对应 issue #6325。4.3 源码中的遗留证据在当前仓库的代码中PipelineResources相关类型仍以**纯向后兼容backwards compatibility**的形式保留。最典型的证据在 pkg/apis/pipeline/v1beta1/resource_types.goPipelineResourceResult、ResultType、ResourceParam、PipelineResourceType等类型全部标注了Deprecated: Unused, preserved only for backwards compatibility类型常量仅保留PipelineResourceTypeGit与PipelineResourceTypeStoragePipelineResourceInterface、TaskModifier、InternalTaskModifier等接口同样标记为 Deprecated。而 pkg/apis/resource/v1alpha1/pipeline_resource_types.go 的包注释更是直言The contents of this package are deprecated and unused. Preserved for backwards compatibility.本包内容已弃用且不再使用仅为向后兼容保留。PipelineResource结构体的Status字段在注释中也说明了这一历史问题——there is no controller for PipelineResourcePipelineResource没有对应的控制器因为资源本身不产生状态。五、迁移指南用 Tasks 与 workspaces 替代 PipelineResources5.1 v1alpha1 到 v1beta1 的字段变化如果你还在维护旧版本清单第一步是理解字段位置的迁移。根据 docs/migrating-v1alpha1-to-v1beta1.md 的字段变化表旧字段v1alpha1新字段v1beta1spec.inputs.paramsspec.paramsspec.inputs从Task中移除spec.outputs从Task中移除spec.inputs.resourcesspec.resources.inputsspec.outputs.resourcesspec.resources.outputs资源声明的具体写法变化迁移指南给出了对照示例。v1alpha1 写法# Task.yaml (v1alpha1) spec: inputs: resources: - name: skaffold type: git outputs: resources: - name: baked-image type: image # TaskRun.yaml (v1alpha1) spec: inputs: resources: - name: skaffold resourceSpec: type: git params: - name: revision value: v0.32.0 - name: url value: https://github.com/GoogleContainerTools/skaffold outputs: resources: - name: baked-image resourceSpec: type: image params: - name: url value: gcr.io/foo/barv1beta1 写法# Task.yaml (v1beta1) spec: resources: inputs: - name: src-repo type: git outputs: - name: baked-image type: image # TaskRun.yaml (v1beta1) spec: resources: inputs: - name: src-repo resourceSpec: type: git params: - name: revision value: main - name: url value: https://github.com/tektoncd/pipeline outputs: - name: baked-image resourceSpec: type: image params: - name: url value: gcr.io/foo/bar5.2 用等价功能的 Tasks 替换每种资源类型迁移指南 docs/migrating-v1alpha1-to-v1beta1.md 明确指出应当用Tekton Catalog 中等价功能的Tasks来替换各类PipelineResources并给出了如下替换方向对应章节标题替换gitresource —— 例如用git-cloneTask 检出代码替换pullrequestresource —— 用处理 Pull Request 的 Catalog Task替换gcsresource —— 用与 GCS 交互的 Catalog Task替换imageresource —— 用处理镜像构建与 digest 的 Catalog Task如kaniko等构建 Task配合Task Results传递 digest替换clusterresource —— 用负责生成 kubeconfig 等集群配置的 Catalog Task。这与原文档在 Whats still missing 中给出的方案 B 思路完全一致用Pipeline中显式的Task配合workspace/PVC 传递数据取代隐式的资源注入。仓库的 examples/v1/taskruns/workspace.yaml、examples/v1/pipelineruns/workspaces.yaml 等示例展示了workspace声明、挂载与 PVC 供应的标准写法可作为迁移后清单的参考模板。5.3 CloudEvents 的替代方向原文档指出cloudEventsPipelineResource的使命让 controller 向特定端点发射 CloudEvents正在由控制器内更正式的 notifications 能力取代。在当前仓库中事件通知相关的配置与实现分别落在 config/config-events.yaml 与 pkg/reconciler/notifications 目录下同时 docs/deprecations.md 记录了config-defaults中的default-cloud-events-sink设置已被config-eventsconfigMap 取代CloudEvents 现已默认启用。迁移 CloudEvents 场景时应基于config-events配置而非cloudEventsresource。六、迁移前检查清单与实操建议结合本文梳理的事实在迁移或新建工作负载时可参考以下检查项确认依赖面搜索清单中的resources字段spec.inputs.resources/spec.outputs.resources/spec.resources.inputs/spec.resources.outputs以及taskRun.status.cloudEvents、ResourcesResult等已被移除或 tombstone 的字段确认镜像依赖检查是否依赖kubeconfigwriter、imagedigestexporter、pullrequest-init、gsutil等随资源移除的镜像切换 API 版本新工作负载应直接使用v1版本的Task/TaskRun/Pipeline/PipelineRunv1beta1也已在 v0.50.0 起被弃用详见 docs/deprecations.md用 Task workspace 重构把资源获取逻辑写成显式Task通过workspacePVC 或 volumeClaimTemplate示例见 examples/v1/pipelineruns/workspace-from-volumeclaimtemplate.yaml在任务间传递数据用 Task Results 传递元数据把原来imageresource 承担的 digest 传递改为Task Results可参考 examples/v1/pipelineruns/task_results_example.yaml。七、总结PipelineResources是 Tekton Pipelines 早期为解决Task 输入/输出外部资源问题而设计的 CRD但由于其注入式实现导致行为不透明、调试困难、类型覆盖有限且与TasksworkspacesTask Results体系存在大量功能重叠同时按类型耦合又降低了Task的复用性始终未能晋升 Beta。它最终按照 TEP-0074 的提议被弃用并于 2023 年 3 月从主线移除最后支持版本为 v0.44.0 LTS。当前仓库中PipelineResources仅在pkg/apis中以标注Deprecated的兼容类型形式保留pkg/apis/pipeline/v1beta1/resource_types.go、pkg/apis/resource/v1alpha1/pipeline_resource_types.go供旧客户端编译兼容。对开发者而言正确的做法是用显式的Task如git-cloneworkspaceTask Results的组合替代隐式的资源注入并参考 docs/migrating-v1alpha1-to-v1beta1.md 完成字段迁移。这套替代方案更透明、更可调试、更可复用也正是PipelineResources被逐步淘汰后 Tekton Pipelines 走向 v1 稳定 API 的底层逻辑所在。赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐IDENTITY and PURPOSEIDENTITY and PURPOSE You are a cybersecurity and email expert. Provide a detaile云原生CI/CDDevOps后端Sails.js 中 sails.getBaseUrl() 的用法、弃用原因与现代化替代方案Sails.js 中 sails.getBaseUrl 的用法、弃用原因与现代化替代方案 sails.getBaseUrl 是 Sails 早期版本v0.12后端Bluebird 弃用 API 解析与迁移实战指南Progression 进度机制与 PromiseResolverPromise.defer的现状、原理与替代方案Bluebird 弃用 API 解析与迁移实战指南Progression 进度机制与 PromiseResolverPromise.defer的现状、原理后端上一篇OpenCloud 搜索底层探秘ZAP v12 段文件格式zapx完整解读下一篇【亲测免费】 XILUnity3D热修复新纪元纯C驱动的技术革命创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考