Kubernetes 排障：Pod、发布、网络与存储 · 按 Pod、Service 与端点定位故障至Pod 运行但服务不可达的复盘

返回分篇目录

按 Pod、Service 与端点定位故障

本节沿Pod 条件、EndpointSlice 与持久数据定位失败层；先确认context、namespace、Secret 与 PVC，与配套示例逐项对照，再选择最小修复。

证据与状态层次

Kubernetes 排障 证据应包含上下文、命名空间、对象 UID、事件时间线、当前与上一容器日志、镜像、修订和最近配置变更。Pod phase 是摘要，Running 不等于 Ready，更不等于业务成功。先保留现场，避免删除 Pod 后把旧日志和事件关联丢掉；输出中 Secret 或业务数据须按事件流程脱敏。

get、describe、logs 与 events 都访问集群。以下解释这些证据能证明什么，不能把命令列表当作已验证结果。

Pending 与 ImagePullBackOff

Kubernetes Pending 调度先看 PodScheduled 条件与 FailedScheduling 事件：资源 requests 太大、污点不可容忍、亲和冲突、PVC 未绑定或卷拓扑都可能阻塞。若已调度但 ContainerCreating 卡住，则进一步看挂载、网络 sandbox 与运行时事件。不要把所有 Pending 都归为“节点 CPU 不够”。

Kubernetes ImagePullBackOff 表示镜像拉取失败后的退避状态，应检查引用、tag/digest、平台、Registry DNS/TLS、限流与 imagePullSecret。主例 .invalid 地址故意要求替换；镜像不存在时放宽 startupProbe 完全无效，因为应用根本没有启动。

CrashLoopBackOff 与探针

Kubernetes CrashLoopBackOff 是容器反复失败后的退避表现，不是根因。先看 lastState、exitCode、reason、上一次容器日志与探针事件：主例未替换 Secret 时初始化抛错；数据库目录无权写也在服务监听前失败。OOMKilled 需核对内存限制和实际使用，CPU 节流通常表现为慢，不直接等价进程被杀。

若日志显示正常启动后周期性停止，检查 liveness 的阈值、端点、超时与启动耗时。startupProbe 的预算不是“固定睡眠”，而是重复检查直到成功；把业务依赖放进 liveness 可能在依赖事故中重启全部应用，应该把依赖就绪表达在 readiness。

Service 无可用后端

Kubernetes Service 无端点时，按 namespace→selector→Pod 标签→readiness→EndpointSlice 条件检查。Pod Ready 但 selector 不匹配，与 Pod 不就绪是两种不同故障。端点正常但请求失败再看 port/targetPort、应用监听、NetworkPolicy、CNI 数据面与调用方 DNS；不要把 80 和 8080 混用。

ClusterIP 主要是集群内入口，外部工作站不能假设直接路由到它。port-forward 可以临时调试但创建本地监听并依赖相应权限。

Forbidden、配置与存储

Kubernetes Forbidden RBAC 意味着身份已被识别但操作没有授权，也可能来自准入策略拒绝；要看错误中的阶段和资源。Unauthorized 则先查认证凭据。observer 组没有 Secret 和 port-forward 权限，拒绝这些操作符合设计，不能通过绑定 cluster-admin 消除所有报错。

PVC Pending 不能靠重启应用解决；先核对存储类、事件、容量、访问模式和拓扑。PVC Bound 也不能保证应用目录可写，还需驱动权限与 fsGroup 支持。配置缺键会阻止容器创建，配置旧值则常是环境变量或程序启动缓存，需要看最终 PodSpec 和配置版本，不先删数据卷。

诊断练习与解答

问题：Service DNS 能解析，Pod Running，curl 仍失败，下一步是什么？答案：检查 Ready 条件、selector 与 EndpointSlice，再检查端口和监听。DNS 与 Running 都不是后端就绪证据。

问题：事件出现 FailedMount，但镜像能拉取，应该换镜像吗？答案：没有依据。先解释卷名、PVC、Secret、CSI 或权限错误，镜像拉取与挂载是不同路径。

原排障手册保留完整命令及场景，先按本页建立假设，再按对象取证。

节点地址、条件与可分配量

节点 Ready、Pressure 条件与 Allocatable 应如何一起用于诊断？ 节点诊断要区分地址、条件和资源账本。Hostname、InternalIP、ExternalIP 表示不同访问范围，不能拿某个地址存在证明 kubelet 或 Pod 网络可达。Ready=True 表示节点报告就绪；False 与 Unknown 分别提示不健康或缺少及时状态，仍要对齐 reason、message、心跳与条件变更时间。MemoryPressure、DiskPressure、PIDPressure 和 NetworkUnavailable 是不同检查方向，不能把所有节点异常归为内存不足。Node Status列出了当前字段与条件（核对 2026-10-17）。

