Google Cloud Shell中GKE Pod CrashLoopBackOff报错修复方法

从kubectl返回的状态可以确认，redis-master组件运行正常，故障范围限定在awwvision-webapp、awwvision-worker两类工作负载，所有相关副本均反复重启触发CrashLoopBackOff，返回结果开头的gcp auth插件弃用警告不影响现有集群操作，和本次故障无关。

按以下步骤排查修复：

• 第一步先拿崩溃日志定位具体错误，不要盲目修改配置。在Cloud Shell执行命令拉取webapp上一次崩溃的日志：
  kubectl logs awwvision-webapp-55f5dbb8c7-mdtnq --previous

必须加--previous参数，否则只能拿到当前正在重启实例的零散日志，看不到容器退出前的报错信息
同Deployment下所有副本启动逻辑一致，worker组件随便选一个副本拉取日志即可：
kubectl logs awwvision-worker-79c846b86d-f9mvp --previous

• 针对该实验场景的高频报错，对应修复方式如下：
  • 日志报Cloud Vision API调用被拒/权限不足：先确认实验流程中已经启用Cloud Vision API，再检查集群节点绑定的服务账号是否拥有Vision API调用权限，不要直接使用未授权的默认Compute Engine服务账号运行业务Pod。
  • 日志报redis连接失败/连接超时：执行kubectl get svc确认redis-master对应的Service存在且端口配置正确，检查webapp和worker的配置文件中，redis连接地址填写为redis-master:6379，不要写localhost或者固定节点IP。
  • 日志报依赖缺失、启动文件不存在：回到容器镜像构建步骤，确认Dockerfile内的依赖安装命令执行成功（该实验用pip安装Python依赖时容易因网络问题丢包），重新构建并推送镜像到GCR后再重新部署工作负载。
  • 日志报端口绑定失败、健康检查探测失败：确认应用启动时绑定的监听地址为0.0.0.0而非127.0.0.1，Deployment配置中声明的containerPort和应用实际监听端口一致，健康检查探测的路径、端口配置正确。
• 修复完成后执行滚动更新重启故障工作负载：
  kubectl rollout restart deployment/awwvision-webapp deployment/awwvision-worker
  等待1-2分钟后重新执行kubectl get pods验证，所有相关Pod的READY列为1/1、STATUS为Running即为修复完成。

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