Kubernetes出现CrashLoopBackOff问题，本地容器可正常运行镜像求助
嘿，我来帮你搞定这个本地能跑但K8s里崩的问题！CrashLoopBackOff本质上是Pod里的容器反复启动又退出，咱们一步步来定位原因：
第一步：先抓Pod的日志，找到崩溃根源
这是最关键的一步，别瞎猜，直接看应用为啥挂：
# 查看当前Pod的日志 kubectl logs <你的Pod名称> # 如果是多次重启，还能看上次崩溃的日志 kubectl logs <你的Pod名称> --previous
比如如果是端口被占用、依赖缺失、代码报错，日志里都会写得明明白白。
第二步：检查K8s资源配置的坑
端口监听范围是否正确
你的Express应用如果默认用3000端口，一定要确认代码里是监听0.0.0.0而不是127.0.0.1：
// 正确写法，允许容器外部访问 app.listen(3000, '0.0.0.0', () => { console.log('Server running on port 3000'); });
如果只监听127.0.0.1，虽然本地容器里curl能访问，但K8s里容器的网络是隔离的，虽然进程不会直接崩溃，但如果后续健康检查失败也可能触发重启，先确认这个点准没错。
资源配额是否够
如果给Pod的CPU/内存限制太小，应用启动时可能直接被OOMKill（内存不足被系统杀死）。用这个命令看Pod的事件：
kubectl describe pod <你的Pod名称>
在Events里找有没有OOMKilled的字样，如果有，调整Deployment里的resources字段，给点足够的资源：
resources: requests: memory: "64Mi" cpu: "100m" limits: memory: "128Mi" cpu: "500m"
第三步：针对你的Dockerfile优化排查
依赖是否真的安装完整
虽然你本地构建时npm install没问题，但推送到镜像仓库的过程中有没有遗漏？或者镜像拉到K8s节点后，node_modules缺失？可以临时启动一个测试Pod进去看：
kubectl run -it --rm --image=<你的镜像名> --overrides='{"spec":{"containers":[{"name":"test","image":"<你的镜像名>","command":["/bin/bash"]}]}}' test-container
进去后执行ls node_modules看看依赖全不全，再手动跑npm start，看会不会报错。
尝试用普通用户运行容器
默认ubuntu镜像用root用户跑，有些K8s集群会限制root权限，导致进程启动失败。给你的Dockerfile加几行，创建普通用户：
# 在CMD前添加以下内容 RUN useradd -m appuser USER appuser
重新构建镜像再部署试试，很多时候权限问题是隐形杀手。
确保进程是前台运行
你的CMD ["npm", "start"]没问题，但要确认package.json里的start脚本不是后台运行的：
// package.json里的scripts要这样写，不要加&符号 "scripts": { "start": "node app.js" }
如果加了&，主进程会退出，容器就直接崩了。
第四步：其他可能的小坑
镜像拉取是否正常
看kubectl describe pod的Events，如果有ErrImagePull或者ImagePullBackOff，说明K8s节点拉不到你的镜像。如果是私有仓库，要配置ImagePullSecret；如果是本地镜像，要确保每个节点都有这个镜像（或者推到公共仓库）。
有没有遗漏的配置文件
如果你的应用依赖本地的某个配置文件，但K8s里没通过ConfigMap或者Volume挂载，应用启动时找不到文件就会崩溃。不过你说这是简单的hello world，大概率没这个问题，但还是可以确认下。
先从看日志开始，90%的问题都能在日志里找到答案！
内容的提问来源于stack exchange，提问作者Chen
