EKS集群部署Pod始终处于Pending状态，报FailedScheduling错误求助

兄弟，我来帮你排查下这个棘手的问题！Pod一直卡在Pending状态还报FailedScheduling，本质是Kubernetes调度器没法把你的Pod分配到集群里的节点上。结合你用的是2台t2.micro节点的情况，我给你列几个最常见的排查方向和操作步骤：

• 先看Pod的调度事件详情（最直接）
  执行这条命令查看具体的错误原因：

  kubectl describe pod my-flask-app-5c9f644594-6c7v6
  

  拉到输出的Events部分，这里会明确告诉你调度失败的具体原因——比如是节点内存/CPU不够，还是节点有污点Pod没容忍，抑或是其他问题，这是定位问题最快的方式。

• 检查节点资源是否不足（t2.micro最容易踩的坑）
  t2.micro本身只有1核CPU、1GB内存，而EKS节点上默认会运行一堆系统组件（kube-proxy、AWS VPC CNI的aws-node Pod、kubelet等），这些已经占用了不少资源。你可以查看节点的资源使用情况：

  kubectl describe node <你的节点名称>
  

  重点看Allocatable（节点可分配的资源）和Allocated resources（已分配的资源）部分，对比剩余的CPU、内存是否能满足你Pod的资源请求（如果Deployment里没配置，K8s会用默认值，但哪怕是默认值也可能超过t2.micro的剩余资源）。

• 检查节点是否有污点
  有时候EKS节点组创建过程中可能会带上污点，导致Pod无法被调度上去。同样用kubectl describe node <你的节点名称>查看Taints字段，如果存在类似node.kubernetes.io/not-ready或者自定义的污点，而你的Pod没有配置对应的Tolerations，就会被调度器拒绝。

• 检查系统组件是否正常运行
  EKS的核心系统组件（比如CNI插件、kube-proxy）如果异常，节点可能处于NotReady状态，调度器不会把Pod分配到不健康的节点上。执行这条命令查看kube-system命名空间下的Pod状态：

  kubectl get pods -n kube-system
  

  确保aws-node、kube-proxy这些Pod都是Running状态，如果有CrashLoopBackOff或者Pending的情况，得先修复这些系统组件的问题。

• 检查Pod的调度约束配置
  如果你在Deployment的YAML里配置了nodeSelector、affinity或者nodeName，可能和现有节点的标签、属性不匹配，导致找不到合适的节点。检查下你的Deployment配置，看看这些约束是不是和节点实际情况对应不上。

按照上面的步骤排查，基本就能找到问题所在了！

备注：内容来源于stack exchange，提问作者Nazim Razac