当前位置：首页 > news >正文

DevOps篇之利用Jenkins实现多K8S集群的版本发布

news 2025/8/29 5:41:01

重点说明

在 Jenkins 中实现多 K8s 集群的版本发布与版本控制，核心在于解决集群身份认证、配置隔离、发布策略协调、版本统一追溯四大问题。以下是具体实现方案，结合工具链集成与流水线设计，确保多集群环境下的发布一致性与可控性。

一、核心前提

1. 多集群环境准备

1. 集群标识

为每个 K8s 集群分配唯一标识（如prod-cluster-1、staging-cluster），便于在 Jenkins 中区分。

2. 统一网络

Jenkins 节点需能访问所有目标集群的 API Server（通过 VPN 或公网暴露 + 认证限制）。

3. 权限控制

每个集群为 Jenkins 创建专用ServiceAccount，通过 RBAC 限制权限（仅允许部署、更新指定 Namespace 资源）。

2、多集群认证与凭证管理

1. 凭证管理

Jenkins 通过kubeconfig文件与 K8s 集群通信，需安全管理多集群的kubeconfig，确保安全隔离
进入 Manage Jenkins → Manage Credentials，添加「Secret file」类型凭证。
命名规则：kubeconfig-{cluster-id}（如kubeconfig-prod-eu），分别对应各集群的kubeconfig文件。

2. 凭证存储方式

Jenkins Credentials：将每个集群的kubeconfig作为 “Secret file” 类型存储，ID 命名格式为kubeconfig-{cluster-id}（如kubeconfig-prod-1）。
动态生成：通过 Vault 等密钥管理工具，在流水线运行时动态拉取kubeconfig（更安全，适合敏感环境）。

3. 凭证使用示例

在 Jenkins 中配置凭证流水线可通过credentialsId引用对应集群的kubeconfig：

// 加载prod-cluster-1的kubeconfig
withCredentials([file(credentialsId: 'kubeconfig-prod-1', variable: 'KUBECONFIG_PATH')]) {sh 'kubectl --kubeconfig=$KUBECONFIG_PATH get nodes'  // 操作目标集群
}

二、多集群发布策略设计

根据业务需求，常见的多集群发布策略包括：串行发布（按顺序逐个部署）、并行发布（同时部署无依赖集群）、灰度发布（先测试集群再生产集群）。

三、Jenkins 流水线实现（Jenkinsfile）

以下流水线支持多集群选择、策略配置、版本控制与故障熔断，兼容上述所有发布策略。
Jenkins多K8s集群版本发布流水线

