EKS集群从1.15升级到1.16后Pod处于CrashLoopBackOff状态故障求助

• 第一步：采集容器崩溃日志与退出状态码
  执行kubectl logs <故障Pod名称> -p获取上一次崩溃的容器运行日志，同时执行kubectl describe pod <故障Pod名称>查看Containers段下的Last State字段，确认退出状态码：
  • 状态码0：进程主动正常退出，一般为业务启动逻辑校验失败（如配置读取失败、依赖服务不可达）
  • 状态码1：程序运行时报错，需结合日志排查业务代码问题
  • 状态码137：进程被系统OOM终止，需调高Pod的内存配额
  • 状态码139：程序段错误，一般为镜像与节点运行环境架构不兼容
• 第二步：检查EKS集群附加组件版本兼容性
  EKS控制平面升级后，必须同步升级配套附加组件到对应版本才能正常运行，1.16版本EKS要求的最低配套版本为：VPC CNI v1.6.3、CoreDNS v1.6.6、kube-proxy v1.16.x。
  执行以下命令确认组件版本：

  kubectl get daemonset aws-node -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}'
  kubectl get deployment coredns -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}'
  kubectl get daemonset kube-proxy -n kube-system -o jsonpath='{.spec.template.spec.containers[0].image}'
  

  版本不符合要求的需要升级到对应适配版本，附加组件不兼容会导致集群网络、域名解析全局异常，引发所有业务Pod启动失败。
• 第三步：检查Kubernetes API版本兼容性
  Kubernetes 1.16正式移除了extensions/v1beta1、apps/v1beta1、apps/v1beta2版本的Deployment/StatefulSet/DaemonSet资源API，若升级前的工作负载配置使用了上述旧版本API，且包含废弃字段，会导致Pod启动参数加载失败。
  执行kubectl get deployment <对应Deployment名称> -o yaml确认apiVersion已调整为apps/v1，同时检查spec配置是否符合apps/v1版本的字段规范。
• 第四步：检查AWS访问权限配置
  若业务容器需要访问AWS服务（如S3、RDS、ECR等），确认节点IAM角色或ServiceAccount绑定的IAM角色权限未发生变更，升级过程中如果集群OIDC提供商配置异常，会导致IRSA权限失效，业务程序无法获取依赖资源主动退出。

• 附加组件版本不兼容：按照EKS 1.16版本官方要求的组件版本逐一升级附加组件，升级完成后集群网络恢复正常，业务Pod会自动重建恢复。
• 旧API配置不兼容：将所有工作负载的API版本统一替换为apps/v1，调整废弃字段至符合新版本规范后重新发布配置即可。
• 业务逻辑异常：根据容器日志的报错信息修复业务问题，比如调整配置参数、调高资源配额、修复依赖服务连接问题后重新发布即可。

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