DevOps篇之利用Jenkins實現多K8S集群的版本發布

重點說明

在 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')}}
}