使用Helm在Minikube部署Spring Boot示例时遇CrashLoopBackOff问题

1. 验证本地JAR包的可执行性 #

先确认本地构建的JAR包本身能正常运行，在项目根目录执行：

java -jar target/[你的JAR文件名].jar

如果本地运行正常，说明JAR包的MANIFEST.MF配置正确，问题出在Docker镜像构建环节；如果本地也报同样错误，先修复Spring Boot的构建配置（比如Maven/Gradle的打包插件配置）。

2. 检查Dockerfile的构建逻辑 #

常见问题是Dockerfile未正确复制可执行fat jar（包含所有依赖和主类配置的JAR），或者构建流程有误。参考标准Spring Boot Dockerfile写法：

FROM openjdk:17-jdk-slim
WORKDIR /app
# 注意路径：Gradle构建的JAR在build/libs下，Maven在target下
COPY build/libs/demo-spring-boot-*.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]

确认复制的是打包后的可执行JAR，而非仅编译后的class文件或未包含依赖的轻量JAR。

3. 检查minikube内部镜像的JAR内容 #

因为你用eval $(minikube docker-env)把镜像构建在了minikube的Docker环境里，直接进入minikube验证镜像：

# 进入minikube节点
minikube ssh
# 启动镜像的临时容器并进入
docker run -it --rm gateixeira/demo-spring-boot:latest bash
# 查看JAR的MANIFEST.MF内容
unzip -p /app.jar META-INF/MANIFEST.MF

正常输出应包含Main-Class和Start-Class属性，比如：

Main-Class: org.springframework.boot.loader.JarLauncher
Start-Class: com.yourpackage.YourApplicationKt

如果没有这些属性，说明镜像里的JAR包无效，需要重新构建。

4. 核对Helm Chart的容器配置 #

检查Helm的values.yaml或deployment模板：

• 确保容器启动命令没有错误，比如不要写成java /app.jar（缺少-jar参数）；
• 确认容器的工作目录、JAR文件路径和Dockerfile中的配置完全匹配。

5. 重新构建镜像并部署 #

如果发现Dockerfile或JAR包问题，修正后重新执行：

# 确保处于minikube的Docker环境
eval $(minikube docker-env)
# 重新构建镜像
docker build -t gateixeira/demo-spring-boot:latest .
# 重新部署Helm应用
helm upgrade --install demo-spring-boot charts --values charts/values.yaml
# 查看Pod状态
kubectl get pods

6. 获取更详细的启动事件日志 #

若问题仍存在，查看Pod的详细事件信息：

kubectl describe pod [你的Pod名称]

在Events板块可以看到容器启动失败的完整上下文，帮助进一步定位问题。

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