本层负责什么
容器与编排层决定镜像如何启动、配置如何注入、资源如何限制以及实例何时被判定为健康。容器显示 running 并不代表服务可用，反复重启也不一定是平台故障。应把退出状态、事件、探针输出和容器内实际配置一起检查，区分应用失败、配置缺失、资源终止与调度问题。
常见症状
这些现象用于判断排查入口，不代表已经确定根因。先记录原始错误和时间，再执行首轮检查。
- 容器处于 Restarting、CrashLoopBackOff 或重启计数持续增加
- 容器保持 running，但健康检查连续失败或流量未被接收
- 退出码 137、143、配置错误码或 OOMKilled 状态
- 实例无法调度、镜像拉取失败、挂载或 Secret/Config 注入缺失
首轮检查清单
按顺序执行并保存输出。每一步只改变一个变量，避免让恢复动作覆盖真正的失败证据。
- 读取结构化状态保存 State、ExitCode、OOMKilled、RestartCount、Health 和最近事件，不只截取一行 ps。
- 检查前一次日志重启循环中优先读取上一个实例的日志，并记录首次致命错误而非后续重复噪声。
- 核对实际部署输入对照镜像摘要、命令、环境变量、挂载、Secret、探针和资源限制，确认运行态与声明一致。
- 隔离验证单一改动在同一镜像和负载下只修正一个配置或限制，比较退出状态和健康结果。
操作边界
inspect、日志和事件读取通常是只读操作。删除 Pod、强制重建、修改资源限制或暂停探针会改变服务容量；执行前必须确认副本数、流量切换和回滚清单。
何时升级或切换层级
当证据指向其他系统边界，立即带着时间、环境和原始输出交接，避免在当前层重复执行无关操作。
- 应用主动以非零码退出且配置完整：转给应用与运行时负责人。
- 节点资源压力、驱逐或运行时守护进程异常：携带节点事件升级给平台团队。
- 镜像、Secret 或配置供应链不一致：升级给构建发布与权限维护者。