故障排查

当高优先级 Pod 仍然 Pending，或抢占后分布不符合预期时，问题往往藏在亲和、拓扑约束和资源请求之间。本篇用调度链路拆解 K8s调度抢占的判断顺序与检查点。

遇到 Pod 一直 Pending 或 ImagePullBackOff 时，先别急着重建应用。本篇按事件、Secret、镜像地址、仓库连通性和节点运行时逐层排查，帮助快速定位 K8s镜像拉取失败原因。

DNS 已经启用 NodeLocal DNSCache，业务仍然偶发解析慢或超时？本篇按现象、命令、指标和配置拆解缓存与 CoreDNS 排查顺序，帮助快速缩小影响范围。

节点维护时 Pod 不让驱逐，或者 PDB 配了却没有保护效果，问题通常出在不可用预算理解上。本文用示例 YAML、边界表和维护验证清单解释 PDB 怎么配置，以及它不能替代哪些高可用设计。

快照对象显示 Ready，但 PVC 恢复一直 Pending？本篇按控制器、快照类、驱动能力和 PVC 绑定顺序排查 Kubernetes CSI 快照恢复失败，避免误删数据源。

跨机房、跨集群或主备仓库同步时，Harbor镜像复制失败会拖慢发布节奏。本文按策略触发、目标凭据、TLS 证书、jobservice 队列和 digest 校验拆解排查顺序，帮助团队少走盲目重试的弯路。

应用日志只看到超时，Dapr sidecar 里却有服务发现、重试或连接错误？本篇从 app-id、端口、策略和日志入手，定位 Dapr 边车调用失败的真实断点。

PVC 一直 Pending 时，问题未必出在应用 Pod，而可能卡在存储类、PV 匹配、拓扑约束或 CSI 动态供给链路。本文给出一套从事件到 StorageClass 的排查路径。

当依赖超时、流量突增或局部故障出现时，系统要先保住核心业务而不是追求所有功能完整可用。本文从原则、策略、检查点和例外情况拆解服务降级设计，帮助团队建立可执行的稳定性预案。

Kubernetes 备份恢复不能只备份 YAML 或 etcd，还要同时考虑应用数据、镜像、Secret、存储卷和恢复顺序。本文用清单方式梳理灾备设计与演练重点。

运行时安全关注的是容器启动之后发生了什么。本文从异常进程、文件访问、网络连接和权限提升信号出发，梳理容器运行时防护与响应路径。

应用访问 Service 超时、域名 NXDOMAIN 或 Pod 内解析偶发失败时，问题可能在 CoreDNS，也可能在 Service、网络策略或节点路径。本文给出 Kubernetes DNS解析失败的分层排查流程。

API Server 无法访问、kubectl 报 x509 或控制面组件反复重启时，Kubernetes证书过期往往是高优先级排查项。本文按影响范围、续期、验证和回滚拆解生产处理流程。

当控制面状态损坏、误删关键资源或集群升级失败时，Kubernetes etcd备份恢复能力决定了恢复窗口和风险边界。本文按生产流程拆解快照、验证、演练、回滚和预防清单。

排查Kubernetes问题时，kubectl命令要按场景组合使用，而不是零散记忆。本文围绕Pod状态、日志、事件、资源、网络和配置检查，整理一份适合日常排障的速查清单。

微服务监控出问题时，根因常常不在单个指标，而在采集、标签、规则和通知链路没有被串起来。本文按数据流拆解 Prometheus架构，帮助平台团队设计可排查、可扩展的监控告警体系。

CrashLoopBackOff不是一个单一错误，而是Pod中的容器不断启动失败后的状态结果。本文用6步排查法串起事件、日志、退出码、OOM、探针和依赖检查，帮助快速定位Pod反复重启原因。

微服务容灾不是只在异地建一套环境，而是把超时、重试、隔离和降级这些日常策略做成系统韧性。本文会从故障传播控制角度讲清楚。

链路追踪的价值不只是把请求路径画出来，而是帮助团队在复杂调用关系里快速定位慢点和故障点。本文会从微服务排障视角讲清楚怎么建设和使用。

发布回滚不是临时出问题时再想办法撤回，而是上线前就要设计好的失败路径。本文会从版本、数据库和应急流程三个关键点拆开讲清楚。