如何通过Jenkins实现从Amazon ECR到Kubernetes的Docker容器自动部署

当然可以在Jenkins流水线内完成整个从镜像推送ECR到部署到K8s的流程！结合你现有的AWS环境，我给你一步步拆解具体的实现方案和注意事项：

一、前置准备工作 #

在开始写流水线之前，得先搞定几个权限和工具的配置：

• Jenkins访问K8s集群的权限：
  • 如果你用的是AWS EKS集群，最安全的方式是用IAM Roles for Service Accounts (IRSA)，给Jenkins的ServiceAccount绑定能操作K8s资源的IAM角色；如果Jenkins部署在EC2上，也可以给EC2实例附加具备K8s访问权限的IAM角色。
  • 确保Jenkins环境里安装了kubectl（或者Helm，如果你用Helm管理部署），也可以安装Jenkins的Kubernetes插件来简化集成。
• K8s拉取ECR镜像的权限：
  • 要么给K8s节点附加AmazonEC2ContainerRegistryReadOnly的IAM权限，要么给K8s中对应应用的ServiceAccount配置IRSA权限，确保Pod能正常拉取ECR里的镜像。

二、Jenkins流水线内直接部署的实现 #

这是最直接的方案，把部署步骤嵌入到流水线中，以下是完整的Jenkinsfile示例，涵盖从拉代码、构建镜像、推ECR到部署K8s的全流程：

pipeline {
  agent any
  environment {
    // 替换成你的ECR仓库地址
    ECR_REPO = '123456789012.dkr.ecr.us-east-1.amazonaws.com/your-app'
    // 替换成你的K8s Deployment名称
    K8S_DEPLOYMENT_NAME = 'your-app-deployment'
    // 替换成Deployment里的容器名称
    CONTAINER_NAME = 'your-app-container'
  }
  stages {
    stage('拉取GitLab代码') {
      steps {
        // 这里用Jenkins配置的GitLab凭证ID
        git url: '你的私有GitLab仓库地址', credentialsId: 'gitlab-private-creds'
      }
    }

    stage('构建并推送镜像到ECR') {
      steps {
        script {
          // 用AWS CLI获取ECR登录凭证（前提是Jenkins有AWS权限）
          sh 'aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $ECR_REPO'
          // 用Git短Commit Hash作为镜像标签，方便追踪版本
          def gitCommit = sh(returnStdout: true, script: 'git rev-parse --short HEAD').trim()
          sh "docker build -t $ECR_REPO:$gitCommit ."
          sh "docker push $ECR_REPO:$gitCommit"
          // 把镜像标签存入环境变量，供后续部署步骤使用
          env.IMAGE_TAG = gitCommit
        }
      }
    }

    stage('部署到Kubernetes集群') {
      steps {
        script {
          // 方式1：用kubectl直接更新Deployment的镜像
          sh "kubectl set image deployment/$K8S_DEPLOYMENT_NAME $CONTAINER_NAME=$ECR_REPO:$IMAGE_TAG"
          // 可选：等待部署完成，确保流水线能感知部署状态
          sh "kubectl rollout status deployment/$K8S_DEPLOYMENT_NAME"

          // 方式2：如果用Helm管理应用，替换上面的kubectl命令为以下内容
          // sh "helm upgrade --install your-app-release ./helm-chart --set image.repository=$ECR_REPO --set image.tag=$IMAGE_TAG"
        }
      }
    }
  }
  post {
    failure {
      // 部署失败可以加通知，比如发邮件或者Slack消息
      echo '部署到K8s失败，请检查日志！'
    }
  }
}

三、关键注意事项 #

• 权限控制：要确保Jenkins的身份（不管是EC2实例角色还是IRSA角色）具备K8s中编辑Deployment的权限，你可以在K8s中创建一个Role，赋予deployments.apps的编辑权限，然后绑定到Jenkins对应的ServiceAccount上。
• 镜像版本追踪：用Git Commit Hash作为镜像标签是个好习惯，能让代码版本和镜像版本一一对应，排查问题更方便。
• 部署稳定性：加上kubectl rollout status命令可以让流水线等待部署完成再结束，如果部署失败（比如镜像拉取失败、Pod启动失败），流水线会直接报错，避免出现“镜像推成功但部署失败”的隐性问题。

四、第三方工具的替代方案（GitOps模式） #

如果你想降低Jenkins和K8s的直接耦合，或者需要更复杂的部署流程（比如多环境部署、回滚更便捷），可以用GitOps工具比如Argo CD或Flux CD：

1. 把你的K8s部署配置（比如Deployment YAML、Helm Values文件）存到一个单独的Git仓库中；
2. Jenkins流水线在推完镜像到ECR后，自动更新Git仓库中配置文件里的镜像标签；
3. Argo CD/Flux CD会自动检测Git仓库的变更，然后将最新的镜像部署到K8s集群中。

这种模式的优势是所有部署配置都在Git中管理，具备版本追溯能力，而且Jenkins只负责构建镜像，不直接操作K8s，权限管理更清晰。

内容的提问来源于stack exchange，提问作者MasoudSat