GitLab 到 Kubernetes 的发布证据链

记录需求编号、合并请求、审批人、窗口、目标服务和非目标事项。确认合并后的精确提交与评审记录一致，并登记 Jenkinsfile 及共享库修订。以下命令在已核对仓库的只读工作副本执行，不获取远端、不修改分支；工作树脏文件不得混入发布上下文。

git status --short
git rev-parse HEAD
git log -1 --format='%H %cI %s'

列出源码读取、Nexus 发布、Harbor 推送和 Kubernetes 部署四类凭据，按项目及阶段限制作用域。Jenkins 发布阶段只接受可信修订，不在可被任意分支修改的脚本中开放生产身份。检查执行节点互信关系、并发隔离、工作区清理与日志脱敏；凭据遮蔽不是对恶意流水线的隔离保证。

以精确提交在测试节点执行已经评审的构建与测试流程，记录构建号、工具链、依赖锁定及测试结果。Java 产物登记 Maven 完整坐标、classifier、packaging 和校验和，发布目标应为指定 hosted 仓库；proxy 缓存和 group 读取成功均不等于允许发布。无 Java 产物的服务明确跳过 Maven 环节，不创建无用途包。

将通过测试的制品纳入受评审镜像构建，保存基础镜像摘要、构建上下文和产物来源。上传批准的 Harbor 项目后记录仓库、标签、摘要、平台以及扫描器和漏洞库时间；正式标签按政策设置不可变和保留保护。多架构镜像同时记录索引摘要与目标平台清单映射，避免把本地镜像 ID 错当仓库摘要。

在任何发布动作前核对 context、namespace、工作负载、服务账号、拉取身份和配置依赖。以下只读命令须替换批准的目标，不依赖当前默认 namespace；保存旧版本摘要和部署修订，同时评审数据库变更能否与旧应用共存。

kubectl config current-context
kubectl --context '<APPROVED_CONTEXT>' -n '<NAMESPACE>' get deployment '<DEPLOYMENT>' -o jsonpath='{.metadata.uid} {.spec.template.spec.containers[*].image}'
kubectl --context '<APPROVED_CONTEXT>' -n '<NAMESPACE>' rollout history deployment/'<DEPLOYMENT>'

由有权限的执行人按组织既定发布机制推进单一试点批次，本站方案不自动提交部署。持续观察拉取、调度、探针、依赖和错误率：拉取失败查证书、权限、摘要与架构；Pending 查资源与约束；就绪失败转查配置及应用日志。每次重试标明原变更编号与是否产生新修订，不在未知状态下反复触发。

由业务验收人检查代表性请求、鉴权、关键依赖及旧客户端兼容性，观察窗口覆盖约定的负载样本。将错误率、延迟和资源预算与发布前基线比较；在隔离环境演练使用保留摘要恢复，并验证必要配置及数据兼容。恢复耗时只对本次测试规模负责，不据此宣称具备全环境容灾能力。

整理提交、合并请求、构建号、Maven 坐标、镜像摘要、部署修订、审批、测试和恢复记录，以变更编号互相链接。交接监控入口、错误分支、值班责任、观察到期时间和制品保留窗口；受限链接用接班人身份验证可读，公开页面只保留脱敏示例。对未实施环节持续标为待验证。