Kubernetes部署失败80%可三步定位：先看Pod状态、再查事件（kubectl describe pod）、最后读日志（含--previous）。CrashLoopBackOff需查上轮崩溃日志；ImagePullBackOff重点验镜像名、凭据、网络；Pending则查资源、标签、污点、配额。
Kubernetes部署失败，90%以上都卡在Pod启动环节——不是镜像拉不下来，就是容器一启就崩，或者压根没被调度出去。别急着重试或删yaml，先看状态、查事件、读日志，三步就能定位80%的问题。
CrashLoopBackOff：应用一跑就崩，怎么快速定位？
这个状态说明容器反复启动→崩溃→重启，根本没活过几秒。关键不是“为什么崩”，而是“崩之前干了什么”。
- 先用
kubectl logs <pod-name> -n <namespace> --previous</namespace></pod-name>查上一轮崩溃的日志（当前容器可能已退出，--previous才能看到真实错误） - 常见真凶：
configmap挂载路径错导致配置文件缺失、secret未注入导致数据库密码为空、环境变量名拼写错误（比如DATABASE_URL写成DB_URL）、健康探针路径不存在（readinessProbe.httpGet.path: /healthz但应用只暴露/health） - 别信应用日志里的“成功启动”——有些框架会先打一行启动日志，再因依赖初始化失败而退出，一定要看到最后一行错误堆栈
ImagePullBackOff：镜像明明存在，却说“找不到”
不是仓库里没有镜像，而是K8s节点根本没权限或没连上。重点查三件事：名字、凭据、网络。
- 在节点上手动执行
docker pull <image></image>或crictl pull <image></image>，复现失败过程——能拉成功？那问题出在Pod定义；拉失败？看报错是unauthorized还是timeout - 私有仓库必须配
imagePullSecrets，且 Secret 必须和 Pod 在同一命名空间；Secret 名称大小写敏感，regcred和RegCred是两个东西 - 检查 Secret 内容是否 Base64 编码正确：
echo <base64-string> | base64 -d</base64-string>应输出合法的{ "auths": { "xxx": { "auth": "..." } } }，否则kubectl describe pod里会显示Failed to pull image "...": rpc error: code = Unknown desc = Error response from daemon: Get ...: unauthorized
Pending 状态不动：资源不够？还是被拦住了？
Pod 卡在 Pending，说明调度器连绑定都没完成。它不怪应用，只看资源、标签、污点、配额四样东西。
- 运行
kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>，紧盯Events区域——出现Insufficient cpu或node(s) had taint {node-role.kubernetes.io/master:NoSchedule}就直接对症下药 - 别只看
kubectl top node，还要查节点真实可分配资源：kubectl describe node <node-name></node-name>里找Allocatable和Non-terminated Pods占用，有些节点看似空闲，但已被 DaemonSet 或系统组件占满 - 命名空间级资源配额（
ResourceQuota）常被忽略：kubectl get resourcequota -n <namespace></namespace>，如果显示used接近hard，即使集群有空资源，Pod 也会被拒
Endpoint 为空、Service 不通：服务发现断在哪？
Deployment 起来了，Pod Running，但 kubectl get endpoints 返回空，说明 Service 根本没找到后端——八成是标签没对上。
- 对比两处标签：Pod 的
metadata.labels（如app: guestbook） 和 Service 的spec.selector（必须完全一致，包括键名和值） - 注意 Deployment 模板里
spec.template.metadata.labels才决定 Pod 标签，不是 Deployment 自身的 labels - 如果用了
matchLabels+matchExpressions复合选择器，漏掉任一条件都会导致 Endpoint 为空；简单起见，生产环境优先用纯matchLabels - NetworkPolicy 也可能静默拦截：
kubectl get networkpolicy -A，尤其当集群默认拒绝所有入站流量时，哪怕标签全对，流量也到不了 Pod
最易被忽略的点：很多问题表面是“部署失败”，实际是滚动更新卡在旧副本没终止、ConfigMap 更新后 volume 挂载没刷新、或 RBAC 权限只给了 ClusterRole 没绑 RoleBinding——排查时别只盯着 Pod，得顺着 ServiceAccount → RoleBinding → Role → API 资源访问链一路往下捋。
