为何一个Pod出现CrashLoopBackOff另一个正常？如何排查该问题？

我有一个Kubernetes Deployment，运行一段时间后出现异常：

NAME                                  READY   STATUS             RESTARTS        AGE
pod/picanagm-solution-5cb8887968-qk4pr   0/1     CrashLoopBackOff   140 (78s ago)   11h
pod/picanagm-solution-77f5fcfdc-kwd9w    1/1     Running            0               2d20h

故障Pod的事件日志：

Events:
  Type     Reason   Age                     From     Message
  ----     ------   ----                    ----     -------
  Warning  BackOff  2m42s (x3258 over 11h)  kubelet  Back-off restarting failed container

容器启动日志：

Picked up JAVA_TOOL_OPTIONS: -Dlogging.config=/app/run/logback.xml -DcontentServer.factory-reset=folder -DcontentServer.factory-reset.folder-name=file:/app/bookmarks -DSameSite=none -Dconfiguration.sign-off.enabled=true -Ddata.extraction.templates.base.dir.path=${java.io.tmpdir} --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED

I> No access restrictor found, access to any MBean is allowed
Jolokia: Agent started with URL http://10.244.4.81:8778/jolokia/
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/activeviam/MINDZ/starter/main/MINDZApplication has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
    at java.base/java.lang.ClassLoader.defineClass1(Native Method)
    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)

ReplicaSet状态：

replicaset.apps/picanagm-solution-5cb8887968   1         1         0       11h

请问该异常的原因是什么？如何调试此问题？

从容器日志中的java.lang.UnsupportedClassVersionError可直接定位核心问题：

• 应用代码是用Java 21编译的（class文件版本65.0对应Java 21）
• 容器内运行的Java环境是Java 17（仅支持最高class文件版本61.0，对应Java 17）
• 两个ReplicaSet状态不一致，说明异常ReplicaSet使用的容器镜像与正常版本存在差异：要么是镜像内的Java环境被降级，要么是应用代码用更高版本JDK编译后，被错误部署到了旧Java环境的镜像中。

• 核对镜像版本差异：分别查看两个ReplicaSet使用的容器镜像地址，确认是否存在版本不一致

  kubectl get replicaset picanagm-solution-5cb8887968 -o jsonpath='{.spec.template.spec.containers[0].image}'
  kubectl get replicaset picanagm-solution-77f5fcfdc -o jsonpath='{.spec.template.spec.containers[0].image}'
  

  若镜像不同，检查镜像构建、发布流程是否存在变更。

• 验证镜像内Java版本：拉取异常ReplicaSet的镜像，查看其内置Java版本

  docker pull <异常镜像地址>
  docker run --rm <异常镜像地址> java -version
  

  对比正常镜像的Java版本，确认环境版本不匹配问题。

• 检查应用编译版本：可尝试进入异常Pod（即使处于CrashLoop状态，也可临时启动shell），查看应用class文件的编译版本

  kubectl exec -it picanagm-solution-5cb8887968-qk4pr -- sh
  # 查看目标class文件的编译版本
  javap -verbose /app/classes/com/activeviam/MINDZ/starter/main/MINDZApplication.class | grep "major version"
  

  也可直接检查CI/CD流程中编译应用使用的JDK版本，确认是否与运行环境兼容。

• 修正Deployment配置：

  • 若为镜像版本错误，更新Deployment使用与正常ReplicaSet一致的镜像；
  • 若为编译环境问题，调整CI/CD使用对应版本的JDK编译应用，或升级容器内的Java环境至Java 21。

• 清理异常ReplicaSet：问题解决后，删除异常的ReplicaSet，让Deployment重新管理Pod实例

  kubectl delete replicaset picanagm-solution-5cb8887968
  

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