CrashLoopBackOff需查上轮崩溃日志；ImagePullBackOff重点验镜像名、凭据、网络；Pending则查资源、标签、污点、配额。先看状态、查事件、读日志，三步定位80%问题。
Pod卡在 CrashLoopBackOff、ImagePullBackOff 或 Pending，八成不用改代码，先看日志——但得看对地方、用对参数，否则白翻。
查 CrashLoopBackOff 必须加 --previous
容器刚启动就崩，当前容器可能已退出，kubectl logs <pod-name> 返回空或“no such container”是常态。不加 --previous 就等于没看真实错误。
- 只对已崩溃并重启过的容器生效；新创建未崩溃过的一次性 Pod 不适用
- 常见真凶藏在最后一行：configmap 挂载路径错（比如挂到
/etc/app/conf.yaml但应用只读/config/app.yaml）、secret 注入失败导致环境变量为空、健康探针路径写错（readinessProbe.httpGet.path: /healthz而应用只暴露/health） - Go 应用尤其容易“假成功”：log 输出 “server started” 后几毫秒因 DB 连接超时 panic，必须看到 panic 堆栈末尾才能定位
kubectl describe pod 的 Events 是第一线索源
它不显示应用日志，但告诉你调度器和 kubelet 看到了什么。所有 ImagePullBackOff 和 Pending 都得从这里起步。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
-
ImagePullBackOff事件里若出现unauthorized，立刻检查imagePullSecrets名称是否大小写一致、Secret 是否与 Pod 同 namespace、Base64 解码后.dockerconfigjson结构是否合法（应含{"auths":{...}}） -
Pending事件若提示Insufficient cpu或node(s) had taint，说明不是镜像或代码问题，而是资源或污点拦截 - 注意时间戳：Events 是按发生顺序排列的，最早那条往往就是根因（比如先报 “Failed to pull image”，后续所有 “Back-off restarting failed container” 都是结果）
Go 构建失败时别信 go version，要清 Godeps/_workspace 和 _output
报错如 expected [linux amd64 go1.5.1 X:none] but got [linux amd64 go1.2.1 X:none]，不是 Go 没装对，是旧版 .a 编译产物残留。
-
make clean不会删掉Godeps/_workspace/pkg/下的旧标准库归档，必须手动rm -rf Godeps/_workspace _output - 若
/usr/local/go/pkg权限为 root-only，Go 构建时跳过重建 stdlib，继续复用旧缓存——执行sudo chmod u+w /usr/local/go/pkg再重试 - 验证是否清干净：
ls Godeps/_workspace _output应返回 “No such file or directory”
journalctl -u kubelet 是节点级问题的最终仲裁者
当 kubectl get nodes 显示 NotReady，或 Pod 明明该调度却卡住，kubelet 日志比 Pod 日志更底层、更诚实。
- 用
journalctl -u kubelet --since "30 minutes ago" | grep -iE 'error|fail|PLEG|eviction'快速过滤关键线索 -
PLEG is not healthy表示容器运行时失联（常见于 docker/crictl 崩溃或 cgroup v2 兼容问题） -
x509相关错误大概率是证书过期或时间不同步，systemctl restart kubelet不解决，得同步节点时间或轮换证书
真正卡住的从来不是某个报错字符串，而是你跳过了 --previous、漏看了 describe 里的第一条 Events、或者以为 go version 正确就等于构建环境干净——这些动作本身不费事，但少做一步，排查时间就翻倍。
