1. 项目概述为什么“JenkinsMavenJib”成了SpringBoot微服务Docker化部署的黄金三角你是不是也经历过这样的场景开发完一个SpringBoot微服务本地mvn clean package打个jar包再手动docker build -t myapp:1.0 .写Dockerfile、构建镜像、推送到私有Registry、最后在K8s集群里kubectl apply ——一套流程走下来光是重复操作就耗掉半小时更别说Dockerfile写错导致镜像启动失败、基础镜像版本不一致引发线上环境差异、或者因为COPY target/*.jar app.jar路径写错导致容器一启动就报NoClassDefFoundError。我带过的三个团队平均每个新成员入职前三天至少要卡在Dockerfile的FROM选择和ENTRYPOINT写法上两次。这不是能力问题而是传统方式把构建逻辑分散在多个文件、多个工具、多个环境里天然容易出错。而标题里这个组合——Jenkins Maven Jib——本质上是在做一件反直觉但极其高效的事把Docker镜像构建这件事从Docker引擎里“搬进”Maven生命周期里。Jib不是让你写Dockerfile而是让Maven在package阶段结束后直接调用Java API把你的SpringBoot应用、依赖、JRE分层打包成符合OCI标准的镜像并推送到Registry。整个过程不需要Docker daemon不依赖docker build命令甚至你本机没装Docker Desktop也能跑通。这背后解决的是微服务时代最痛的三个点一是构建环境一致性Jenkins Agent只要装了JDK和Maven就行不用管Docker版本二是安全合规性Jib默认使用distroless基础镜像不含shell、包管理器攻击面极小三是交付速度实测比传统Docker build快40%~60%尤其对多模块项目Jib能复用已推送的layer。关键词里的Jenkins、Maven、Jib、SpringBoot、Docker每一个都不是孤立存在。Jenkins提供的是可审计、可回滚、可触发的CI流水线骨架Maven是Java生态的事实标准构建工具链它定义了compile、test、package这些标准化阶段Jib则是Maven的一个插件它聪明地“劫持”了package之后的阶段把原本该生成jar包的动作悄悄替换成生成镜像SpringBoot提供了spring-boot-maven-plugin的fat jar能力而Jib正是基于这个结构做分层优化Docker则是最终交付物的载体和运行时标准。这五者环环相扣缺一不可。如果你只学Jib怎么用却没配好Maven的settings.xml里阿里云镜像源或者Jenkins里没设好MAVEN_HOME环境变量那整个流程就会卡在第一步。所以这篇详解不会只告诉你pom.xml里加几行配置而是从Mac上Maven怎么装、Jenkins Agent怎么初始化、Jib的from.image参数为什么不能随便写、到SpringBoot的application.yml如何适配容器环境变量——全部拆开揉碎给你端上来。2. 整体设计思路与方案选型逻辑为什么放弃Dockerfile选择Jib2.1 传统Dockerfile方案的三大硬伤先说清楚我们为什么要换方案。很多团队还在用这种写法FROM openjdk:17-jdk-slim VOLUME /tmp ARG JAR_FILEtarget/myapp.jar COPY ${JAR_FILE} app.jar ENTRYPOINT [java,-Djava.security.egdfile:/dev/./urandom,-jar,/app.jar]表面看很简洁但实际落地时问题接踵而至环境漂移风险高openjdk:17-jdk-slim这个tag是浮动的。今天拉下来是17.0.112明天可能变成17.0.28JDK小版本升级可能触发SpringBoot的ConditionalOnClass失效导致某个自动配置类不加载。我们曾在线上遇到过一次就因为Registry里缓存的base image被上游更新导致所有新构建的镜像都少了spring-boot-starter-web的依赖API全部404排查了6小时才发现是基础镜像变了。构建过程不可控docker build命令本身不参与Maven的生命周期。你在pom.xml里配置了maven-surefire-plugin跑单元测试但Dockerfile里COPY指令执行时测试根本没跑——它只认target/目录下有没有jar包。这就造成一种假象本地mvn test通过了但镜像构建后一跑集成测试就挂因为docker build跳过了测试阶段。镜像体积与安全冗余openjdk:17-jdk-slim虽然叫slim但依然包含完整的JDK、apt-get、bash、curl等。一个SpringBoot应用真正需要的只是JRE运行时你的代码依赖jar。多余的东西不仅增大镜像体积实测多出80MB更关键的是它给攻击者留了后门。去年我们做过一次安全扫描用openjdk:17-jdk-slim的基础镜像CVE漏洞数高达37个换成Jib默认的gcr.io/distroless/java17:nonroot只剩2个且都是低危。2.2 Jib的核心设计哲学构建即代码镜像即产物Jib的设计者来自Google它的出发点非常务实Java开发者不该为了打包Docker镜像去学Dockerfile语法、记各种--build-arg参数、操心RUN apt-get update的缓存失效问题。它把镜像构建抽象成三个确定性步骤分层LayeringJib自动把应用拆成dependencies、snapshot-dependencies、resources、classes四层。其中dependencies层最稳定第三方jar基本不变classes层最易变业务代码天天改。每次构建只有变更的层会重新上传其余层直接复用Registry里的缓存。这和docker build的layer cache原理一样但Jib的分层逻辑是语义化的不是靠COPY指令顺序决定的。无Docker Daemon构建Daemonless BuildJib不调用docker命令而是用Java原生HTTP Client直接和Registry通信。这意味着Jenkins Agent只要能联网、有JDK、有Maven就能构建镜像Mac用户不用再折腾Virtualization Support Not Detected的报错Docker Desktop启动失败那个经典问题在K8s里跑Jenkins Agent Pod时不用给Pod加privileged: true权限极大提升安全性。安全基线预置Secure DefaultsJib默认使用distroless系列镜像。这类镜像没有shell、没有包管理器、没有/bin/sh连ls命令都没有。它只包含JRE和一个极简的启动器。你无法在容器里执行/bin/bash也无法apt-get install vim来调试——但这恰恰是生产环境想要的。我们线上所有微服务现在都强制要求使用distroless安全团队扫描报告里JRE相关的高危漏洞直接归零。2.3 为什么是JenkinsMaven组合而非GitLab CI或GitHub Actions有人会问现在GitLab CI、GitHub Actions多火为啥标题强调Jenkins答案很现实企业级CI/CD的存量市场Jenkins仍是事实标准。我们调研过12家金融、电信行业的客户9家在用Jenkins其中7家是自建集群3家用了Jenkins X。原因有三插件生态成熟Jenkins有超过1800个官方插件。比如你要对接公司内部的LDAP认证、用SonarQube做代码质量门禁、集成Jira自动创建Bug单——这些都有现成插件配置点几下就行。而GitHub Actions的Marketplace里很多企业级插件要么收费要么维护滞后。Agent弹性调度能力强Jenkins可以按需启动Docker-in-DockerDinDAgent、K8s Pod Agent、甚至物理机Agent。比如你有个老项目必须用Windows Server 2012编译.NET组件Jenkins能单独起一个Windows Agent其他项目完全不受影响。GitLab Runner虽然也支持多平台但资源隔离粒度不如Jenkins精细。审计与合规友好Jenkins的所有构建日志、参数、环境变量、甚至构建时的git diff都能完整留存。这对金融行业做等保测评、ISO27001审计是刚需。GitHub Actions的审计日志需要额外开通Enterprise版且导出格式不统一。所以这个方案不是技术情怀而是踩过坑后的务实选择。它不追求“最新”而追求“最稳”。3. 核心细节解析与实操要点从Mac环境搭建到Jib参数精调3.1 Mac环境准备Maven安装与阿里云镜像源配置避坑指南Mac用户最容易栽在第一步Maven装好了但mvn -v报错JAVA_HOME not set或者mvn clean package慢得像蜗牛。这不是Maven的问题而是环境链路没打通。第一步确认JDK版本与JAVA_HOMESpringBoot 3.x要求JDK 17而Mac自带的/usr/bin/java往往是JDK 8。必须用SDKMAN或Homebrew装新版# 推荐用SDKMAN比Homebrew更新及时 curl -s https://get.sdkman.io | bash source $HOME/.sdkman/bin/sdkman-init.sh sdk install java 17.0.2-tem sdk default java 17.0.2-tem验证echo $JAVA_HOME # 应输出类似 /Users/xxx/.sdkman/candidates/java/current java -version # 必须是17.x.x提示不要用/Library/Java/JavaVirtualMachines/下的路径设JAVA_HOMESDKMAN管理的路径才是可靠的。我见过三次故障都是因为用户手动改了/etc/profile里的JAVA_HOME结果SDKMAN切换JDK后Maven还指向旧版本。第二步Maven安装与settings.xml深度配置下载Maven 3.8.8兼容SpringBoot 3.xbrew install maven3.8 # 或手动下载解压到 /opt/maven然后设环境变量 export MAVEN_HOME/opt/maven export PATH$MAVEN_HOME/bin:$PATH最关键的一步修改$MAVEN_HOME/conf/settings.xml配置阿里云镜像源。注意这里不是简单替换mirror而是要覆盖中央仓库Spring官方仓库公司私有仓库mirrors !-- 阿里云镜像覆盖maven central -- mirror idaliyunmaven/id mirrorOfcentral/mirrorOf nameAliyun Maven/name urlhttps://maven.aliyun.com/repository/public/url /mirror !-- Spring Milestone镜像 -- mirror idspring-milestones/id mirrorOfspring-milestones/mirrorOf nameSpring Milestones/name urlhttps://maven.aliyun.com/repository/spring-milestones/url /mirror !-- Spring Snapshot镜像 -- mirror idspring-snapshots/id mirrorOfspring-snapshots/mirrorOf nameSpring Snapshots/name urlhttps://maven.aliyun.com/repository/spring-snapshots/url /mirror /mirrors profiles profile idaliyun/id repositories repository idcentral/id urlhttps://maven.aliyun.com/repository/public/url releasesenabledtrue/enabled/releases snapshotsenabledfalse/enabled/snapshots /repository repository idspring-milestones/id urlhttps://maven.aliyun.com/repository/spring-milestones/url releasesenabledtrue/enabled/releases snapshotsenabledfalse/enabled/snapshots /repository repository idspring-snapshots/id urlhttps://maven.aliyun.com/repository/spring-snapshots/url releasesenabledfalse/enabled/releases snapshotsenabledtrue/enabled/snapshots /repository /repositories /profile /profiles activeProfiles activeProfilealiyun/activeProfile /activeProfiles注意mirrorOf的值必须精确匹配pom.xml里repository的id。很多用户复制网上教程把mirrorOfcentral/mirrorOf写成mirrorOf*/mirrorOf结果Spring Boot的spring-boot-starter-parent拉不到报Could not find artifact org.springframework.boot:spring-boot-starter-parent:pom:3.1.0。这是血泪教训。3.2 Jenkins Agent环境初始化环境变量与工具链绑定Jenkins Master本身不干活所有构建都在Agent上执行。Agent的环境直接决定Jib能否成功推送镜像。Agent类型选择推荐用Docker Agent不是Docker-in-Docker。理由轻量、隔离、可复用。在Jenkins全局配置里添加一个Docker Agent模板Docker Image:maven:3.8.8-openjdk-17官方镜像预装Maven 3.8.8和OpenJDK 17Remote FS Root:/home/jenkins/agent不要用/home/jenkins避免权限冲突Labels:maven-java17后面Pipeline里用这个label指定Agent关键环境变量注入Jib需要知道Registry地址、用户名、密码。绝不能写死在pom.xml里必须通过Jenkins凭据管理Jenkins后台 → Credentials → System → Global credentials → Add CredentialsKind: Username with passwordUsername:your-registry-usernamePassword:your-registry-password或TokenID:registry-credentials在Pipeline脚本里用withCredentials动态注入pipeline { agent { label maven-java17 } environment { REGISTRY_URL registry.yourcompany.com IMAGE_NAME myapp } stages { stage(Build and Push) { steps { withCredentials([usernamePassword( credentialsId: registry-credentials, usernameVariable: REGISTRY_USER, passwordVariable: REGISTRY_PASS )]) { sh mvn compile jib:build \ -Djib.to.image${REGISTRY_URL}/${IMAGE_NAME} \ -Djib.to.auth.username${REGISTRY_USER} \ -Djib.to.auth.password${REGISTRY_PASS} } } } } }实操心得jib:build参数必须用-D传入不能写在pom.xml里。因为不同环境dev/test/prod的Registry URL和认证方式不同。我们曾在一个项目里把prod的Registry密码误提交到Git导致安全告警。现在所有敏感参数一律通过Jenkins凭据Pipeline变量传递。3.3 Jib核心参数详解从from.image到container.jvmFlagsJib的pom.xml配置看着简单但每个参数背后都有深意。下面逐个拆解plugin groupIdcom.google.cloud.tools/groupId artifactIdjib-maven-plugin/artifactId version3.3.1/version configuration from imagegcr.io/distroless/java17:nonroot/image credHelpergcloud/credHelper /from to imageregistry.yourcompany.com/myapp:${project.version}/image auth username${env.REGISTRY_USER}/username password${env.REGISTRY_PASS}/password /auth /to container jvmFlags jvmFlag-Xms512m/jvmFlag jvmFlag-Xmx1024m/jvmFlag jvmFlag-XX:UseG1GC/jvmFlag /jvmFlags ports port8080/port /ports environment SPRING_PROFILES_ACTIVEprod/SPRING_PROFILES_ACTIVE /environment useCurrentTimestamptrue/useCurrentTimestamp /container /configuration /pluginfrom.image为什么必须用distrolessgcr.io/distroless/java17:nonroot是Google维护的无发行版Java镜像。nonroot后缀表示它以非root用户启动符合最小权限原则。对比openjdk:17-jdk-slim它的大小只有87MB vs 320MB启动时间快1.8秒实测数据。更重要的是distroless镜像没有/bin/sh所以kubectl exec -it pod-name -- /bin/sh会失败——这反而是一种安全保护逼你用kubectl logs和健康检查来诊断问题而不是习惯性进容器乱搞。to.auth密码明文传输安全吗看似危险实则安全。Jib在推送镜像时用的是Registry的/v2/API认证走的是Bearer Token机制。username/password只是用来换取临时TokenToken有效期通常只有10分钟且只对本次推送有效。真正的镜像数据是HTTPS加密传输的。我们抓包验证过密码不会出现在网络请求体里。container.jvmFlags别盲目抄网上的-Xmx4gJVM堆内存设置必须结合容器cgroup限制。如果你在K8s里给Pod设了resources.limits.memory: 2Gi那-Xmx1024m就是黄金值约50%。设太高JVM会OOM Kill设太低频繁GC。我们有个服务-Xmx4g配在2Gi内存的Pod里结果每天凌晨GC停顿12秒监控报警响个不停。后来改成-Xmx1024mGC停顿降到200ms内。container.useCurrentTimestamp为什么必须设为trueSpringBoot Fat Jar里MANIFEST.MF的Created-By字段包含构建时间戳。如果Jib不把这个时间戳同步到镜像的created元数据里会导致两个问题一是镜像层哈希不稳定同一份代码不同时间构建镜像ID不同二是安全扫描工具如Trivy无法准确关联CVE修复时间。设为true后Jib会把构建时间写入镜像配置保证可重现性。4. 实操过程与核心环节实现手把手跑通一条Jenkins Pipeline4.1 SpringBoot项目结构准备pom.xml与application.yml适配一个能被Jib友好打包的SpringBoot项目结构必须规范。我们以一个典型的订单服务为例order-service/ ├── pom.xml ├── src/ │ └── main/ │ ├── java/com/example/order/ │ └── resources/ │ ├── application.yml │ └── application-prod.yml └── Dockerfile # 这个文件可以删了Jib不需要它pom.xml关键片段只列Jib相关properties java.version17/java.version spring-boot.version3.1.0/spring-boot.version jib-maven-plugin.version3.3.1/jib-maven-plugin.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 其他依赖... -- /dependencies build plugins !-- SpringBoot Maven Plugin确保生成fat jar -- plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version${spring-boot.version}/version executions execution goals goalrepackage/goal /goals /execution /executions /plugin !-- Jib Maven Plugin核心打包插件 -- plugin groupIdcom.google.cloud.tools/groupId artifactIdjib-maven-plugin/artifactId version${jib-maven-plugin.version}/version configuration from imagegcr.io/distroless/java17:nonroot/image /from to imageregistry.yourcompany.com/order-service:${project.version}/image /to container jvmFlags jvmFlag-Xms512m/jvmFlag jvmFlag-Xmx1024m/jvmFlag jvmFlag-XX:UseG1GC/jvmFlag /jvmFlags ports port8080/port /ports environment SPRING_PROFILES_ACTIVEprod/SPRING_PROFILES_ACTIVE /environment useCurrentTimestamptrue/useCurrentTimestamp /container /configuration executions execution idbuild-to-registry/id phasepackage/phase goals goalbuild/goal /goals /execution /executions /plugin /plugins /buildapplication.yml容器化适配要点server: port: 8080 address: 0.0.0.0 # 必须监听0.0.0.0否则容器内端口不通 spring: profiles: active: activatedProperties # 这里用Maven resource filtering # 数据库配置用环境变量替代硬编码 datasource: url: ${DB_URL:jdbc:mysql://mysql:3306/order_db} username: ${DB_USER:root} password: ${DB_PASS:password} # 日志路径指向stdout方便K8s收集 logging: file: name: /dev/stdout关键技巧activatedProperties是Maven的resource filtering占位符。在pom.xml里加build resources resource directorysrc/main/resources/directory filteringtrue/filtering /resource /resources filters filtersrc/main/filters/filter-${env}.properties/filter /filters /build这样mvn package -Pprod时activatedProperties会被替换成prodapplication.yml就自动激活application-prod.yml。4.2 Jenkins Pipeline编写从代码检出到镜像推送全链路新建一个Jenkins Freestyle Project或Pipeline Project。推荐用Declarative Pipeline语法清晰易维护。pipeline { agent { label maven-java17 } // 指定Docker Agent environment { // 全局环境变量 REGISTRY_URL registry.yourcompany.com APP_NAME order-service GIT_REPO https://git.yourcompany.com/backend/order-service.git } options { timeout(time: 20, unit: MINUTES) skipDefaultCheckout() } parameters { string(name: BRANCH, defaultValue: main, description: Git branch to build) choice(name: ENVIRONMENT, choices: [dev, test, prod], description: Target deployment environment) } stages { stage(Checkout) { steps { checkout([ $class: GitSCM, branches: [[name: refs/heads/${params.BRANCH}]], doGenerateSubmoduleConfigurations: false, extensions: [ [$class: CleanBeforeCheckout], [$class: RelativeTargetDirectory, relativeTargetDir: src] ], userRemoteConfigs: [[ url: ${GIT_REPO}, credentialsId: git-credentials ]] ]) } } stage(Build with Maven) { steps { dir(src) { // 设置Maven settings.xml路径如果Agent上没全局配置 sh mvn clean compile -s /home/jenkins/agent/settings.xml } } } stage(Test) { steps { dir(src) { sh mvn test -s /home/jenkins/agent/settings.xml } } } stage(Build and Push Docker Image) { steps { withCredentials([usernamePassword( credentialsId: registry-credentials, usernameVariable: REGISTRY_USER, passwordVariable: REGISTRY_PASS )]) { dir(src) { // 构建并推送镜像 sh mvn compile jib:build \ -Djib.to.image${REGISTRY_URL}/${APP_NAME}:${BUILD_NUMBER}-${params.ENVIRONMENT} \ -Djib.to.auth.username${REGISTRY_USER} \ -Djib.to.auth.password${REGISTRY_PASS} \ -Djib.from.imagegcr.io/distroless/java17:nonroot \ -Djib.container.jvmFlags-Xms512m -Xmx1024m -XX:UseG1GC \ -Djib.container.ports8080 \ -Djib.container.environmentSPRING_PROFILES_ACTIVE${params.ENVIRONMENT} } } } } stage(Deploy to Kubernetes) { when { expression { params.ENVIRONMENT prod } } steps { script { // 这里调用K8s部署脚本比如用kubectl或Helm sh kubectl set image deployment/${APP_NAME} ${APP_NAME}registry.yourcompany.com/${APP_NAME}:${BUILD_NUMBER}-prod } } } } post { success { echo ✅ Build and push successful! Image: ${REGISTRY_URL}/${APP_NAME}:${BUILD_NUMBER}-${params.ENVIRONMENT} slackSend channel: #deploy-alerts, message: ${APP_NAME} deployed to ${params.ENVIRONMENT} [${BUILD_NUMBER}] } failure { echo ❌ Build failed! slackSend channel: #deploy-alerts, message: ${APP_NAME} build failed [${BUILD_NUMBER}] } } }Pipeline关键点说明skipDefaultCheckout() 自定义checkout避免Jenkins默认checkout把整个workspace清空我们只checkout到src/子目录保持Agent上其他工具链如settings.xml不被覆盖。withCredentials作用域密码只在Build and Push阶段生效其他阶段拿不到降低泄露风险。BUILD_NUMBER作为镜像Tag比用git commit hash更直观。BUILD_NUMBER是Jenkins内置变量每次构建递增天然有序。我们线上用1234-prod这种格式运维查问题时直接看Tag就知道是第几次构建。post阶段Slack通知用slackSend插件发消息。注意channel名要提前在Slack里创建好且Jenkins的Slack App要有对应channel的写权限。4.3 验证与调试如何确认镜像真的构建成功光看Jenkins Console Output显示BUILD SUCCESS不够。必须验证三件事镜像是否真推上去了镜像内容是否正确容器能否正常启动验证1登录Registry查看镜像列表# 用curl直接查Registry API无需Docker login curl -X GET https://registry.yourcompany.com/v2/order-service/tags/list \ -H Authorization: Basic $(echo -n username:password | base64) \ -H Accept: application/json # 返回 {name:order-service,tags:[1234-prod,1233-test]}验证2用jib:dockerInfo本地检查镜像结构在本地Mac上cd到项目根目录运行mvn compile jib:dockerInfo \ -Djib.to.imagelocalhost:5000/order-service:local-testJib会输出详细的镜像信息包括每层的SHA256、大小、创建时间[INFO] Containerizing application to localhost:5000/order-service:local-test... [INFO] Getting base image gcr.io/distroless/java17:nonroot... [INFO] Building dependencies layer... [INFO] Building resources layer... [INFO] Building classes layer... [INFO] Building snapshot dependencies layer... [INFO] Finalizing... [INFO] [INFO] Built and pushed image as localhost:5000/order-service:local-test [INFO] [INFO] Executing tasks: [INFO] [] 100.0% complete [INFO] [INFO] Image size: 124.5 MB [INFO] Total layers: 4 [INFO] Layer 0 (dependencies): 87.2 MB [INFO] Layer 1 (resources): 1.3 MB [INFO] Layer 2 (classes): 35.8 MB [INFO] Layer 3 (snapshot dependencies): 0.2 MB验证3用docker run快速启动测试# 拉取刚推的镜像 docker pull registry.yourcompany.com/order-service:1234-prod # 启动容器映射端口加环境变量 docker run -d \ --name order-test \ -p 8081:8080 \ -e SPRING_PROFILES_ACTIVEdev \ -e DB_URLjdbc:h2:mem:testdb \ registry.yourcompany.com/order-service:1234-prod # 查看日志 docker logs -f order-test # 应看到 Started OrderServiceApplication in X.XXX seconds # curl测试接口 curl http://localhost:8081/actuator/health # 返回 {status:UP}注意docker run时-e传的环境变量会覆盖pom.xml里environment配置。这是Jib的设计方便测试不同profile。5. 常见问题与排查技巧实录那些让你加班到凌晨的坑5.1 经典报错“Connection refused” or “Unable to connect to the server”现象Jenkins构建时jib:build报错[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:3.3.1:build (default-cli) on project order-service: Build image failed: Connection refused (Connection refused)排查路径先确认Registry地址是否可达在Jenkins Agent容器里执行ping registry.yourcompany.com。如果不通检查Agent所在宿主机的DNS配置或防火墙策略。检查Registry是否启用HTTPSJib默认走HTTPS。如果你们的Registry是HTTP比如本地测试用registry:2必须加-Djib.allowInsecureRegistriestrue参数mvn jib:build -Djib.to.imagelocalhost:5000/order-service -Djib.allowInsecureRegistriestrue验证Registry认证用curl手动测试认证# 获取Bearer Token curl -X POST https://registry.yourcompany.com/auth \ -d serviceregistry.yourcompany.com \ -d scoperepository:order-service:push,pull # 如果返回401说明用户名密码错了5.2 镜像启动后立即退出“no main manifest attribute”现象docker run后容器状态是Exited (1)docker logs为空。根本原因Jib找不到SpringBoot的主类。Jib依赖spring-boot-maven-plugin生成的BOOT-INF/classes/META-INF/MANIFEST.MF里的Main-Class属性。如果pom.xml里没配spring-boot-maven-plugin或者配了但没执行repackagegoalJib就无法确定入口。解决方案确保pom.xml里有spring-boot-maven-plugin且executions里绑定了repackage。在Jenkins Pipeline里jib:build前必须执行mvn compile因为jib:build默认不触发compile阶段。手动验证unzip -p target/order-service-1.0.0.jar META-INF/MANIFEST.MF | grep Main-Class应输出类似Main-Class: org.springframework.boot.loader.JarLauncher。5.3 JVM内存溢出“java.lang.OutOfMemoryError: Java heap space”现象容器启动后日志里反复出现OOM然后被K8s OOMKilled。定位方法查看K8s事件kubectl describe pod order-service-xxxxx找OOMKilled事件。查看容器日志kubectl logs order-service-xxxxx --previous找java.lang.OutOfMemoryError堆栈。根因分析与修复JVM堆内存 容器内存限制这是最常见原因。比如K8s里limits.memory: 1Gi但Jib里-Xmx2gJVM会尝试