建设口径：Jenkins+K8s自动化部署流水线的目标，不是把人工命令搬进Jenkins任务，而是把构建、制品、部署、验证、回滚和权限纳入可追踪的交付流程。
很多团队最早使用Jenkins做自动化部署，是从一个脚本开始的：拉代码、构建包、构建镜像、执行kubectl apply。这个方式能快速替代手工发布，但随着应用数量、环境数量和团队数量增加，问题会逐渐显现：谁能发布生产，镜像是否扫描，配置从哪里来，失败如何回滚，发布后如何验证，命令执行记录是否可审计。
Jenkins和K8s结合的真正价值，是把应用交付过程标准化，而不是制造更多难以维护的脚本。
先定义流水线边界：CI和CD不要混成一团
Jenkins流水线通常覆盖CI和CD两个阶段。CI关注代码构建、测试、镜像构建和制品生成；CD关注环境发布、配置注入、灰度、验证和回滚。两者可以在同一平台上编排，但责任边界应清晰。
建议把流水线拆成以下阶段：
- 代码触发：提交、合并请求、标签或人工审批触发
- 构建测试：依赖安装、单元测试、静态检查和打包
- 镜像构建：生成镜像、打标签、推送仓库
- 制品治理：漏洞扫描、签名、元数据记录
- 部署准备：生成或选择K8s部署清单
- 环境发布：按环境权限执行发布
- 发布验证：检查Pod、Service、接口和关键指标
- 回滚处理：失败时按策略回退到上一版本
如果这些阶段都写在一个长脚本里，短期看起来简单，长期会很难维护。平台团队应让每个阶段有输入、输出、责任人和失败处理方式。
镜像构建：版本和来源必须可追踪
K8s部署的对象通常是镜像，因此镜像构建是流水线核心。生产环境最忌讳使用不可追踪镜像，例如长期覆盖latest、手工上传镜像或无法对应源码版本的镜像。
镜像阶段应至少记录：
| 信息 | 为什么重要 |
| Git提交ID | 追踪镜像对应代码版本 |
| 构建时间和构建人 | 支撑审计和问题定位 |
| 基础镜像版本 | 识别漏洞和兼容风险 |
| 镜像标签策略 | 支撑回滚和多环境晋级 |
| 扫描结果 | 防止高风险制品进入环境 |
镜像标签建议与提交ID、版本号或构建号关联，而不是只使用latest。流水线应把镜像地址传递给后续部署阶段，避免人工复制粘贴。
部署清单：不要让YAML散落在每个项目里
Jenkins发布K8s应用时，常见做法是执行一段kubectl命令或应用一组YAML。问题在于：不同项目各写一套YAML，命名、资源、探针、配置和发布策略都不一致，平台团队很难治理。
更稳妥的做法是建立部署清单模板或Helm、Kustomize等配置管理方式，至少统一以下内容：
- Deployment、Service、Ingress或网关资源结构
- 资源请求与限制
- Liveness、Readiness和Startup探针
- ConfigMap、Secret和环境变量注入
- 滚动更新策略和回滚方式
- Namespace、ServiceAccount和RBAC边界
- 日志、监控和标签注入规范
部署清单要服务平台治理，而不是成为应用团队各自维护的隐性脚本。模板越清晰，后续批量应用安全基线、监控标签、资源配额和发布策略越容易。
环境权限：流水线不能拥有无限生产权限
Jenkins与K8s集成时，权限设计非常关键。最危险的做法是给Jenkins一个高权限kubeconfig，然后所有项目、所有环境、所有Namespace都用它发布。这样一旦流水线脚本或凭据泄露，影响范围会非常大。
建议按环境和命名空间拆分权限：
- 开发环境：允许应用团队自助发布和回滚
- 测试环境：允许流水线自动部署并执行验证
- 预生产环境：增加审批和变更记录
- 生产环境：限制发布权限，保留审批、审计和回滚流程
Jenkins凭据不应写入脚本、仓库或文档。平台团队应使用凭据管理能力，并定期轮换。流水线执行时只获得完成当前任务所需的最小权限。
发布策略：从一次性apply走向灰度和回滚
最基础的K8s发布是更新Deployment镜像，让K8s滚动更新Pod。对于低风险应用，这已经能满足部分需求。但企业级交付还需要考虑灰度、蓝绿、金丝雀、分批发布、暂停和回滚。
发布策略应根据业务风险选择：
| 场景 | 推荐策略 |
| 内部低风险服务 | 滚动更新 + 自动验证 |
| 核心业务接口 | 分批发布 + 指标观察 |
| 大版本变更 | 蓝绿或金丝雀发布 |
| 配置高风险变更 | 预生产验证 + 手工审批 |
| 问题快速恢复 | 保留上一版本和明确回滚入口 |
Jenkins流水线可以编排这些步骤，但不应把所有策略写成硬编码脚本。更好的方式是由平台提供发布能力，流水线调用标准接口或模板，应用团队选择适合的发布策略。
发布验证：部署成功不等于业务可用
很多流水线只检查命令返回值或Pod是否Running，这远远不够。K8s对象更新成功，只说明控制面接受了变更，不说明服务已经可用。
发布验证至少应覆盖：
- Deployment rollout状态是否成功
- Pod是否Ready，重启次数是否异常
- Service端点是否存在
- Ingress或网关路由是否可访问
- 关键接口冒烟测试是否通过
- 错误率、延迟和核心业务指标是否异常
- 日志和事件是否出现明显错误
对于关键应用，发布验证应与可观测体系联动。流水线不一定自己计算所有指标，但应能读取或触发平台检查，避免“发布成功但用户不可用”。
回滚与审计：失败路径要提前设计
自动化部署的价值不只在成功路径，也在失败路径。发布失败时，流水线应该明确做什么：暂停、回滚、通知、保留现场、记录日志，还是等待人工确认。
回滚设计要注意3个边界：
- 镜像回滚是否足够，配置或数据库是否也发生变化
- 回滚是否会影响正在处理的请求或数据兼容
- 谁有权限执行生产回滚，执行后如何记录
审计记录也很重要。一次发布至少应留下应用、环境、版本、镜像、提交ID、触发人、审批人、执行结果、验证结果和回滚记录。没有审计，自动化发布会变成更快的黑盒操作。
平台化建议：让Jenkins成为流水线入口，而不是所有能力的堆叠点
Jenkins擅长编排，但不应承载所有平台能力。镜像仓库、制品扫描、权限、部署模板、监控、日志、灰度和回滚，应尽量由平台能力提供，Jenkins负责串联流程。
这样做有两个好处：一是避免每条流水线重复实现相同逻辑；二是当企业后续引入GitOps、应用交付平台或内部开发者平台时，已有能力可以平滑迁移。
如果所有能力都写在Jenkinsfile里，后续维护成本会越来越高。平台工程团队应把高频交付动作抽象成标准步骤，让应用团队使用模板，而不是复制脚本。
下一步建议
建议先选择一个非核心但有代表性的服务，建立Jenkins+K8s标准流水线样板：代码触发、构建测试、镜像构建、扫描、部署到测试环境、冒烟验证、预生产审批、生产发布和回滚。样板跑通后，再逐步推广到同类应用。
推广过程中，重点沉淀4类资产：标准Jenkinsfile模板、K8s部署模板、环境权限模型、发布验证清单。只有这些资产可复用，自动化部署才会从单项目脚本升级为企业级交付能力。
延伸阅读可以查看DevOps与平台工程分类，并结合K8sDeployment详解和kubectl exec命令明确流水线发布、回滚与调试边界。
FAQ
Jenkins和K8s集成是否必须使用kubectl？
不一定。kubectl是常见方式，但也可以通过Helm、Kustomize、GitOps工具或平台API发布。关键是发布过程可追踪、权限可控、模板可复用，而不是使用哪一个命令。
Jenkins是否应该直接拥有生产集群管理员权限？
不建议。流水线应遵循最小权限原则，按环境、Namespace和操作类型拆分权限。生产发布通常需要审批、审计和受控凭据，避免一个高权限凭据影响所有环境。
Jenkins流水线如何判断发布成功？
不能只看命令返回值。至少应检查Deployment rollout、Pod Ready、Service端点、关键接口冒烟测试和核心指标。关键业务还应结合错误率、延迟和日志事件判断。
已经有Jenkins还需要平台工程吗？
需要。Jenkins解决编排问题，但平台工程还要提供模板、权限、制品、安全、可观测、灰度和自服务能力。没有平台工程，Jenkins流水线容易变成大量项目脚本的集合。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/465/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
