Kubernetes部署新版本镜像失败：存活探针503及CrashLoopBackOff求助

一、先定位新版本镜像的核心问题 #

因为切回旧镜像完全正常，说明新版本镜像本身存在启动或运行异常，优先排查这一点：

1. 查看故障Pod的启动日志

   kubectl logs <故障Pod名称>
   # 如果容器已经重启，看之前的日志
   kubectl logs <故障Pod名称> --previous
   

   重点关注日志里的错误信息，比如依赖缺失、配置加载失败、端口监听失败、内部服务初始化报错等，这些是导致503和CrashLoopBackOff的根本原因。
2. 本地直接运行新版本镜像验证
   拉取镜像到本地环境，模拟容器启动场景：

   docker pull <你的镜像仓库>/<镜像名>:<新版本标签>
   # 直接运行看启动日志
   docker run --rm <你的镜像仓库>/<镜像名>:<新版本标签> 2>&1
   # 如果需要暴露端口测试健康接口
   docker run --rm -p <本地端口>:<容器端口> <你的镜像仓库>/<镜像名>:<新版本标签>
   

   如果本地启动就失败，直接修复镜像问题（比如Dockerfile里依赖安装不全、启动命令错误、基础镜像不兼容等）。

二、优化探针配置 #

503状态码说明健康检查接口返回服务不可用，结合CrashLoopBackOff，大概率是探针检测时机过早或配置不合理：

1. 区分livenessProbe和readinessProbe的作用
   • readinessProbe：判断应用是否准备好接收流量，失败时会从Service端点移除，不会重启容器
   • livenessProbe：判断应用是否存活，失败时会重启容器
     建议给探针增加启动延迟、调高失败阈值，避免过早检测：

   livenessProbe:
     httpGet:
       path: /healthz  # 替换成你的健康检查路径
       port: 8080       # 替换成应用实际监听端口
     initialDelaySeconds: 60  # 给应用足够的启动初始化时间
     periodSeconds: 10
     failureThreshold: 5      # 允许连续5次失败才重启
     timeoutSeconds: 5
   readinessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 30
     periodSeconds: 5
     failureThreshold: 3
   

2. 临时禁用livenessProbe测试
   如果调整参数后还是重启，先临时注释掉livenessProbe，看Pod能不能稳定运行。如果能，说明健康检查接口本身有问题，需要检查新版本应用的健康检查逻辑是否变更。

三、解决节点资源不足与调度问题 #

针对Insufficient memory和亲和性不匹配的报错：

1. 检查节点资源使用情况

   # 查看节点资源占用
   kubectl top nodes
   # 查看节点可分配与已使用资源详情
   kubectl describe node <节点名称> | grep -A 10 "Allocatable"
   kubectl describe node <节点名称> | grep -A 10 "Used"
   

2. 调整应用资源请求/限制
   对比旧版本应用的资源占用数据，如果新版本内存需求增加，更新Deployment的资源配置：

   resources:
     requests:
       memory: "512Mi"  # 根据实际测试结果调整，不要超过节点可分配内存
       cpu: "250m"
     limits:
       memory: "1Gi"
       cpu: "500m"
   

3. 检查节点亲和性配置
   查看Deployment里的nodeSelector或affinity规则，确认符合条件的节点是否存在且有足够资源：

   # 查看所有节点标签
   kubectl get nodes --show-labels
   

   如果亲和性规则过于严格，且符合条件的节点资源不足，可以暂时移除亲和性配置，或给目标节点扩容内存。

四、检查Dockerfile变更 #

对比新旧版本Dockerfile，重点看以下几点：

• 基础镜像是否更换（比如从Python 3.8换成3.11，可能导致依赖兼容问题）
• 依赖安装步骤是否完整（比如缺失pip install环节，或依赖包版本变更）
• 启动命令是否正确（比如启动脚本路径错误、参数配置错误）
• 端口暴露是否与应用实际监听端口一致（EXPOSE指令是否正确）

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