Tekton Pipelines 的 Manual Approval Gate
目录
功能概述
Manual Approval Gate 允许流水线作者暂停一个 PipelineRun,直到指定的审批人审核并批准该操作。背后由 Operator 提供的控制器为每个审批步骤创建一个 ApprovalTask 资源,跟踪审批人的响应,并将结果写回到发起的 CustomRun。
使用场景
- 在部署到生产环境或执行破坏性维护之前强制设置人工检查点。
- 通过结合个人和组以及
numberOfApprovalsRequired实现多人审批策略。 - 通过查询
ApprovalTask的状态字段或 CLI 输出审计谁批准或拒绝了变更。
前提条件
- 集群管理员已部署
Manual Approval Gate。如果未部署,请参阅部署指南。 - 你可以在目标命名空间中创建或编辑
Pipeline/PipelineRun对象。 - 审批人可以在目标命名空间中对
approvaltasks.openshift-pipelines.org资源进行 patch(通常通过kubectl)。例如Alauda Container Platform默认授予此权限;仅当你显式移除内置权限时才需自定义 RBAC。
操作步骤
1. 在流水线中声明审批步骤
当流水线执行到 wait-for-approval 时,Tekton 会发出一个 CustomRun。审批控制器根据你的参数创建一个 ApprovalTask,并保持 PipelineRun 处于挂起状态,直到达到法定人数或发生拒绝。
2. 监控审批状态
重要状态字段:
status.state:整体关卡状态,如pending、approved或rejected。status.approvalsRequired/status.approvalsReceived:法定人数跟踪(收到的计数仅在至少一名审批人响应后出现)。status.approversResponse:每个用户/组的结果及消息,便于审计。
3. 审批或拒绝
用户审批
首先查看审批人列表以确定正确的索引:
以用户身份批准:
以用户身份拒绝:
组审批
当组被配置为审批人时,该组的成员可以通过向组条目下的 users 数组添加自己的响应来提交审批。多个组成员可以独立批准,每个批准都会计入 approvalsReceived 总数。
最初,组审批人条目没有 users 字段:
第一个组成员创建 users 数组并将组的 input 设置为 approve:
后续组成员追加到已有的 users 数组并更新组的 input:
以组成员身份拒绝:
应用这些 patch 后,检查组条目和状态以查看所有成员的响应:
在此示例中,release-managers 组的 bob 和 carol 都已批准。每个组成员的批准都会单独增加 approvalsReceived,因此两个组成员的批准计为两个审批数,计入所需总数。status.approversResponse 显示了详细的审批信息,包括各个组成员的响应。
组审批关键点:
- 每个组成员必须执行 两个必需操作:向
users数组添加自己的条目,且设置组的input(approve或reject)。可选地,也可以设置组的message。 - 第一个组成员通过路径
/spec/approvers/<index>/users创建users数组,值为数组。 - 后续成员通过路径
/spec/approvers/<index>/users/-追加到数组末尾。 users数组中的每个用户条目仅包含name和input字段(不包含用户条目内的message字段)。- 组级别的
message字段是可选且共享的;后续响应若提供新消息会覆盖该字段。 - 每个组成员的批准都会独立增加
approvalsReceived。 - 同一组的多个成员可以批准,每个都计入所需总数。
status.approversResponse字段跟踪详细的审批信息,包括各个组成员。- 使用
--as <username> --as-group <groupname>来以组成员身份进行 patch。
控制器会相应地将对应的 CustomRun 和 PipelineRun 设置为 Succeeded 或 Failed:审批累计直到满足 numberOfApprovalsRequired,任何拒绝都会立即使该流水线段失败。
提示: 当你需要以特定身份审批时,使用
--as <username>(必需)和--as-group <group>。验证 webhook 只允许你修改与该模拟用户和组匹配的条目。RBAC 必须授予你模拟权限。例如,kubectl patch ... --as bob --as-group release-managers表示你以用户bob身份,属于release-managers组。
4. 延长 PipelineRun 超时时间以适应长时间审批
如果审批可能耗时数小时或数天,请配置 PipelineRun.spec.timeouts.pipeline 和 PipelineRun.spec.timeouts.tasks,使其超过审批窗口,避免在审批人响应前运行终止。一个简单的用于测试审批关卡的 PipelineRun 如下:
确保审批任务的 timeout 参数短于流水线超时,否则 PipelineRun 可能先过期,导致审批未解决。
操作结果
kubectl get approvaltasks -o yaml显示每个审批关卡的state和法定人数相关字段(approvalsReceived列在有人响应后出现)。PipelineRun状态反映审批结果:批准后下游任务继续执行;拒绝则运行失败,失败原因从ApprovalTask传递。- 调度日志或
kubectl get approvaltask -o yaml输出提供审批历史,便于审计。
故障排查
- 审批任务从未出现: 确认管理员安装的
ManualApprovalGateCR 是否处于READY状态。没有控制器,CustomRun对象会一直挂起。 - 审批人缺少权限: 授予他们在相关命名空间对
approvaltasks.openshift-pipelines.org的get、list、update和patch权限。 - 流水线在审批完成前结束: 设置
PipelineRun.spec.timeouts.pipeline和PipelineRun.spec.timeouts.tasks覆盖预期审批时间窗口,且确保审批timeout合理。否则即使审批人未响应,运行也可能超时。 - 审批后仍卡在 pending 状态: 检查
status.approversResponse,查看是否有用户更改投票或拒绝。你可能需要更新审批人列表并重新运行流水线。
用户和组标识符
Manual Approval Gate 依赖平台的 Identity Provider 来匹配审批人名称。始终使用提供者暴露的规范标识符,而非 UI 显示名。例如,在 Alauda Container Platform:
添加用户审批人时使用 USERNAME 列(如 admin)。
引用组审批人时使用 NAME 列(如 g-v9mfs,例如 group:g-v9mfs)。其他平台也会暴露类似资源——请查阅身份服务文档以获取准确字段名。