pipeline {agent anyparameters {// 参数1：选择目标集群（可多选，用逗号分隔）string(name: 'TARGET_CLUSTERS',defaultValue: 'staging,prod-eu,prod-us',description: '目标集群列表（用逗号分隔，如staging,prod-eu）')// 参数2：发布策略（串行/并行）choice(name: 'DEPLOY_STRATEGY',choices: ['serial', 'parallel'],description: '发布策略：serial（串行）/parallel（并行）')// 参数3：发布顺序（仅串行有效，按集群优先级排序）string(name: 'SERIAL_ORDER',defaultValue: 'staging,prod-eu,prod-us',description: '串行发布顺序（需与TARGET_CLUSTERS一致，用逗号分隔）')// 参数4：指定镜像版本（默认使用当前构建版本）string(name: 'IMAGE_TAG',defaultValue: '',description: '指定镜像版本（如空则自动生成：commit-hash-buildnumber）')}environment {APP_NAME = "user-service"REGISTRY = "harbor.example.com/apps"// 自动生成镜像标签（Git Commit短哈希+构建号）AUTO_IMAGE_TAG = "${env.GIT_COMMIT.take(7)}-${env.BUILD_NUMBER}"// 最终使用的版本（优先用户指定）FINAL_IMAGE_TAG = "${params.IMAGE_TAG ?: env.AUTO_IMAGE_TAG}"// Helm Chart目录CHART_DIR = "charts/${APP_NAME}"}stages {// 阶段1：前置检查（镜像存在性、集群连通性）stage('Pre-Check') {steps {script {def clusters = params.TARGET_CLUSTERS.split(',')// 1. 检查镜像是否存在withCredentials([usernamePassword(credentialsId: 'registry-creds', usernameVariable: 'USER', passwordVariable: 'PWD')]) {sh """docker login ${REGISTRY} -u ${USER} -p ${PWD}if ! docker pull ${REGISTRY}/${APP_NAME}:${FINAL_IMAGE_TAG}; thenecho "镜像 ${FINAL_IMAGE_TAG} 不存在，终止发布"exit 1fi"""}// 2. 检查所有目标集群的连通性for (cluster in clusters) {withCredentials([file(credentialsId: "kubeconfig-${cluster}", variable: 'KUBECONFIG')]) {sh """kubectl --kubeconfig=${KUBECONFIG} cluster-info || {echo "集群 ${cluster} 连接失败"exit 1}"""}}}}}// 阶段2：构建镜像（仅当未指定版本时执行）stage('Build Image') {when {expression { return params.IMAGE_TAG == '' }}steps {withCredentials([usernamePassword(credentialsId: 'registry-creds', usernameVariable: 'USER', passwordVariable: 'PWD')]) {sh """docker login ${REGISTRY} -u ${USER} -p ${PWD}docker build -t ${REGISTRY}/${APP_NAME}:${FINAL_IMAGE_TAG} .docker push ${REGISTRY}/${APP_NAME}:${FINAL_IMAGE_TAG}"""}}}// 阶段3：多集群发布（根据策略选择串行/并行）stage('Deploy to Clusters') {steps {script {def targetClusters = params.TARGET_CLUSTERS.split(',')if (params.DEPLOY_STRATEGY == 'serial') {// 串行发布：按指定顺序逐个部署，前一个成功才继续def serialClusters = params.SERIAL_ORDER.split(',')// 校验串行顺序是否包含在目标集群中def invalid = serialClusters.find { !targetClusters.contains(it) }if (invalid) {error("串行顺序中的集群 ${invalid} 不在目标集群列表中")}for (cluster in serialClusters) {deployToCluster(cluster)  // 调用部署函数}} else {// 并行发布：同时部署所有目标集群parallel targetClusters.collectEntries { cluster ->["部署到 ${cluster}": { deployToCluster(cluster) }]}}}}}// 阶段4：版本记录与审计stage('Record Version') {steps {sh """# 记录本次发布的集群-版本映射echo "$(date +%Y-%m-%d_%H:%M:%S) - ${APP_NAME} - ${FINAL_IMAGE_TAG} - 集群: ${TARGET_CLUSTERS}" >> deployment-history.log# 提交到Git仓库（用于审计）git config --global user.name "jenkins"git config --global user.email "jenkins@example.com"git add deployment-history.loggit commit -m "Record deployment: ${APP_NAME} ${FINAL_IMAGE_TAG} to ${TARGET_CLUSTERS}"git push origin main"""}}}post {failure {// 发布失败通知（邮件/Slack）emailext to: 'devops@example.com',subject: "[$APP_NAME] 多集群发布失败: ${FINAL_IMAGE_TAG}",body: "失败集群: ${TARGET_CLUSTERS}\n构建链接: ${BUILD_URL}"}}
}// 部署到单个集群的函数（复用逻辑）
def deployToCluster(String cluster) {echo "===== 开始部署 ${cluster} 集群 ====="// 每个集群的命名空间（如staging集群用staging命名空间）def namespace = clusterwithCredentials([file(credentialsId: "kubeconfig-${cluster}", variable: 'KUBECONFIG')]) {sh """# 检查命名空间是否存在，不存在则创建if ! kubectl --kubeconfig=${KUBECONFIG} get namespace ${namespace}; thenkubectl --kubeconfig=${KUBECONFIG} create namespace ${namespace}fi# 检查Helm Release是否存在，存在则升级，否则安装if helm --kubeconfig=${KUBECONFIG} list -n ${namespace} | grep -q ${APP_NAME}; thenhelm --kubeconfig=${KUBECONFIG} upgrade ${APP_NAME} ${CHART_DIR} \-n ${namespace} \--set image.repository=${REGISTRY}/${APP_NAME} \--set image.tag=${FINAL_IMAGE_TAG} \--set cluster=${cluster}  # 传递集群标识到Chartelsehelm --kubeconfig=${KUBECONFIG} install ${APP_NAME} ${CHART_DIR} \-n ${namespace} \--set image.repository=${REGISTRY}/${APP_NAME} \--set image.tag=${FINAL_IMAGE_TAG} \--set cluster=${cluster}fi# 等待部署完成（超时10分钟）kubectl --kubeconfig=${KUBECONFIG} rollout status deployment/${APP_NAME} -n ${namespace} --timeout=10m# 验证Pod状态if ! kubectl --kubeconfig=${KUBECONFIG} get pods -n ${namespace} -l app=${APP_NAME} | grep -q 'Running'; thenecho "${cluster} 集群部署后Pod异常，触发回滚"helm --kubeconfig=${KUBECONFIG} rollback ${APP_NAME} 0 -n ${namespace}exit 1fi"""}echo "===== ${cluster} 集群部署成功 ====="
}

四、核心策略解析

1. 串行发布（Serial Deployment）

适用场景：集群间有依赖关系（如先部署欧洲集群，再部署美国集群）、需逐步验证的核心业务。
实现逻辑：按SERIAL_ORDER参数指定的顺序逐个部署，前一个集群部署成功且健康检查通过后，才开始下一个集群的部署。
优势：故障影响范围小，便于逐步发现问题（如某集群配置错误）。

2. 并行发布（Parallel Deployment）

适用场景：集群独立无依赖（如多区域冗余部署）、非核心业务追求发布效率。
实现逻辑：通过 Jenkins 的parallel语法同时部署所有目标集群，各集群部署过程互不阻塞。
优势：发布速度快，适合大规模集群批量更新。

3. 灰度发布（Canary Deployment）

可基于上述流水线扩展，先部署测试集群验证，再按比例部署生产集群：

// 示例：灰度发布扩展
stage('Canary Deploy') {steps {script {// 1. 先部署测试集群deployToCluster('staging')// 2. 人工确认后，部署10%的生产集群input message: '测试集群验证通过？', ok: '继续'deployToCluster('prod-eu-10pct')  // 10%流量的生产集群// 3. 监控无异常后，全量部署生产集群input message: '灰度集群无异常？', ok: '全量部署'deployToCluster('prod-eu')deployToCluster('prod-us')}}
}