旧笔记列 OutOfDisk 和固定心跳/驱逐默认时间，只能当版本背景，不能继续作为当前阈值。Capacity 是节点容量，Allocatable 是可供 Pod 调度使用的资源；即使实时 CPU 较低，请求预留与调度约束仍可能让 Pod Pending。保存节点条件时间线后，再关联受影响 Pod 的事件、requests、污点与卷拓扑。本节没有查询节点，也不从一段历史 JSON 推断任何实际集群健康。

Pod 运行但服务不可达的复盘

以下演练将Kubernetes 单副本计数项目的变更、失败证据和恢复验收串起来；先熟悉配套示例中的context、namespace、Secret 与 PVC。演练未执行。

故障场景与影响

Deployment 显示副本已运行，但通过 Service 访问仍然超时或没有可用后端。

先记录首次异常时间、受影响对象和最近变更，区分个别对象失败与整条管理链路异常。以下是排查演练，不是已发生事故的实测记录。

按证据定位原因

1. 先确认 context、namespace 和目标 Service，避免观察了另一套集群或同名对象。
2. 比较 Service selector 与 Pod labels，检查 EndpointSlice 地址、端口与 ready 条件；Running 不等于 Ready。
3. 沿 Pod 监听地址、容器端口、targetPort、集群内访问与入口链路逐层检查，同时查看事件和探针失败记录。

恢复步骤与验收

根据证据修正 selector、端口或探针配置；与最近发布相关时恢复已验证的工作负载版本。若涉及数据结构变更，先核对数据兼容性，不能把 Deployment 回滚等同数据回滚。

验收：从业务实际入口验证请求，确认预期端点承接流量，探针状态稳定且错误率恢复。复盘记录为什么仅看 Pod phase 没有发现故障。

将触发条件、直接原因、修复动作、恢复证据和后续检查写入同一份复盘，明确每项后续工作的负责人。机制参考：官方说明。

五条线的复盘

Kubernetes 复盘 对象不能只写“发布成功”。声明线检查 spec、配置和镜像；控制线检查 Deployment→ReplicaSet→Pod 与调度；流量线检查 DNS→Service→EndpointSlice→监听→业务；数据线检查 PVC→PV→CSI→应用一致备份；权限线检查认证→RBAC→准入与运行身份。每条线都要能指出失败证据和下一条最小检查。

配置审阅应检查 selector 与标签对应、探针路径在源码存在、PVC 挂载名闭合、Secret/ConfigMap 引用一致、observer 不读 secrets；不能确认目标集群准入、真实 CSI 行为、Registry 可用性或网络互通。

场景题：Running 与 Ready

Kubernetes Running Ready 问题：单副本 Pod Running，但 Deployment 无可用副本，是否应扩大 replicas？答案：先看 Ready 条件和探针。主例数据库不可读时 /ready 503，而 /live 仍可 200；复制相同故障配置只会扩大问题。Running 是阶段摘要，Ready 是是否适合接受流量的条件，业务授权成功又是另一层。

场景题：存储与更新

Kubernetes RWO Recreate 问题：为什么本例放弃无停机滚动？答案：一个 PVC 支撑单 SQLite 写入者，新旧 Pod 并发可能受挂载拓扑和写入锁影响。Recreate 停旧再新，明确承认停机；它没有生成跨节点数据副本，也不替代备份。要得到高可用，应从数据库和存储协议重新设计，而不是硬调 maxSurge。

追问：RWO 能保证只有一个 Pod 写吗？不能，它主要限制单节点挂载，同节点可能多个 Pod。不能用它替代应用层排他和数据一致性设计。

场景题：配置与权限

问题：更改 Secret 后旧 token 仍能用，是否说明 Secret 没更新？答案：本例进程启动时读取 token 后缓存，挂载文件变化不会自动改变进程内存。应先核对对象和文件，再按轮换计划重建；不能把文件投射的最终更新等同应用热加载。

问题：只给 observer 读日志是否等于没有敏感风险？答案：日志可能包含业务和凭据，应用必须避免打印 token，授予日志读取权也须按数据敏感度评估。本例只输出异常类型而不打印 Authorization。

完成标准与历史材料

读者应能解释调谐不是一次性脚本、apply 成功不是就绪、Secret 编码不是加密、requests 不是实时使用量、RWO 不是单 Pod 锁。给出故障时，应能提出最小只读取证并说明该证据的限度。

原 1.19 kubeadm 与 Kuboard v3 部署正文已移入编辑归档，旧 URL 保留兼容入口并指向现行解释；当代安装与安全不能沿用其中关闭防火墙、hostPath、cluster-admin 或过期源的选择。深入手册的对象、网络、存储和诊断解释继续保留。审阅范围与逐页取舍见 orchestration/audit.json，未声称逐条全文审计全部命令手册。

未来若要写运行通过，需读者记录版本/平台、镜像 digest、PVC 绑定、探针与端点、授权请求、Pod 重建后数据、Secret 轮换和实际清理后果。