Kubernetes Pod遇CrashLoopBackOff：自定义Docker镜像创建Pod失败求助

Hey there, let's work through this CrashLoopBackOff issue with your custom (yellow) Docker image. I’ve dealt with this exact scenario dozens of times, so let’s break down the troubleshooting steps systematically:

Step 1: Check the Pod’s Logs (First Stop!) #

CrashLoopBackOff almost always leaves clues in the container logs. Run these commands to get the full picture:

• Get the latest logs from your failing pod:

  kubectl logs <your-pod-name>
  

• If the container restarted recently, check the logs from the previous run (this often has the actual error that caused the crash):

  kubectl logs <your-pod-name> --previous
  

Look for errors like missing dependencies, invalid configuration, or failed startup commands—this will usually point you straight to the problem.

Step 2: Verify the Image Works Locally (Outside Kubernetes) #

Before blaming K8s, test your custom image directly with Docker on your server:

docker run -it <your-custom-image-tag>

If the container exits immediately or throws errors here, the issue is with your image itself, not Kubernetes. Compare its behavior to the official (red) tomcat image you’re using successfully—note any differences in startup output or exit codes.

Step 3: Check the Image’s Entrypoint/Command #

Custom images often break when the ENTRYPOINT or CMD is modified incorrectly. The official tomcat image uses catalina.sh run to keep the container running in the foreground. If your custom image changed this to a one-time command (like a script that exits after running), the container will stop immediately, triggering CrashLoopBackOff.

Inspect your image’s entrypoint/command and compare it to the official tomcat image:

# Check your custom image
docker inspect <your-custom-image-tag> | grep -A 5 -B 5 "Cmd\|Entrypoint"

# Check the official tomcat image for comparison
docker inspect tomcat | grep -A 5 -B 5 "Cmd\|Entrypoint"

Step 4: Dig Into Pod Events and Details #

Use kubectl describe to get a full timeline of what Kubernetes is trying to do with your pod:

kubectl describe pod <your-pod-name>

Look for sections like:

• Events: Did the image pull succeed? (Even with imagePullPolicy: IfNotPresent, confirm the image exists on the node.)
• State: Are there any error messages about failed liveness/readiness probes?
• Resources: Is the pod getting enough CPU/memory? (A resource-starved container might crash.)

Step 5: Check Permissions and File Ownership #

If you modified file permissions or switched to a non-root user in your custom image, you might run into issues:

• Tomcat typically needs write access to directories like webapps or logs—if your custom setup revoked these permissions, the server will fail to start.
• Ports like 8080 require root privileges by default; if you’re running as a non-root user, you’ll need to either use a port above 1024 or grant the necessary capabilities.

Step 6: Compare Your Custom Image to the Official One #

Since the official tomcat image works, do a side-by-side comparison of the two images. Check things like:

• Installed packages (did you remove a dependency tomcat needs?)
• Environment variables (did you override a critical variable like CATALINA_HOME?)
• Configuration files (did you modify server.xml or web.xml with invalid settings?)

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