pod一直处于pending状态通常因调度失败，需先用kubectl describe pod查看events：常见原因包括资源不足（insufficient cpu/memory）、nodeselector或affinity不匹配、节点污点未容忍。
Pod一直处于Pending状态
这通常意味着调度器无法为Pod找到合适的节点，不是资源不足就是约束条件冲突。
先运行 kubectl describe pod <pod-name></pod-name>，重点看 Events 部分。常见原因包括：
-
0/3 nodes are available: 2 Insufficient cpu, 1 Insufficient memory.—— 节点资源不够，检查kubectl top nodes和 Pod 的requests -
No nodes match node selector—— Pod 的nodeSelector或affinity匹配不到带对应 label 的节点，用kubectl get nodes -o wide确认 label 是否存在 -
Taints not tolerated—— 节点有 taint（如node-role.kubernetes.io/control-plane:NoSchedule），而 Pod 没配对应tolerations
Pod启动后立即CrashLoopBackOff
容器进程启动失败又退出，Kubernetes 不断重启。关键不是看 Pod 状态，而是看容器日志和退出码。
执行 kubectl logs <pod-name> --previous</pod-name> 查上一次崩溃的日志；如果没输出，再用 kubectl describe pod <pod-name></pod-name> 看 State.Terminated.Reason 和 Exit Code：
-
Exit Code 1：通常是应用启动报错（配置错误、连接不到 DB、env 缺失） -
Exit Code 137：被 OOMKilled —— 内存超限，检查容器limits.memory和实际内存占用 -
Exit Code 143：收到 SIGTERM 后正常退出，但主进程没撑住 —— 可能是没处理信号，或启动脚本里漏了exec "$@"
Service无法访问后端Pod
Service 是抽象层，连不上不等于 Pod 挂了，大概率是网络映射或选择器没对上。
分三步验证：
- 确认 Service 的
selector字段和 Pod 的labels完全一致（键和值都需匹配），用kubectl get pods -l key=value测试是否能选中 - 查 Endpoints：
kubectl get endpoints <service-name></service-name>—— 如果为空，说明 selector 没匹配到任何 Pod - 进一个同 namespace 的 Pod，直接
curl http://<pod-ip>:<port></port></pod-ip>测试容器是否真能响应；再试curl http://<service-name>:<port></port></service-name>，排除 DNS 或 kube-proxy 问题
Ingress返回502或连接拒绝
Ingress 控制器（如 nginx-ingress、ingress-nginx）本身是个 Deployment + Service，它挂了或配置错，前端就全黑。
先确认控制器 Pod 正常运行：kubectl -n ingress-nginx get pods（命名空间依实际而定）；再查其日志：kubectl -n ingress-nginx logs -l app.kubernetes.io/name=ingress-nginx。
常见硬伤：
- Ingress 资源的
spec.rules[].host和请求 Host 头不一致，或没配spec.tls却用了 HTTPS - 后端 Service 的
port名不匹配 Ingress 中service.port.name（注意：若用数字端口，Ingress 中必须写number，不能写name） - Service 类型不是
ClusterIP（Ingress 只能转发到 ClusterIP Service）
真正卡住的地方往往不在 YAML 写得“对不对”，而在于多层抽象之间 label、port、namespace、协议这些细节能否严丝合缝对上。少依赖 kubectl apply 后的状态绿标，多用 describe 和 get endpoints 看真实关联关系。
