Jenkins自动化部署核心在于插件协同而非界面操作，通过Git、Maven、Docker、K8s等插件串联工具链，形成可复用、可追溯、可审计的流水线。
Jenkins 的自动化部署能力，核心不在界面操作，而在于插件的组合与协同。真正让构建、测试、发布“跑起来”的，是插件对工具链的串联——它把 Git、Maven、Docker、K8s、SSH 等离散能力变成一条可复用、可追溯、可审计的流水线。
关键插件选型：按角色分清“谁干啥”
不必装满所有插件，而是根据部署目标精准选择：
- 代码拉取与触发：Git Plugin（必装）、Gitee/GitLab Plugin（对接国内平台）、Webhook Plugin（响应推送事件）
- 构建执行：Maven Integration（Java）、NodeJS Plugin（前端）、Gradle Plugin（Android/多语言项目）
- 镜像与容器：Docker Pipeline（原生支持 Docker 命令）、Docker Build Step（简单镜像构建）、CloudBees Docker Build and Publish（自动推镜像）
- 部署交付：Kubernetes Plugin（直连 K8s 集群部署 YAML 或 Helm）、Publish Over SSH（传统服务器 scp + 启停脚本）、Deploy to Container（如 Tomcat 热部署）
- 凭证与安全：Credentials Plugin（统一管理 token、密钥、证书）、SSH Credentials Plugin（SSH 登录凭据加密存储）
K8s 部署插件实操要点
要让 Jenkins 把应用真正“落”到 K8s 集群里，光装插件不够，得打通身份认证和权限通路：
- 在 K8s Master 节点提取
~/.kube/config中的certificate-authority-data、client-certificate-data、client-key-data，base64 解码后生成 PKCS#12 格式证书（cert.pfx） - Jenkins 凭据中添加类型为 Certificate 的全局凭据，上传该
cert.pfx并填写对应密码 - 系统配置里新增 Kubernetes Cloud，指定 API Server 地址、命名空间、服务账户 Token（或直接选刚建的证书凭据）
- Pipeline 脚本中用
kubernetesDeploy步骤即可部署 YAML 文件，支持变量替换和环境隔离（如env == 'prod'时加载不同 configmap）
SSH 部署插件避坑指南
看似简单，但常因权限或路径问题失败：
- 确保 Jenkins 所在机器能免密 SSH 连通目标服务器（建议用
ssh-keygen+ssh-copy-id配置） - 在 Jenkins 凭据中添加 SSH Username with private key 类型凭据，私钥内容粘贴完整（含
-----BEGIN OPENSSH PRIVATE KEY-----头尾） - 远程命令建议封装为单个 shell 脚本（如
/opt/deploy.sh），并在 Jenkins 配置中勾选 Use remote directory 指定工作路径，避免相对路径混乱 - 注意目标服务器 SELinux 或防火墙是否拦截了端口（默认 22），以及 Jenkins 用户是否有执行
systemctl或docker的权限
流水线中插件能力的自然融合
插件不是孤立调用，而应嵌入 Pipeline 逻辑中形成闭环：
- 用
withCredentials安全注入 Docker Registry 登录信息，再执行sh 'docker login -u ...' - 构建完镜像后，调用
docker.withRegistry('https://harbor.example.com')直接 push，无需暴露密码到日志 - 部署前加健康检查步骤：
sh 'curl -f http://localhost:8080/actuator/health || exit 1'，失败则中断后续流程 - 用
input message: 'Promote to production?'实现人工卡点，配合 Role Strategy 插件控制审批权限
插件不是越多越好，而是越准越稳。一次只聚焦一个部署目标（比如先跑通 SSH 部署 jar 包，再升级为 K8s+Helm），每步验证输出、日志和状态码，比堆插件更能快速落地自动化。
