9.4 苗不出来怎么办：排错手册
9.4 苗不出来怎么办：排错手册
本节摘要：苗长不起来集中于几个高频现场：Pending（选不了地）、ImagePullBackOff（拉不到图纸）、CrashLoopBackOff（反复崩溃）、Running 却不通（水路问题）。本节按"现象、常见根因、验证命令、解法"的结构把这些现场编成手册，配一张总决策图，并把全册的排错知识收拢成一套固定的诊断流程。
先看总路线图
排错最忌乱试。把常见现象汇成一张决策图，先对号入座再动手：
图：苗情异常总决策图
现场一：Pending，种子落不了地
苗停在 Pending，说明调度器没找到合适的地。事件段会直说原因：
kubectl describe pod -n greenlib-prod greenlib-api-66d8f9bcb-z9qk | grep -A 2 Events # Events: # Warning FailedScheduling 0/6 nodes are available: 6 Insufficient memory # 六台节点内存都不够——申报额超了所有节点的余粮
三个常见根因按命中率排：requests 报太高（对照 7.3，把申报额校准到真实用量）；节点真的满了（扩节点或减株数）；没有节点满足约束（nodeSelector 或亲和性把范围圈死了）。解法都落回清单：改 resources、改 replicas、改调度约束，改完 apply，园丁自会重新选地。
现场二：ImagePullBackOff，图纸拿不到
苗知道去哪块地了，但造盆车间拉不到图纸：
kubectl describe pod -n greenlib-prod greenlib-web-5c8d9b7f4-x2qm | grep -A 3 Events # Normal Pulling Pulling image "greenlib/web:1.0.0" # Warning Failed Failed to pull image "greenlib/web:1.0.0": # Tag 1.0.0 not found in repository # 标签打错或没推上去 是这个现场的头号根因
命中率排序：镜像名或标签写错（本地能跑、集群拉不到，九成是它）；私有仓库没凭据（第五章的 dockerconfigjson 农药柜没配，或 imagePullSecrets 忘了引用）；网络不通（节点出不了网或仓库限流）。验证顺序：先人肉核对称与标签，再查凭据，最后测连通。
现场三：CrashLoopBackOff，起盆即崩
图纸到手、盆也造了，进程一启动就崩，退避重试循环往复。关键证据在前一世的日志里（7.1 讲过原理）：
kubectl logs -n greenlib-prod greenlib-api-66d8f9bcb-p3vw --previous | tail -n 6 # Traceback (most recent call last): # File "main.py", line 12, in <module> # conn = connect(DB_HOST, DB_PASS) # ConnectionRefusedError: [Errno 111] Connection refused # 应用启动时连数据库被拒：地址错 或数据库还没就绪 kubectl describe pod -n greenlib-prod greenlib-api-66d8f9bcb-p3vw | grep "Last State" -A 2 # Last State: Terminated # Reason: Error Exit Code: 1
根因常见三类：配置错误（地址、口令、开关不对——回到第五章检查施肥卡与农药柜）；依赖未就绪（数据库自己还在暖机，配上 8.1 的启动探针与重试逻辑能扛过窗口期）；资源不足（describe 里 Reason 若是 OOMKilled，回到 7.3 调 Limits）。CrashLoop 的退避间隔会越拉越长，系统在替你争取冷静排查的时间。
现场四：Running 却访问不通
苗活得好好的，就是用不了。按水的路线逐段排查：
# 第一段：苗在名单里吗（就绪探针过没过） kubectl get endpoints greenlib-web -n greenlib-prod # NAME ENDPOINTS # greenlib-web 10.24.0.31:8080 只有一株在名单 另两株被就绪探针拦下 # 第二段：名单里的苗真的能应答吗 kubectl exec -it -n greenlib-prod deploy/greenlib-api -- curl -s -o /dev/null -w "%{http_code}\n" http://greenlib-web # 000 水闸后的苗没应答 目标端口对不上 targetPort 与容器监听对一遍 # 第三段：门卫的路牌翻译对吗（外部访问不通时） kubectl describe ingress greenlib-entry -n greenlib-prod | grep -A 3 Rules # 确认域名与路径指向的水闸名和端口无误
三段分别对应三种根因：就绪探针太严（苗能干活但被误拦，8.1 的调参原则）；端口对不上（水闸的 targetPort 与容器实际监听不符）；路牌写错（Ingress 的 backend 指错了水闸）。沿着水路图查，每一段都能用命令落到实处。
收拢成流程
全册的排错知识在此收拢成一套固定流程，值得存进肌肉记忆：
kubectl get pods -A定现象，对号入座上面的决策图kubectl describe pod看事件与 Last State，根因常在其中kubectl logs --previous读遗言，CrashLoop 的必经一步kubectl top对水肥账，资源类问题的实锤- 仍无头绪：上探一层看节点与全局事件（describe node、get events 按时间排序）
- 解法永远落回清单：改期望、apply、让机制去执行——而不是登机器手修
第六条是全册的收束句。从第一章"交期望不指挥动作"出发，到最后一节"排错也是改期望"，这本播种手册讲的始终是同一件事：把田的经营写成清单，让机制替你看守。往后的路标也顺手留下：Operator（把运维经验写成专属园丁）、网络策略（给苗之间也装门禁）、服务网格（把水路管理再抽一层）。它们都长在你已经认得的枝干上。
本节要点回顾
- 四大高频现场：Pending 选地难、图纸拉不到、起盆即崩、活着不通
- 现象进图 根因进命令 解法进清单：describe 与前一世日志是两大证据源
- CrashLoopBackOff 必看 logs 加 previous；OOMKilled 回去调 Limits
- 访问不通沿水路三段查：名单、端口、路牌
- 最终修法永远是改期望再 apply，不登机器手修——这是声明式的纪律，也是全册的落点