3.3.1 Docker（容器技术）容器镜像、隔离、网络与资源治理

定位： 本文建立从 OCI（开放容器规范）镜像到受 namespace（命名空间）隔离、受 cgroup（控制组）限制的宿主机进程模型，并把网络、存储、生命周期、安全与业务恢复串成证据链。项目实际版本统一为“待现场核对”；文中数值均为演练样例，不能冒充生产事实。

版本与现场核对卡： Docker Engine（容器引擎）版本：待现场核对；containerd（容器运行时）版本：待现场核对；runc（低级容器运行时）版本：待现场核对；OCI Image Spec（开放容器镜像规范）版本：待现场核对；OCI Runtime Spec（开放容器运行时规范）版本：待现场核对；Linux（操作系统）内核与发行版：待现场核对；cgroup（控制组）v1（第一版）或 v2（第二版）：待现场核对；存储驱动、日志驱动、默认网络、默认地址池、默认停止宽限期与安全配置：待现场核对。

命令核对卡： docker info、docker version、docker inspect、docker image inspect、docker history --no-trunc、docker system df -v、docker stats --no-stream、docker events、docker logs、docker network inspect、docker volume inspect、ctr、crictl、runc、nsenter、lsns、ip、ss、conntrack、findmnt、df -h、df -i、journalctl、dmesg 与 /sys/fs/cgroup 的参数、权限、字段和默认值均须在只读优先、脱敏留痕的前提下现场核对；具有删除、清理、强杀、网络改写或压力注入效果的子命令不得直接在生产执行。

正式总图：docker-isolation-resource.png；源文件：docker-isolation-resource.puml。

1. OCI（开放容器规范）镜像对象、内容寻址与联合文件系统

OCI（开放容器规范）镜像不是一个“大压缩包”，而是一组由 digest（摘要）内容寻址的对象。manifest（清单）声明 config（配置）对象与有序 layer（层）对象；config（配置）保存入口、环境、用户、工作目录及 rootfs（根文件系统）层差异标识；layer（层）是文件系统变更归档。仓库标签只是可变指针，digest（摘要）才把字节内容固定。拉取时先解析 manifest（清单），再按本地内容库缺失集合下载、逐对象校验 digest（摘要）、解压快照并按顺序叠加。联合文件系统把多个只读 layer（层）呈现为一个根目录；首次修改下层文件时发生 copy-on-write（写时复制），新内容进入容器 writable layer（可写层），不会回写镜像层。数据库文件、任务检查点和审计结果属于持久化数据，不能因“目录看得见”就当作镜像资产。

flowchart LR
  T[标签：可变指针] --> M[manifest（清单）]
  M --> C[config（配置）]
  M --> L1[layer（层）A]
  M --> L2[layer（层）B]
  L1 --> U[联合文件系统]
  L2 --> U
  U --> W[writable layer（可写层）]
  W -.删除容器.-> X[失败：运行期变化丢失]
  M -.digest（摘要）不符.-> Y[失败：拒绝解包]

图 1 说明： 节点表示标签、manifest（清单）、config（配置）、只读 layer（层）、联合视图与 writable layer（可写层）；实线箭头表示引用或叠加，虚线箭头表示失败后果。前提是仓库对象和本地内容库可按 digest（摘要）校验。正常路径只下载缺失层并形成联合视图；失败路径是摘要不符被拒绝或删除容器后可写层消失。业务结论是发布身份使用 digest（摘要），状态数据必须外置。

sequenceDiagram
  participant E as Docker Engine（容器引擎）
  participant R as 镜像仓库
  participant C as 本地内容库
  participant S as 快照存储
  E->>R: 按标签或 digest（摘要）请求 manifest（清单）
  R-->>E: 返回 config（配置）与 layer（层）摘要
  E->>C: 检查本地缺失对象
  alt 对象完整且摘要一致
    E->>R: 只下载缺失对象
    R-->>E: 返回压缩对象
    E->>C: 校验并内容寻址保存
    E->>S: 解包并叠加快照
  else 摘要不符或空间不足
    E-->>E: 中止创建并保留错误证据
  end

图 2 说明： 参与者是容器引擎、仓库、本地内容库和快照存储，箭头表示解析、缺失检查、下载、校验和解包。前提是鉴权、平台架构和磁盘水位可用。正常路径复用已有对象；失败路径在摘要不一致或解包空间不足时中止。业务结论是“网络下载完成”不等于镜像已可运行，还要确认校验与解包完成。

数据演绎 1：500 MiB（兆字节）镜像分层。 演练镜像压缩后 500 MiB（兆字节），由 300 MiB（兆字节）基础层、120 MiB（兆字节）依赖层、60 MiB（兆字节）应用层和 20 MiB（兆字节）配置层组成。宿主已有前两层，则网络只拉 80 MiB（兆字节）；按有效带宽 40 MiB/s（兆字节每秒）约需 2 秒，但解压后若膨胀为 1.2 GiB（吉字节），还要计入校验、随机写和快照元数据。若先在 120 MiB（兆字节）层加入秘密再在后层删除，旧层仍保留字节，既不缩小镜像也构成泄漏。

热门面试题

1. 问题： manifest（清单）、config（配置）和 layer（层）如何协作？ 考点： OCI（开放容器规范）镜像对象关系。 回答思路： 从引用、运行元数据、文件差异和摘要校验回答。 详细答案： manifest（清单）固定目标平台及 config（配置）、有序 layer（层）的 digest（摘要）；config（配置）描述运行参数和根文件系统差异链；layer（层）保存文件变化。拉取端逐对象校验后按顺序解包，因此任一字节变化都会形成新 digest（摘要）。 进阶追问： 标签为何不能作为回滚证据？ 进阶回答： 标签可被重新指向，历史回滚必须保存并验证不可变 digest（摘要）。
2. 问题： copy-on-write（写时复制）为何可能拖慢数据库？ 考点： 联合文件系统写路径。 回答思路： 解释首次复制、元数据更新和持久化边界。 详细答案： 修改只读 layer（层）中的现有文件时，联合文件系统要先把对象复制到 writable layer（可写层）再修改；大文件和大量小文件会放大复制、元数据与 inode（索引节点）成本。数据库关键数据还会随容器删除而丢失，因此应写入经验证的数据卷。 进阶追问： 新文件也会复制下层内容吗？ 进阶回答： 新文件直接进入 writable layer（可写层），但仍受该层空间、inode（索引节点）和存储驱动约束。
3. 问题： 镜像层与持久化数据最本质的区别是什么？ 考点： 不可变制品与业务状态。 回答思路： 从生命周期、所有权和恢复责任回答。 详细答案： 镜像层由构建产生、按摘要分发且应只读；持久化数据由运行期业务产生，必须有独立生命周期、备份、一致性与恢复验证。把支付流水或 Runner（执行器）检查点写进 writable layer（可写层）会让进程重建等同数据丢失。 进阶追问： 容器提交为新镜像能否代替备份？ 进阶回答： 不能，它没有应用一致性边界、增量链、恢复点目标和可验证恢复流程。

2. Dockerfile（镜像构建文件）、缓存键与供应链门禁

Dockerfile（镜像构建文件）接收 build context（构建上下文）；未排除的大文件即使未复制也可能增加发送、哈希和缓存判断成本。缓存键不仅受指令文本影响，还受父层、复制文件内容、构建参数与构建器实现影响，具体语义待现场核对。multi-stage build（多阶段构建）把编译工具留在构建阶段，只把运行所需文件复制到最小运行镜像。基础镜像应固定 digest（摘要），语言依赖应锁定版本与完整性，构建网络输入必须可追溯；产出同时生成 SBOM（软件物料清单）、漏洞扫描结果、签名与 provenance（来源证明）。同一 digest（摘要）从测试环境晋级到生产环境，不在环境间重新构建；环境差异通过受控配置和密钥挂载注入。

flowchart LR
  S[源代码与锁文件] --> B[构建阶段]
  D[基础镜像 digest（摘要）] --> B
  B --> R[最小运行镜像]
  R --> M[SBOM（软件物料清单）]
  R --> V[漏洞扫描]
  R --> P[签名与 provenance（来源证明）]
  M --> G{门禁}
  V --> G
  P --> G
  G -->|通过| I[同一 digest（摘要）跨环境晋级]
  G -->|失败| X[阻断、修复或有期限例外]

图 3 说明： 节点是代码、锁文件、基础摘要、构建阶段、最小镜像和三类供应链证据；箭头表示输入汇聚与门禁判定。前提是构建身份可信且依赖源可追溯。正常路径让同一 digest（摘要）逐环境晋级；失败路径在漏洞、签名或来源不合格时阻断。业务结论是“重新构建相同版本”会制造新制品，破坏测试证据继承。

sequenceDiagram
  participant D as 开发者
  participant B as 构建器
  participant G as 制品门禁
  participant R as 镜像仓库
  participant E as 目标环境
  D->>B: 提交代码、锁文件与构建上下文
  B->>B: 多阶段构建并生成镜像
  B->>G: 提交 digest（摘要）、SBOM（软件物料清单）、扫描与来源证明
  alt 证据满足策略
    G->>R: 签名并保存不可变制品
    R->>E: 按同一 digest（摘要）晋级
  else 高风险漏洞或来源不明
    G-->>D: 阻断并返回组件证据
  end

图 4 说明： 参与者是开发者、构建器、门禁、仓库和目标环境，箭头表示证据随制品传递。前提是依赖锁和基础摘要未漂移。正常路径只晋级同一摘要；失败路径把具体组件和来源返回修复。业务结论是漏洞处置必须关联制品身份，不能只说“扫描已通过”。

数据演绎 2：构建上下文与缓存。 演练仓库源代码 80 MiB（兆字节），误把 2 GiB（吉字节）测试转储和 600 MiB（兆字节）本地依赖目录纳入 build context（构建上下文），每次构建需额外读取、发送或哈希 2.6 GiB（吉字节）。若把每次变化的源码复制放在依赖安装之前，改一行代码就可能让 120 MiB（兆字节）依赖层重建；先复制锁文件并安装依赖，再复制源码，可把高频变化限制在应用层。缓存是否命中仍以实际构建日志和构建器版本为准。

热门面试题

1. 问题： multi-stage build（多阶段构建）的主要价值是什么？ 考点： 构建环境与运行环境分离。 回答思路： 从攻击面、体积和可追溯运行依赖回答。 详细答案： 编译器、包管理缓存和测试工具只留在构建阶段，最终阶段复制经过确认的运行文件，减少镜像体积、漏洞暴露和误用工具的机会。但它不自动保证安全，仍需固定基础摘要、锁定依赖并生成供应链证据。 进阶追问： 最小镜像一定越小越好吗？ 进阶回答： 还要保留证书、时区、诊断和运行库等必要能力，并建立外部调试手段，不能因极小而失去可运维性。
2. 问题： 为什么基础镜像要固定 digest（摘要）？ 考点： 构建输入不可变。 回答思路： 区分标签的人类可读性与摘要的字节身份。 详细答案： 同一标签可能随上游更新指向不同字节，导致相同提交在不同时间产生不同结果；固定 digest（摘要）能重现输入并把漏洞关联到具体对象。升级时主动修改摘要并重新验证，而不是被动漂移。 进阶追问： 固定后如何获得安全更新？ 进阶回答： 由依赖更新流程发现新摘要、生成差异、重建扫描并逐级晋级。
3. 问题： 不可变制品跨环境晋级解决什么问题？ 考点： 证据连续性。 回答思路： 说明测试对象、生产对象和配置差异边界。 详细答案： 测试、预发和生产使用同一 digest（摘要），测试证据才能指向生产将运行的字节；环境配置与密钥在运行时受控注入。若每个环境重新构建，即使源码相同也可能因基础镜像、依赖源或时间变化产生不同制品。 进阶追问： 环境变量改变后还是同一制品吗？ 进阶回答： 镜像字节仍相同，但完整发布身份还应记录配置版本和密钥引用版本。

3. Docker Engine（容器引擎）到宿主机进程的运行时链

容器本质是宿主机进程，不是独立内核。Docker Engine（容器引擎）的 daemon（守护进程）接收创建意图并管理高层对象；containerd（容器运行时）管理镜像、快照和任务；shim（运行时垫片）承接标准输入输出、退出状态并让容器生命周期不必与上层守护进程完全绑定；runc（低级容器运行时）依据 OCI Runtime Spec（开放容器运行时规范）创建 namespace（命名空间）、挂载、能力和 cgroup（控制组），执行目标进程后通常退出。进程终止后，shim（运行时垫片）收集退出状态，上层清理任务、网络和挂载。不同安装方式和版本的进程树待现场核对，不能把概念链写成固定进程数量。

sequenceDiagram
  participant C as Docker Client（容器客户端）
  participant D as daemon（守护进程）
  participant T as containerd（容器运行时）
  participant S as shim（运行时垫片）
  participant R as runc（低级容器运行时）
  participant K as Linux（操作系统）内核
  C->>D: 创建并启动容器
  D->>T: 准备内容、快照与任务
  T->>S: 启动生命周期垫片
  S->>R: 传入运行规范
  R->>K: 创建 namespace（命名空间）、cgroup（控制组）与进程
  K-->>S: 目标进程运行
  R-->>S: 创建完成后退出
  alt 目标进程正常退出
    S-->>T: 返回退出码并触发清理
  else 创建阶段失败
    R-->>S: 返回挂载、权限或资源错误
    S-->>T: 保留失败阶段与原因
  end

图 5 说明： 参与者从客户端到内核，箭头表示高层意图逐级变成进程创建。前提是镜像已解包、运行规范有效且宿主资源可用。正常路径中 runc（低级容器运行时）完成创建后退出，shim（运行时垫片）继续守护生命周期；失败路径保留创建阶段错误。业务结论是 daemon（守护进程）重启、runc（低级容器运行时）退出与业务进程退出是三个不同事实。

数据演绎 3：创建与清理时间线。 演练一次启动共 1.8 秒：镜像对象检查 100 毫秒、快照准备 450 毫秒、网络与挂载 300 毫秒、runc（低级容器运行时）创建 150 毫秒、Java（编程语言）进程预热 800 毫秒。若 150 毫秒处报挂载权限错误，继续分析应用启动日志没有意义；若 1.8 秒后进程以退出码 1 结束，则创建链已成功，应查 PID 1（第一号进程）参数、依赖和应用异常。阶段时间必须来自事件和日志，而不是总耗时猜测。

热门面试题

1. 问题： 为什么说容器是受隔离和限制的宿主机进程？ 考点： 共享内核模型。 回答思路： 从进程实体、可见性和资源控制回答。 详细答案： 目标程序仍由宿主 Linux（操作系统）内核调度，namespace（命名空间）改变其可见对象，cgroup（控制组）限制或统计资源，能力与系统调用策略缩小权限。它没有自己的内核，因此宿主内核故障可同时影响多个容器。 进阶追问： 容器内看到 PID 1（第一号进程）是否是宿主第一进程？ 进阶回答： 不是，PID namespace（进程标识命名空间）提供局部编号，宿主能看到对应的另一进程标识。
2. 问题： shim（运行时垫片）解决了什么生命周期问题？ 考点： 上层守护与容器进程解耦。 回答思路： 结合输入输出、退出码和守护重启回答。 详细答案： shim（运行时垫片）承接目标进程的输入输出和退出状态，使上层运行时短暂重启时，已启动进程不必立刻被带走；它还在进程退出后向上报告并协助清理。具体行为与版本实现必须现场验证。 进阶追问： shim（运行时垫片）存在就代表应用健康吗？ 进阶回答： 不代表，它只说明生命周期组件存在，健康要看目标进程、依赖和业务结果。
3. 问题： runc（低级容器运行时）为何通常不是常驻业务守护？ 考点： 低级运行时职责边界。 回答思路： 区分创建动作与持续生命周期。 详细答案： runc（低级容器运行时）消费运行规范，完成命名空间、挂载、安全属性和目标进程创建后即可返回；持续输入输出、退出状态和上层对象由 shim（运行时垫片）及 containerd（容器运行时）承接。 进阶追问： 进程退出后的残留资源由谁清理？ 进阶回答： 由运行时链与内核共同完成，排障应分别核对任务、挂载、网络端点和 cgroup（控制组）是否残留。

4. namespace（命名空间）的隔离对象与泄漏边界

PID namespace（进程标识命名空间）隔离进程编号和可见进程树；mount namespace（挂载命名空间）隔离挂载视图；network namespace（网络命名空间）隔离网卡、地址、路由、端口与协议栈对象；UTS namespace（主机名命名空间）隔离主机名；IPC namespace（进程间通信命名空间）隔离部分进程间通信对象；user namespace（用户命名空间）映射容器内外用户标识。隔离不是“信息绝对不可见”：共享内核、显式挂载、宿主套接字、共享网络模式、过宽能力、设备映射和内核侧信号都可能跨边界。排障必须同时保留容器视角与宿主视角，不能把局部编号当全局身份。

flowchart TB
  H[宿主 Linux（操作系统）内核] --> P[同一宿主进程实体]
  P --> NP[PID namespace（进程标识命名空间）]
  P --> NM[mount namespace（挂载命名空间）]
  P --> NN[network namespace（网络命名空间）]
  P --> NU[UTS/IPC/user namespace（命名空间）]
  NM -.宿主目录挂载.-> L1[泄漏：文件边界扩大]
  NN -.共享主机网络.-> L2[泄漏：端口边界扩大]
  NU -.错误映射或过宽能力.-> L3[泄漏：权限边界扩大]

图 6 说明： 节点是共享内核、宿主进程实体和六类隔离视图，箭头表示同一进程被不同命名空间约束。前提是运行规范没有主动共享关键命名空间。正常路径只暴露声明对象；失败路径由宿主目录挂载、共享网络和错误用户映射扩大边界。业务结论是隔离强度取决于组合配置，不由“运行在容器里”自动保证。

数据演绎 4：双视角标识映射。 演练 Runner（执行器）在容器内看到 PID 1（第一号进程）和工作进程 PID 42（进程标识 42），宿主对应标识可能是 23100 与 23218；容器内 root（超级用户）若经 user namespace（用户命名空间）映射到宿主 100000，则在未额外授权时不能等同宿主 root（超级用户）。事故时间线应记录容器标识、宿主进程标识、cgroup（控制组）路径和启动时间，避免重启后局部标识复用导致串错证据。

热门面试题

1. 问题： 六类 namespace（命名空间）各自隔离什么？ 考点： 可见性边界。 回答思路： 按进程、文件、网络、主机名、通信和用户映射回答。 详细答案： PID（进程标识）管进程树，mount（挂载）管文件系统视图，network（网络）管网络栈对象，UTS（主机名）管主机名，IPC（进程间通信）管部分共享通信对象，user（用户）管用户与组标识映射。它们组合后形成视图隔离。 进阶追问： 哪一个 namespace（命名空间）负责限制内存？ 进阶回答： 都不负责，内存限制属于 cgroup（控制组）资源控制。
2. 问题： 为什么宿主能看到容器进程而容器未必看到宿主进程？ 考点： PID namespace（进程标识命名空间）层级。 回答思路： 从宿主全局视角和子命名空间局部视角解释。 详细答案： 容器进程仍是宿主内核管理的实体，宿主所在上层视角可观察它；子 PID namespace（进程标识命名空间）只暴露本空间及其后代允许看到的进程，并重新编号。排障需建立内外标识映射。 进阶追问： 只记录容器内 PID（进程标识）有什么风险？ 进阶回答： 重启后编号可复用，且无法与宿主调度、内核日志和 cgroup（控制组）证据稳定关联。
3. 问题： bind mount（绑定挂载）为何可能打破文件隔离？ 考点： 显式共享边界。 回答思路： 说明挂载视图、权限和宿主路径所有权。 详细答案： mount namespace（挂载命名空间）只隔离视图；一旦把宿主敏感目录显式映射进去，容器便可在进程权限与安全策略允许范围内访问该路径。读写挂载还可能修改宿主配置或其他工作负载数据。 进阶追问： 只读挂载是否绝对安全？ 进阶回答： 它降低写风险，但仍可能泄露秘密和元数据，也要限制路径、用户和读取能力。

5. cgroup（控制组）的配额、节流、回收与 OOM（内存溢出）

cgroup（控制组）把进程组织成资源控制树。CPU quota（处理器配额）限制一个周期内可消耗的处理器时间，耗尽后产生 throttling（节流），即使宿主仍有空闲核，受限组也可能等待下一周期；shares/weight（权重）主要在竞争时分配相对份额，不等同硬上限；cpuset（处理器集合）限定可运行核集合。memory limit（内存限制）统计口径包含匿名内存、部分 page cache（页缓存）和内核内存，具体字段依 cgroup（控制组）模式待现场核对；接近上限时先产生 memory pressure（内存压力）并尝试页面回收，回收不足且继续分配时才进入 OOM（内存溢出）选择与杀死。I/O（输入输出）限制约束吞吐或操作速率，PIDs（进程数）限制阻止进程/线程无限创建。容器内可能只看到延迟、分配失败或进程消失，宿主还要查看节流计数、压力、内核杀死和全机争用。

flowchart LR
  P[容器进程] --> C[cgroup（控制组）]
  C --> Q[CPU quota（处理器配额）]
  C --> W[weight（权重）/cpuset（处理器集合）]
  C --> M[memory limit（内存限制）]
  C --> I[I/O（输入输出）与 PIDs（进程数）]
  Q --> T[节流：等待下一周期]
  M --> R[页面回收与内核内存核算]
  R -->|回收成功| P
  R -->|回收不足且继续分配| O[OOM（内存溢出）选择并杀死]

图 7 说明： 节点是进程、控制组、处理器、内存、输入输出和进程数控制，箭头表示记账与限制结果。前提是进程已加入正确控制组且层级委派有效。正常路径在预算内运行或回收后继续；失败路径是配额节流、创建失败与 OOM（内存溢出）杀死。业务结论是高延迟不一定需要扩容，先区分硬配额、竞争权重和宿主瓶颈。

sequenceDiagram
  participant A as 应用进程
  participant M as cgroup（控制组）内存控制器
  participant K as Linux（操作系统）内核
  participant H as 宿主观测
  A->>M: 申请匿名内存并访问 page cache（页缓存）
  M->>M: 记账逼近 2 GiB（吉字节）上限
  M->>K: 触发页面回收与回写
  alt 回收释放足够页面
    K-->>A: 分配继续但延迟上升
    K-->>H: 记录 memory pressure（内存压力）
  else 回收不足且分配继续
    K->>K: 在约束边界内选择牺牲进程
    K-->>A: 发送杀死信号
    K-->>H: 记录 OOM（内存溢出）与计数
  end

图 8 说明： 参与者是应用、内存控制器、内核和宿主观测，箭头表示分配、记账、回收和杀死顺序。前提是内存控制器启用且统计口径已核对。正常路径在回收后继续但产生压力延迟；失败路径在回收不足后杀死进程。业务结论是 OOMKilled（容器内存杀死）之前通常已有压力信号，恢复不能只靠重启。

数据演绎 5：8 核宿主、2 核配额与 2 GiB（吉字节）内存。 演练宿主有 8 核，某 Runner（执行器）容器每 100 毫秒周期只获 200 毫秒处理器时间，等价最多持续使用 2 核。若 4 个工作线程每周期合计需要 320 毫秒，则约 120 毫秒需求被推迟，节流比例约 37.5%，宿主总利用率即使仅 45% 也可能出现任务尾延迟。该容器内存上限 2 GiB（吉字节）：Java（编程语言）堆 1.2 GiB（吉字节）、直接内存 320 MiB（兆字节）、线程栈 160 MiB（兆字节）、元数据 120 MiB（兆字节）、page cache（页缓存）300 MiB（兆字节），合计约 2.1 GiB（吉字节）。顺序应解释为逼近上限、回收 page cache（页缓存）、内存压力和延迟上升、回收不足、内核选择进程、记录 OOM（内存溢出）、目标进程退出，最终由运行时呈现 OOMKilled（容器内存杀死）。

热门面试题

1. 问题： CPU quota（处理器配额）和 weight（权重）有何区别？ 考点： 硬上限与竞争分配。 回答思路： 分别说明空闲与竞争场景。 详细答案： CPU quota（处理器配额）规定周期内最多可用处理器时间，耗尽后会节流；weight（权重）主要在多个组竞争时决定相对份额，宿主空闲时不一定限制使用。两者都要结合 cpuset（处理器集合）和线程并行度判断。 进阶追问： 宿主处理器空闲为何容器仍慢？ 进阶回答： 容器可能已耗尽本周期配额，或被限制在热点处理器集合上，只看宿主平均利用率会漏判。
2. 问题： OOMKilled（容器内存杀死）前内核通常做什么？ 考点： 内存压力、回收与杀死顺序。 回答思路： 从记账、回收、失败分配和牺牲进程回答。 详细答案： 内存使用逼近约束后，内核尝试回收可回收页面、回写脏页并产生压力；若有效工作集无法缩小且分配继续，才在相应约束边界内选择牺牲进程。应同时取压力、事件计数、内核日志和进程退出证据。 进阶追问： page cache（页缓存）都是可立即释放的吗？ 进阶回答： 不是，脏页可能先回写，活跃页面很快又被访问，回收会放大输入输出与延迟。
3. 问题： PIDs（进程数）限制为何也会限制线程？ 考点： Linux（操作系统）任务记账。 回答思路： 说明线程也是内核可调度任务。 详细答案： 在相关控制器记账中，线程创建会增加任务数量；达到上限后应用可能报无法创建原生线程或 fork（派生进程）失败。它能阻止进程炸弹，但过低会让 Java（编程语言）线程池、诊断工具或子进程异常。 进阶追问： 如何区分进程上限与内存不足？ 进阶回答： 交叉检查组内任务数和上限事件、应用错误、可用内存与内核日志，不能只凭同一句创建失败。

6. network namespace（网络命名空间）、网桥、转换与故障边界

默认桥接模型中，容器 network namespace（网络命名空间）内有虚拟网卡，veth（虚拟以太网对）另一端接入宿主 bridge（网桥）；同网桥容器可经二层转发和路由互通，访问宿主取决于宿主地址与防火墙，访问外部通常经宿主路由与 NAT（网络地址转换）。端口映射把宿主地址/端口的入站连接转换到容器地址/端口，不代表应用已监听正确地址。DNS（域名系统）解析受容器配置、转发器与上游影响；MTU（最大传输单元）不匹配会造成大包丢弃、分片或路径发现失败；连接跟踪表耗尽会让新连接丢失。网络排障要沿名称解析、套接字监听、路由、邻居/网桥、转换/防火墙、连接跟踪、链路 MTU（最大传输单元）和远端响应逐层取证。

flowchart LR
  C1[容器 A 网络命名空间] --> V1[veth（虚拟以太网对）]
  C2[容器 B 网络命名空间] --> V2[veth（虚拟以太网对）]
  V1 --> B[bridge（网桥）]
  V2 --> B
  B --> H[宿主路由与防火墙]
  H --> N[NAT（网络地址转换）与端口映射]
  N --> E[外部网络]
  C1 --> D[DNS（域名系统）]
  H -.连接跟踪表满.-> F1[失败：新连接丢失]
  E -.MTU（最大传输单元）不匹配.-> F2[失败：大包黑洞]

图 9 说明： 节点是两个容器网络空间、虚拟网卡、网桥、宿主路由、转换、外部网络和名称解析，箭头表示帧或包的转发路径。前提是地址、路由和转发策略正确。正常路径覆盖同桥、到宿主和到外部；失败路径展示连接跟踪耗尽与大包黑洞。业务结论是端口通不代表完整业务报文可通，必须按包大小和连接状态验证。

sequenceDiagram
  participant X as 外部客户端
  participant H as 宿主端口 18080
  participant N as NAT（网络地址转换）/连接跟踪
  participant B as bridge（网桥）/veth（虚拟以太网对）
  participant C as 容器端口 8080
  X->>H: 连接宿主地址:18080
  H->>N: 匹配端口映射
  N->>B: 改写目标为容器地址:8080
  B->>C: 交付连接
  alt 应用监听 0.0.0.0:8080
    C-->>X: 经反向转换返回响应
  else 仅监听 127.0.0.1 或映射缺失
    C-->>N: 拒绝或无监听
    N-->>X: 连接失败
  end

图 10 说明： 参与者是外部客户端、宿主端口、转换/连接跟踪、网桥链路和容器端口，箭头表示一次端口映射连接及反向返回。前提是宿主端口未冲突且规则已生效。正常路径要求容器应用监听可达地址；失败路径是只监听容器回环或规则缺失。业务结论是排查必须同时证明宿主入口和容器监听，不能只看映射配置。

数据演绎 6：端口映射、MTU（最大传输单元）与连接跟踪。 演练把宿主 18080 映射到容器 8080，小于 1 KiB（千字节）的健康请求成功，但 32 KiB（千字节）业务请求超时。容器侧 MTU（最大传输单元）为 1500 B（字节），底层隧道可承载 1450 B（字节），若路径发现报文被过滤，就可能出现小包通、大包黑洞。另有 100 个容器每个维持 800 条长连接，共 8 万条，再叠加短连接高峰，连接跟踪容量若只有约 10 万量级便接近高水位。具体阈值必须现场核对，不能通过扩大表容量掩盖连接泄漏。

热门面试题

1. 问题： 容器访问外部网络会经过哪些关键点？ 考点： 网络路径分层。 回答思路： 从容器路由、veth（虚拟以太网对）、网桥、宿主路由和转换回答。 详细答案： 包从 network namespace（网络命名空间）的虚拟接口发出，经 veth（虚拟以太网对）进入 bridge（网桥），再由宿主路由、防火墙和 NAT（网络地址转换）转发到外部；返回包还需连接状态和反向路由匹配。 进阶追问： 能解析域名为何仍可能连接失败？ 进阶回答： DNS（域名系统）只证明名称到地址，端口、路由、转换、MTU（最大传输单元）和远端服务仍可能失败。
2. 问题： 端口映射配置存在为何外部仍不可达？ 考点： 规则与监听边界。 回答思路： 核对宿主端口、转换规则、容器地址和监听地址。 详细答案： 可能是宿主端口冲突、防火墙拒绝、转换规则未生效、容器地址变化或应用只监听 127.0.0.1。应从外到内同时取套接字、规则、抓包和应用日志证据。 进阶追问： 宿主端口能建立连接是否代表业务正常？ 进阶回答： 不代表，还要发送代表性报文并验证远端响应、应用处理和业务结果。
3. 问题： 如何识别 MTU（最大传输单元）不匹配？ 考点： 小包成功大包失败。 回答思路： 对比不同包长、分片策略和路径抓包。 详细答案： 典型现象是连接建立或小请求成功，大响应、加密握手或批量传输停顿；按逐步增大包长测试，核对各层接口 MTU（最大传输单元）、路径发现和必要控制报文，再在容器与宿主两侧对齐抓包。 进阶追问： 直接统一调大 MTU（最大传输单元）可以吗？ 进阶回答： 不可盲调，路径最小承载能力才是上限，还需考虑隧道头部和中间设备。

7. writable layer（可写层）、挂载、备份与容量水位

writable layer（可写层）适合短生命周期临时变化，不具备独立数据生命周期。bind mount（绑定挂载）直接暴露宿主指定路径，性能和可控性清晰但强耦合主机布局与权限；volume（数据卷）由容器引擎管理位置与生命周期，便于迁移接口和备份流程，但仍需明确驱动与宿主故障域；tmpfs（内存文件系统）不落持久盘，适合敏感短暂数据或高速临时文件，重启即失且占内存预算。备份必须在应用一致性边界生成，恢复必须校验数据、权限、所有者和业务水位。磁盘既可能耗尽字节，也可能耗尽 inode（索引节点）；高水位还会让解包、日志、数据库临时文件和页面回写相互争用。数据库关键数据绝不能只留在容器可写层。

flowchart TB
  I[只读镜像层] --> U[联合根文件系统]
  U --> W[writable layer（可写层）]
  P[容器进程] --> W
  P --> B[bind mount（绑定挂载）]
  P --> V[volume（数据卷）]
  P --> T[tmpfs（内存文件系统）]
  W -.容器删除.-> L1[失败：实例数据丢失]
  V --> BK[一致性备份与恢复演练]
  B -.权限错配.-> L2[失败：读写拒绝或越权]
  T -.重启.-> L3[失败：内容消失]

图 11 说明： 节点是只读层、联合视图、可写层、三类挂载和备份，箭头表示进程写入的不同归属。前提是挂载目标、权限与容量预算已声明。正常路径把关键状态写入有备份的数据卷；失败路径覆盖容器删除、权限错配和内存文件重启丢失。业务结论是目录路径相同不代表数据所有权相同。

数据演绎 7：10 GiB（吉字节）可写层、inode（索引节点）与卷恢复。 演练异步导出把 10 GiB（吉字节）中间文件写进 writable layer（可写层），同时每个任务产生 20 万个 4 KiB（千字节）小分片；字节只约 0.76 GiB（吉字节）时也可能先耗尽 inode（索引节点）。改为 volume（数据卷）后，备份在任务暂停、缓冲刷出和清单提交完成的水位生成；恢复到新宿主时先挂载只读核对摘要、所有者和分片清单，再切换为读写并从最后提交检查点续跑。只看到卷已挂载不能证明导出结果完整。

热门面试题

1. 问题： bind mount（绑定挂载）与 volume（数据卷）如何选择？ 考点： 数据所有权与主机耦合。 回答思路： 比较路径控制、迁移、权限、备份和驱动。 详细答案： 需要明确映射宿主配置或受控目录时可用 bind mount（绑定挂载）；希望由容器平台管理位置和生命周期时使用 volume（数据卷）。两者都不自动提供备份、一致性或跨宿主恢复，必须按业务状态设计。 进阶追问： volume（数据卷）是否随容器删除？ 进阶回答： 取决于创建与删除方式，不能猜默认值，必须检查卷对象、引用和现场策略。
2. 问题： 磁盘还有空间为何仍无法创建文件？ 考点： inode（索引节点）与配额。 回答思路： 区分字节、inode（索引节点）、只读重挂载和权限。 详细答案： 大量小文件可能先耗尽 inode（索引节点）；还可能触发文件系统配额、保留块、只读保护或目录权限问题。应同时检查字节水位、inode（索引节点）水位、挂载状态、内核日志和目标目录写入错误。 进阶追问： 删除一个大文件一定能恢复吗？ 进阶回答： 不一定，若问题是 inode（索引节点）耗尽、文件仍被进程打开或底层只读，删除大文件不能解决根因。
3. 问题： 为什么数据库不能把关键数据只留在 writable layer（可写层）？ 考点： 实例生命周期与状态恢复。 回答思路： 从容器替换、写时复制、备份和一致性回答。 详细答案： writable layer（可写层）跟随容器实例，替换或误删可能失去数据；联合文件系统还会引入写时复制和容量不透明。数据库需要独立卷、应用一致性备份、日志链和恢复演练，确保进程重建不改变数据所有权。 进阶追问： 把目录复制出来算可靠备份吗？ 进阶回答： 只有在数据库认可的一致性边界和完整日志条件下才可能成立，普通在线复制可能得到互相不一致的文件。

8. PID 1（第一号进程）、信号、健康、日志与重启边界

容器 PID 1（第一号进程）承担特殊信号处理和孤儿进程回收责任。若启动脚本不使用 exec（执行）把目标程序替换为主进程，终止信号可能停在脚本，应用收不到优雅退出通知；不回收退出子进程会积累 zombie process（僵尸进程）。优雅停止应先停止接收新工作，等待在途请求或提交任务检查点，刷新必要缓冲并在宽限期内退出；超时后强杀可能留下未知结果。restart policy（重启策略）只决定何时重建进程，不修复数据、依赖或配置。healthcheck（健康检查）应区分“进程活着”和“能够承担职责”，且不能用高成本检查制造故障。日志驱动和 rotation（轮转）必须有阻塞、丢弃、容量与保留策略；同步日志管道拥塞可能反压业务线程。

sequenceDiagram
  participant O as 停止控制方
  participant P as PID 1（第一号进程）
  participant A as 应用工作线程
  participant D as 外置状态/数据卷
  participant K as Linux（操作系统）内核
  O->>P: 发送终止信号，宽限期 30 秒
  P->>A: 转发信号并停止接收新任务
  A->>D: 完成在途事务或提交检查点
  alt 30 秒内完成
    A-->>P: 清理完成
    P-->>O: 正常退出
  else 脚本吞信号或任务未收敛
    O->>K: 宽限期后请求强杀
    K-->>P: 强制终止
    D-->>O: 状态可能未知，必须核验恢复
  end

图 12 说明： 参与者是停止控制方、第一号进程、工作线程、外置状态和内核，箭头表示 30 秒优雅停止与超时强杀。前提是信号可到达应用且业务支持检查点或幂等恢复。正常路径在限时内清理并退出；失败路径由脚本吞信号或任务未收敛触发强杀。业务结论是退出码只能说明进程结果，业务状态必须另行核验。

数据演绎 8：100 个容器日志与 30 秒优雅停止。 演练 100 个容器每个持续写 200 KiB/s（千字节每秒）日志，总速率约 19.5 MiB/s（兆字节每秒），一天原始量约 1.65 TiB（太字节）；若无轮转，日志盘会先于业务盘告警。停止时给 30 秒：前 3 秒从端口摘流量，最长在途请求 8 秒，Runner（执行器）检查点写入 12 秒，缓冲刷新 4 秒，总预算 27 秒，仅余 3 秒抖动。若第 3 秒就把进程标记为恢复，尚未完成的检查点可能被重复执行；若 30 秒后强杀，则按任务幂等键和外置检查点判定续跑位置。

热门面试题

1. 问题： PID 1（第一号进程）为何需要正确转发信号？ 考点： 容器停止语义。 回答思路： 从脚本、目标进程和强杀后果回答。 详细答案： 停止信号通常先送到 PID 1（第一号进程）；若它只是不会转发的脚本，真正应用无法停止接流量、提交检查点或刷新缓冲，最终只能被强杀。使用正确 exec（执行）形式或可靠的 init（初始化）进程可建立信号和回收边界。 进阶追问： 应用收到信号就算优雅停止完成吗？ 进阶回答： 不算，还要确认停止接流量、在途收敛、状态提交与进程退出都完成。
2. 问题： restart policy（重启策略）为什么不等于恢复？ 考点： 进程动作与业务正确性。 回答思路： 区分可运行、依赖可用、数据正确和任务续跑。 详细答案： 重启只创建新进程；若根因是损坏配置、卷权限、外部依赖、OOM（内存溢出）或非幂等任务，重启会重复失败甚至扩大副作用。恢复必须用业务权威状态、积压和一致性证据确认。 进阶追问： 哪些场景适合自动重启？ 进阶回答： 短暂进程故障且启动幂等、状态外置、退避有界并有失败升级机制时更合适。
3. 问题： 日志驱动如何反过来阻塞业务？ 考点： 输出管道背压。 回答思路： 从标准输出、缓冲、驱动和下游说明。 详细答案： 应用同步写标准输出时，若驱动缓冲、磁盘或远端采集变慢，写调用可能阻塞业务线程；若选择丢弃则会产生证据缺口。必须记录模式、队列、丢弃、轮转和盘水位，并把审计事实写入独立可靠通道。 进阶追问： 增大缓冲能彻底解决吗？ 进阶回答： 只能吸收短时突发，长期写入大于排出仍会耗尽内存或磁盘，必须限量、采样或治理日志源。

9. 非 root（超级用户）、最小权限与共享内核风险

安全基线从非 root（超级用户）运行开始，但用户标识只是第一层。user namespace（用户命名空间）可把容器内高权限标识映射到宿主非特权范围；capability（能力）把传统超级用户权限拆分为更小集合，应按职责删除而不是全量保留；seccomp（系统调用过滤）限制可调用的内核接口；AppArmor（应用安全配置）和 SELinux（安全增强式 Linux）按路径、标签与策略约束访问；只读根文件系统减少持久篡改面，必要写目录单独挂载；密钥以最小可见、只读、可轮换的挂载或受控通道提供，不能写入镜像层和普通日志。rootless（无特权）模式降低守护与容器进程获得宿主高权限的风险，但网络、存储、性能和功能边界待现场核对。容器共享宿主内核，内核漏洞、危险设备、宿主套接字和过宽能力仍可能突破边界，其安全隔离通常弱于拥有独立客体内核的虚拟机。

flowchart LR
  P[容器进程] --> U[非 root（超级用户）与用户映射]
  U --> C[最小 capability（能力）]
  C --> S[seccomp（系统调用过滤）]
  S --> L[AppArmor（应用安全配置）/SELinux（安全增强式 Linux）]
  L --> F[只读根与最小挂载]
  F --> K[共享宿主内核]
  K -.内核漏洞或危险设备.-> X[失败：隔离边界突破]
  F -.宿主套接字或秘密误挂载.-> Y[失败：控制面或凭据泄露]

图 13 说明： 节点按用户、能力、系统调用、强制访问、文件挂载到共享内核逐层收缩权限，箭头表示纵深防御。前提是策略已在目标发行版验证且业务确有最小权限清单。正常路径让进程仅获完成职责所需权限；失败路径是内核漏洞、危险设备、宿主套接字或秘密误挂载越界。业务结论是多个薄控制叠加才形成边界，任何单一开关都不是虚拟机级隔离。

数据演绎 9：权限收缩。 演练 IoT（物联网）采集器原以 root（超级用户）运行、拥有 14 项额外 capability（能力）、根文件系统可写并挂载宿主容器套接字。整改后使用固定非特权用户，只保留绑定低端口确需的单项 capability（能力）或改用高端口，根文件系统只读，写入仅限 64 MiB（兆字节）tmpfs（内存文件系统）与独立数据卷，密钥只读挂载。风险面明显缩小，但若宿主内核发生严重故障，100 个同宿主容器仍可能同时不可用，必须靠节点隔离、补丁和故障域设计处理。

热门面试题

1. 问题： 非 root（超级用户）运行是否足够安全？ 考点： 纵深防御。 回答思路： 列出用户、能力、系统调用、访问控制和挂载边界。 详细答案： 不足。非特权用户减少直接权限，但过宽 capability（能力）、危险系统调用、宿主敏感挂载、设备访问或内核漏洞仍可能越界。需要叠加用户映射、最小能力、seccomp（系统调用过滤）、强制访问控制和只读根文件系统。 进阶追问： 容器内 root（超级用户）一定等于宿主 root（超级用户）吗？ 进阶回答： 不一定，user namespace（用户命名空间）可映射到宿主非特权用户，但是否启用及映射范围必须现场核对。
2. 问题： capability（能力）与 seccomp（系统调用过滤）有什么区别？ 考点： 权限与调用面。 回答思路： 一个回答“能做哪类特权动作”，一个回答“能调用哪些接口”。 详细答案： capability（能力）拆分高权限操作授权；seccomp（系统调用过滤）按系统调用及部分参数限制进入内核的接口。两者互补：即使某调用存在，没有相应能力也可能被拒绝；反之能力存在，策略仍可阻断不应使用的调用。 进阶追问： 直接使用最严格策略可以吗？ 进阶回答： 必须在目标工作负载和诊断流程中验证，过严会让合法启动、线程、网络或排障调用失败。
3. 问题： rootless（无特权）模式的边界是什么？ 考点： 风险降低而非风险消失。 回答思路： 从守护权限、用户映射、功能和共享内核回答。 详细答案： rootless（无特权）让守护和容器不依赖宿主超级用户权限，可降低错误配置和部分逃逸后果；但网络、存储驱动、低端口、资源控制能力可能受环境限制，且仍共享宿主内核。是否适用要以现场功能与性能验证决定。 进阶追问： 它能替代内核补丁吗？ 进阶回答： 不能，共享内核仍需及时修复、最小攻击面和故障域隔离。

10. 十类故障的五层证据、双信号、止血、修复与回归

统一使用五层证据：制品层确认 digest（摘要）、仓库、解包与供应链；运行时层确认 daemon（守护进程）、containerd（容器运行时）、shim（运行时垫片）、退出码和事件；内核/资源层确认 namespace（命名空间）、cgroup（控制组）、网络、文件系统与内核日志；进程层确认 PID 1（第一号进程）、线程、套接字、文件和应用错误；业务层确认订单、库存、资金、轨迹、任务或报警结果。每类故障至少取两类信号：事件/日志是离散因果，指标/计数是持续趋势，必要时再加包、进程树、文件清单和业务审计。止血只控制扩散，修复消除根因，回归必须覆盖原始症状和业务不变量。

sequenceDiagram
  participant A as 告警/用户症状
  participant F as 五层证据采集
  participant S as 止血控制
  participant R as 根因修复
  participant B as 业务权威状态
  A->>F: 固定时间窗、容器标识与发布 digest（摘要）
  F->>F: 制品→运行时→内核资源→进程→业务
  F->>S: 用两类信号确认扩散路径
  S->>B: 降级、暂停、限流或隔离
  B-->>S: 返回库存/资金/轨迹/任务影响
  S->>R: 在影响受控后修复根因
  R->>F: 复现原始症状并执行故障注入
  alt 技术信号与业务不变量均恢复
    B-->>A: 关闭事故并记录证据
  else 仅进程恢复或证据不足
    F-->>A: 保持事故开放，继续核验
  end

图 14 说明： 参与者是症状入口、五层采集、止血、修复和业务权威状态，箭头表示从固定身份到闭环回归。前提是时间、容器、宿主、digest（摘要）和业务键可关联。正常路径在技术与业务证据同时恢复后关闭；失败路径是只见进程恢复或证据不足。业务结论是排障不是命令清单，而是可证伪的分层假设。

数据演绎 10：同一“接口慢”的三种根因。 演练 WMS（仓储管理系统）接口高分位从 180 毫秒升至 2.4 秒。场景一：处理器使用仅 1.9 核，但 2 核配额节流时间占窗口 35%，应调整并行与配额；场景二：内存 1.95 GiB（吉字节）逼近 2 GiB（吉字节），页面回收每秒扫描激增且磁盘读放大，应降低工作集并修内存预算；场景三：小包健康检查正常，大响应重传并停在 1450 B（字节）附近，应查 MTU（最大传输单元）。三者应用层都可能只报超时，必须用资源指标/网络计数与日志/抓包两类信号区分。

热门面试题

1. 问题： 为什么排障必须保留五层证据？ 考点： 现象归属与业务闭环。 回答思路： 说明相同症状可能跨层产生。 详细答案： 启动失败可能来自镜像入口、运行时快照、内核权限、应用配置；技术进程恢复后，库存或任务仍可能处于未知状态。五层让假设可逐层证伪，并把容器动作连接到业务不变量。 进阶追问： 五层是否每次都要全量采集？ 进阶回答： 先用低成本证据缩小范围，但事故关闭前必须覆盖根因所在层、相邻影响层和业务确认层。
2. 问题： 两类信号为什么比单条日志可靠？ 考点： 离散事件与连续趋势互证。 回答思路： 用 OOM（内存溢出）或节流举例。 详细答案： 单条日志可能丢失、误报或缺少时间范围；内核 OOM（内存溢出）事件结合内存曲线能说明杀死与压力过程，节流计数结合请求延迟能说明资源限制与用户影响。两类信号仍需业务事实完成确认。 进阶追问： 指标恢复到正常能关闭事故吗？ 进阶回答： 不能自动关闭，还要核对积压、未知交易、任务检查点和用户结果。
3. 问题： 止血、修复和回归怎样区分？ 考点： 事故阶段管理。 回答思路： 分别回答控制影响、消除根因和证明不复发。 详细答案： 止血通过限流、降级、暂停或隔离阻止影响扩大；修复处理泄漏、配置、权限或容量根因；回归重现原症状、注入关键故障并验证技术指标和业务不变量。把扩容当修复会留下同类故障。 进阶追问： 临时提高内存上限属于哪类？ 进阶回答： 通常是止血，除非经过工作集测量、容量模型和回归证明它就是正确长期预算。

11. 共享内核、镜像分层、资源配额与不可变基础设施的权衡

容器以共享内核换取秒级启动、更高密度和统一交付接口，代价是安全边界与故障域弱于虚拟机；镜像分层以内容寻址和层复用减少分发、存储和构建成本，代价是历史层难以“后删”、小文件/元数据和供应链对象增多；资源限制把 noisy neighbor（邻居噪声）从隐性争抢变成显式配额、权重、节流和 OOM（内存溢出）结果，代价是预算错误会在宿主仍有余量时主动制造延迟或杀死；immutable infrastructure（不可变基础设施）用替换而非在线修改减少漂移，代价是所有状态必须外置、可备份、可恢复，启动和迁移流程必须成熟。这些不是单向收益，而是把复杂度从“机器漂移”转移到“制品、状态与策略治理”。

数据演绎 11：密度收益与宿主内核故障。 演练一台 32 核、128 GiB（吉字节）宿主承载 40 个平均 0.5 核、2 GiB（吉字节）的无状态容器，平均请求合计约 20 核、80 GiB（吉字节），密度良好；若把支付、库存和 IoT（物联网）入口都放在同一宿主，单次宿主内核故障会同时失去三个业务域。即使每个容器有 2 GiB（吉字节）限制，也无法隔离内核崩溃。应按业务关键性和故障域分散，保留节点余量并演练外置状态恢复；不能用容器数量证明高可用。

热门面试题

1. 问题： 容器与虚拟机的安全边界为何不同？ 考点： 共享内核与独立客体内核。 回答思路： 比较隔离机制、攻击面和故障域。 详细答案： 容器通过同一宿主内核的 namespace（命名空间）、cgroup（控制组）和安全策略隔离进程，内核漏洞或宿主故障可能跨容器影响；虚拟机通常有独立客体内核和虚拟化边界，开销更高但隔离更强。选择取决于威胁模型。 进阶追问： 所有敏感业务都必须用虚拟机吗？ 进阶回答： 不是绝对，应结合租户可信度、内核攻击面、合规、节点隔离和恢复目标分层选择。
2. 问题： 镜像分层为何既省空间又增加风险？ 考点： 内容复用与历史不可消除。 回答思路： 说明摘要复用、旧层保留和依赖传播。 详细答案： 相同 layer（层）按 digest（摘要）只存和传一次，能加速拉取；但敏感文件在后层删除仍留于旧层，基础层漏洞会传播到多个镜像，层数和小文件还增加解包元数据。需要构建上下文、层顺序和供应链治理。 进阶追问： 合并所有层是否最佳？ 进阶回答： 不一定，会失去跨镜像复用和缓存粒度，应以安全、变更频率和拉取数据决定。
3. 问题： 不可变基础设施为何要求状态外置？ 考点： 替换式交付。 回答思路： 从实例销毁、状态所有权和恢复回答。 详细答案： 不可变实例通过新制品替换旧实例，不依赖在线修补；若关键状态绑在实例可写层，替换就会丢数据或阻断回滚。因此状态必须进入有独立身份、备份和恢复协议的数据库、对象存储或数据卷。 进阶追问： 缓存也必须持久化吗？ 进阶回答： 可再生缓存可以随实例丢失，但要评估重建风暴、下游压力和冷启动预算。

12. WMS（仓储管理系统）、支付、跨境物流、异步导出、Runner（执行器）与 IoT（物联网）项目落地

项目表达必须包含资源预算、数据卷、信号、降级、恢复和证据边界。WMS（仓储管理系统）库存服务优先保证低延迟请求，批量盘点和导出受处理器/输入输出预算约束；支付服务最小权限运行，密钥只读挂载，终止前停止接单并完成本地提交或把未知请求送对账；跨境物流轨迹消费允许积压但要保留游标和幂等键；异步导出把临时分片、清单和检查点放在受配额数据卷，磁盘高水位时拒绝新大任务；Runner（执行器）限制 PIDs（进程数）、并发和单任务内存，强杀后按外置状态续跑；IoT（物联网）长连接入口预算连接跟踪与文件描述符，报警风暴时聚合降级而不是无限写日志。任何容器指标都不能直接证明库存未超卖、资金一致、轨迹完整或任务完成。

sequenceDiagram
  participant G as 停流量/降级控制
  participant W as WMS（仓储管理系统）/支付接口
  participant R as Runner（执行器）/导出
  participant I as IoT（物联网）/物流消费
  participant S as 外置权威状态
  participant E as 五层证据
  G->>W: 停接新请求并保留幂等键
  G->>R: 停止领取并提交检查点
  G->>I: 降采集频率、聚合报警、保留游标
  W->>S: 提交库存/资金本地状态
  R->>S: 提交任务游标与分片清单
  I->>S: 提交轨迹游标与设备状态
  alt 宽限期内全部确认
    S-->>E: 返回可恢复水位
    E-->>G: 放行正常退出或迁移
  else 超时强杀或宿主内核故障
    E->>S: 按业务键核对未知结果
    S-->>G: 选择补偿、续跑、重连或人工复核
  end

图 15 说明： 参与者是降级控制、三类工作负载、外置权威状态和五层证据，箭头表示停止时提交业务水位。前提是幂等键、检查点、游标和审计状态独立于容器。正常路径在宽限期内确认后退出；失败路径覆盖强杀与宿主内核故障，并回到权威状态判定。业务结论是统一容器生命周期必须映射成各业务不同的恢复协议。

数据演绎 12：六项目资源预算与恢复。 演练同宿主 8 核：WMS（仓储管理系统）接口配 2 核，支付配 2 核，跨境物流配 1 核，异步导出与 Runner（执行器）合计 2 核，IoT（物联网）配 1 核；配额总和等于 8 核但没有突发余量，因此不能同时长期跑满。内存分别按 2、2、1、2、1 GiB（吉字节）只是上限样例，仍需叠加宿主内核和运行时开销。宿主内核故障后，支付先查未知流水，库存核对扣减账，物流从确认游标续跑，导出校验分片清单，Runner（执行器）按检查点重领，IoT（物联网）分批重连防止连接风暴；恢复顺序由业务损失而非容器启动速度决定。

热门面试题

1. 问题： WMS（仓储管理系统）批任务如何避免拖慢库存接口？ 考点： 资源分组与业务优先级。 回答思路： 从处理器、内存、输入输出和任务降级回答。 详细答案： 将批任务放入独立 cgroup（控制组）或独立实例，限制处理器、内存、输入输出和并发；磁盘或数据库压力升高时暂停批任务，库存接口保留预算。回归同时看节流、尾延迟和库存扣减正确性。 进阶追问： 只降低批任务线程数够吗？ 进阶回答： 不一定，还要限制单任务内存、临时文件、查询压力和输入输出带宽。
2. 问题： 支付容器被 OOMKilled（容器内存杀死）后如何恢复？ 考点： 未知结果与资金一致性。 回答思路： 先止新请求，再查权威流水和外部渠道。 详细答案： 新实例启动不代表旧请求失败。按支付幂等键查询本地流水、渠道状态与回调，已成功则返回既有结果，明确失败才重试，未知进入查单或对账；同时修正堆、堆外和并发预算，并用故障注入验证。 进阶追问： 重放入口日志可以判定结果吗？ 进阶回答： 不能，入口日志只证明收到请求，资金结果以本地账务和渠道权威状态为准。
3. 问题： Runner（执行器）与 IoT（物联网）为何需要不同优雅停止策略？ 考点： 长任务与长连接差异。 回答思路： 对比检查点、连接排空、重连和幂等。 详细答案： Runner（执行器）先停止领任务，提交当前步骤检查点并释放子进程；IoT（物联网）入口先停止新连接或迁移流量，分批断开并控制设备重连速率。两者都需外置状态，但恢复单位分别是任务步骤和设备会话/上报序号。 进阶追问： 统一 30 秒宽限期是否合理？ 进阶回答： 只能作为上层边界，内部阶段预算要按请求、任务和连接特性测量，超时后走不同恢复协议。

13. 版本核对卡、复习闭环与综合推演入口

本文不把任何随 Docker Engine（容器引擎）、containerd（容器运行时）、runc（低级容器运行时）、Linux（操作系统）内核、cgroup（控制组）模式、存储驱动或发行版变化的行为写成无条件默认。现场核对按“身份、配置、实际、事件、业务”五步：先记录宿主、内核、运行时、镜像 digest（摘要）和容器标识；再导出只读配置与安全策略；随后观察 cgroup（控制组）、namespace（命名空间）、网络、挂载和进程实际状态；对齐事件、日志、指标、包和内核记录；最后用库存、资金、轨迹、任务、文件清单或设备状态确认。复习时按“镜像对象→供应链→运行时→隔离→资源→网络→存储→生命周期→安全→排障→权衡→项目”顺序口述，任何一步若只剩工具名，都返回节点、箭头、前提、正常路径、失败路径和业务结论重建因果。

热门面试题

1. 问题： 为什么版本与默认值统一写“待现场核对”？ 考点： 版本敏感性与证据纪律。 回答思路： 说明实现、发行版、安装方式和配置都可改变行为。 详细答案： 命令字段、cgroup（控制组）模式、日志与存储驱动、默认网络、安全策略和停止行为都可能随版本或部署方式变化。先写待核对，再用现场输出固定前提，可避免把教程环境错误投射到生产。 进阶追问： 这会不会让回答显得不确定？ 进阶回答： 机制结论可以确定，具体版本、默认值和阈值用证据确定，区分两者反而更严谨。
2. 问题： 如何快速复习本文而不退化成命令清单？ 考点： 因果模型复述。 回答思路： 沿镜像到进程、状态到恢复的链路回答。 详细答案： 先讲 digest（摘要）固定镜像对象，再讲运行时创建受 namespace（命名空间）和 cgroup（控制组）约束的宿主进程，随后串网络、卷、信号和安全；最后用五层证据说明故障，并以业务权威状态确认恢复。 进阶追问： 每个图至少要说出什么？ 进阶回答： 节点、箭头、前提、正常路径、失败路径和业务结论六项。
3. 问题： 如何判断自己真正掌握容器资源治理？ 考点： 从概念到数据与事故闭环。 回答思路： 要求能算预算、解释内外视角并设计回归。 详细答案： 能用 8 核/2 核配额解释节流，用 2 GiB（吉字节）预算解释回收与 OOM（内存溢出），能区分 writable layer（可写层）与数据卷，能沿网络和运行时取证，并能把重启后的业务核验说完整，才算形成可操作模型。 进阶追问： 只会背命令为什么不够？ 进阶回答： 命令输出只是某层证据，不说明因果、版本前提和业务是否恢复。

综合面试题

以下 30 题均按口述场景组织；答案中的版本和阈值仍需现场核对。每题后附本文件真实相对 Markdown（标记语言）详情链接。

1. 综合问题： 请完整解释一个 500 MiB（兆字节）OCI（开放容器规范）镜像如何被拉取并变成运行进程。

   • 口述答案： 我会把它分成对象解析、内容传输、快照解包和进程创建四段。镜像标签只是入口，仓库返回 manifest（清单），其中固定目标平台、config（配置）和有序 layer（层）的 digest（摘要）；引擎先比较本地内容库，只下载缺失对象，逐对象校验摘要后按内容寻址保存。假设压缩镜像共 500 MiB（兆字节），宿主已有 300 MiB（兆字节）基础层与 120 MiB（兆字节）依赖层，网络只需拉 80 MiB（兆字节）；有效带宽 40 MiB/s（兆字节每秒）时下载约 2 秒，但还要计算校验、解压后约 1.2 GiB（吉字节）空间和快照元数据，不能把下载完成当可运行。只读层按顺序组成联合根文件系统，容器运行期修改进入 writable layer（可写层），首次修改下层既有文件会发生 copy-on-write（写时复制）。之后 daemon（守护进程）把任务交给 containerd（容器运行时），shim（运行时垫片）承接生命周期，runc（低级容器运行时）按 OCI Runtime Spec（开放容器运行时规范）创建 namespace（命名空间）、cgroup（控制组）、挂载和目标进程。失败要按阶段定位：鉴权/缺层属于仓库，摘要不符属于内容校验，空间不足属于解包，挂载或权限错误属于创建，应用退出才进入进程层。最终以 digest（摘要）、进程、资源边界和业务探测四类证据确认，而不是只看“容器为运行状态”。
   • 追问 1： 标签与 digest（摘要）冲突时信谁？
   • 直接回答 1： 发布和回滚信不可变 digest（摘要），标签只作可变的人类入口。
   • 追问 2： 镜像压缩 500 MiB（兆字节）为何磁盘需求更大？
   • 直接回答 2： 内容库存压缩对象，快照还要解包文件并维护元数据，运行期另有可写层。
   • 追问 3： 拉取成功能否判定业务可用？
   • 直接回答 3： 不能，还需创建、启动、依赖与业务结果证据。
   • 详情：OCI（开放容器规范）镜像对象、内容寻址与联合文件系统

2. 综合问题： 如何设计可复现、可晋级、可回滚的 Dockerfile（镜像构建文件）供应链？

   • 口述答案： 我的核心原则是固定所有可变输入，并让证据随同一 digest（摘要）跨环境传递。构建入口记录代码提交、Dockerfile（镜像构建文件）、依赖锁文件、构建参数和构建器身份；基础镜像不用浮动标签，固定摘要，升级通过显式变更重新测试。build context（构建上下文）用排除规则移除转储、密钥、本地依赖和无关大文件，既减少发送与哈希成本，也避免秘密进入历史 layer（层）。指令顺序按变化频率组织：先复制锁文件并恢复依赖，再复制高频变化源码，提高缓存复用；multi-stage build（多阶段构建）在构建阶段编译和测试，最终只复制运行文件、证书与必需诊断能力，使用非 root（超级用户）和最小运行镜像。产出后生成 SBOM（软件物料清单），把系统包和语言依赖关联到镜像摘要；执行漏洞扫描，但扫描结果必须记录数据库时间、策略和有期限例外，不能说“零漏洞”；再由可信构建身份签名并生成 provenance（来源证明）。测试、预发和生产只晋级同一 digest（摘要），配置与密钥作为独立版本在运行时注入。回滚选择已通过门禁的历史摘要，同时检查配置、数据库兼容和外部副作用。若生产临时重建，测试证据就失去对象一致性，因此必须阻断这种做法。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： 最小运行镜像是否应删除所有诊断工具？
   • 直接回答 1： 不必绝对删除，应保留运行必需内容并建设受控的外部诊断路径。
   • 追问 2： 锁文件存在就能可复现吗？
   • 直接回答 2： 还要固定基础摘要、依赖源、构建器和网络输入，并验证产出。
   • 追问 3： 漏洞扫描失败能否人工放行？
   • 直接回答 3： 只能按风险、暴露面、补偿控制、责任人和到期时间形成可审计例外。
   • 详情：Dockerfile（镜像构建文件）、缓存键与供应链门禁

3. 综合问题： daemon（守护进程）重启后容器为何可能仍在运行，如何证明？

   • 口述答案： 我先区分控制对象、生命周期垫片和业务进程。daemon（守护进程）负责高层接口与对象管理，containerd（容器运行时）管理内容、快照和任务，shim（运行时垫片）承接目标进程输入输出与退出状态，runc（低级容器运行时）通常只在创建阶段按运行规范设置隔离与执行进程，完成后返回。因此在实现和配置支持的前提下，上层 daemon（守护进程）短暂重启，不必把已经由 shim（运行时垫片）维持的业务进程一同终止；但这个行为不能只靠概念推断，版本与现场模式必须核对。证明时先固定容器标识、宿主进程标识、启动时间和 cgroup（控制组）路径，在重启前后采集目标进程存活、套接字监听、shim（运行时垫片）进程、containerd（容器运行时）任务与事件；再发代表性只读请求，确认进程仍承担业务，而不是只剩生命周期残影。还要验证日志管道和退出状态上报是否连续，因为业务可运行不代表管理面完全恢复。若 daemon（守护进程）回来后对象状态不一致，应停止变更，保留任务和挂载证据，避免盲目删除。事故结论应写成“业务进程在该时间窗持续运行，管理面于某时恢复”，不能写“容器没有影响”，因为镜像拉取、创建、日志、网络变更等控制操作可能受影响。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： runc（低级容器运行时）进程消失是否异常？
   • 直接回答 1： 创建完成后退出通常符合其职责，需结合创建结果与 shim（运行时垫片）判断。
   • 追问 2： 只看业务端口能证明容器仍在吗？
   • 直接回答 2： 不能，端口可能由其他进程接管，应关联进程、命名空间和容器标识。
   • 追问 3： 管理面恢复后为何还要查日志链？
   • 直接回答 3： 输入输出或退出状态可能在重启窗口中断，影响后续审计与清理。
   • 详情：Docker Engine（容器引擎）到宿主机进程的运行时链

4. 综合问题： 如何向面试官解释“容器不是轻量虚拟机”？

   • 口述答案： 我会从内核、进程、可见性、资源和故障域五点说明。容器中的应用仍是宿主 Linux（操作系统）内核调度的进程，宿主能看到其真实进程实体；PID namespace（进程标识命名空间）只让容器看到局部编号和进程树，mount namespace（挂载命名空间）提供独立挂载视图，network namespace（网络命名空间）提供网卡、路由与端口视图，UTS/IPC/user namespace（命名空间）分别隔离主机名、通信对象和用户映射。它们改变“看见什么”，不提供独立内核。cgroup（控制组）负责处理器、内存、输入输出和进程数的统计与限制，解决“能用多少”，同样不是虚拟硬件。安全上再叠加非 root（超级用户）、capability（能力）、seccomp（系统调用过滤）、AppArmor（应用安全配置）或 SELinux（安全增强式 Linux），仍无法消除共享内核漏洞和宿主故障。虚拟机通常运行独立客体内核，通过虚拟化边界隔离，启动和密度成本更高，但对不可信租户或强隔离场景往往更合适。项目上，容器适合快速交付 WMS（仓储管理系统）接口和 Runner（执行器），但支付与库存不能因为容器隔离就忽略节点故障域、密钥和业务状态恢复。结论不是谁全面优于谁，而是容器用共享内核换速度和密度，虚拟机用更多资源换更强边界。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： user namespace（用户命名空间）能让容器拥有独立内核吗？
   • 直接回答 1： 不能，它只映射用户标识，系统调用仍进入宿主内核。
   • 追问 2： namespace（命名空间）与 cgroup（控制组）谁负责隔离进程列表？
   • 直接回答 2： PID namespace（进程标识命名空间）负责可见性，cgroup（控制组）负责资源组织与限制。
   • 追问 3： 何时更倾向虚拟机？
   • 直接回答 3： 不可信多租户、强合规隔离或需要独立内核控制时更倾向虚拟机。
   • 详情：namespace（命名空间）的隔离对象与泄漏边界

5. 综合问题： 8 核宿主上的容器只给 2 核配额，为什么宿主空闲时请求仍然慢？

   • 口述答案： 关键是区分宿主总利用率与 cgroup（控制组）周期预算。假设处理器周期为 100 毫秒，容器每周期配额 200 毫秒处理器时间，等价于可持续使用 2 核；应用有 4 个工作线程，在一个周期合计需要 320 毫秒，则用完 200 毫秒后剩余需求要等下一周期，约 120 毫秒被推迟，需求节流比例约 37.5%。宿主其余 6 核即使空闲，也不改变该组硬配额。若 weight（权重）较低，则只有与其他组竞争时份额受影响，空闲时未必封顶；若 cpuset（处理器集合）仅允许两个热点核，平均空闲同样掩盖局部运行队列。排障时取两类信号：一类是 cgroup（控制组）节流周期、节流时长、配额和处理器集合，另一类是应用请求高分位、线程池队列和任务吞吐；再看宿主每核利用率与运行队列排除全机瓶颈。止血可降低批任务并发、关闭非关键计算或增加实例分片，不能先无脑加线程，因为更多线程会更快耗尽同一配额并增加切换。长期修复要根据单请求处理器成本、目标吞吐和突发余量重算预算，或优化算法与批量处理。回归需在代表性并发下同时验证吞吐、高分位、节流比例和关键业务成功率，证明不是把压力转给数据库或下游。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： 2 核配额是否意味着只能在两个固定核运行？
   • 直接回答 1： 不一定，配额限制时间总量，固定核集合由 cpuset（处理器集合）决定。
   • 追问 2： 提高 weight（权重）能消除硬配额节流吗？
   • 直接回答 2： 不能，weight（权重）调竞争份额，硬配额耗尽仍会节流。
   • 追问 3： 为什么平均延迟不足以回归？
   • 直接回答 3： 周期节流主要推高尾部等待，平均值可能掩盖尖峰。
   • 详情：cgroup（控制组）的配额、节流、回收与 OOM（内存溢出）

6. 综合问题： 请演绎 2 GiB（吉字节）内存限制下 OOMKilled（容器内存杀死）的完整顺序。

   • 口述答案： 我不会把它简化成“Java（编程语言）堆超过 2 GiB（吉字节）”。先建立完整预算：堆 1.2 GiB（吉字节）、直接内存 320 MiB（兆字节）、线程栈 160 MiB（兆字节）、元数据与运行库 120 MiB（兆字节）、活跃 page cache（页缓存）300 MiB（兆字节），合计约 2.1 GiB（吉字节），还未计入部分内核内存。进程继续分配或读取文件时，cgroup（控制组）记账逼近 memory limit（内存限制），内核先尝试回收不活跃 page cache（页缓存）、回写脏页并限制分配速度，此时容器内可能表现为垃圾回收频繁、输入输出上升和请求高分位恶化。若工作集活跃、脏页回写跟不上或匿名内存无法回收，memory pressure（内存压力）持续；新的分配仍无法满足时，内核在相应约束边界内选择牺牲进程并发送杀死信号，运行时随后记录终止原因，外层才可能显示 OOMKilled（容器内存杀死）。证据至少包括内存当前值/事件/压力曲线、内核 OOM（内存溢出）记录、进程堆/堆外/线程数据和业务任务状态。止血是暂停大导出、降低并发、保留必要转储条件；修复是重算堆外与缓存预算、修泄漏或拆分工作负载；恢复按幂等键和检查点确认未知任务，不能把重启成功当完成。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： page cache（页缓存）为何计入容器压力？
   • 直接回答 1： 文件访问产生的缓存可能进入该组记账，口径依 cgroup（控制组）模式现场确认。
   • 追问 2： 把堆调小一定能解决吗？
   • 直接回答 2： 可能给堆外留余量，也可能加剧垃圾回收，必须按完整工作集压测。
   • 追问 3： 只看到退出码能证明 OOM（内存溢出）吗？
   • 直接回答 3： 不能，需要运行时原因、内核事件和内存压力互证。
   • 详情：cgroup（控制组）的配额、节流、回收与 OOM（内存溢出）

7. 综合问题： 如何排查容器能访问外部、外部却访问不了容器？

   • 口述答案： 我先画清方向：容器出站通常使用默认路由，经 veth（虚拟以太网对）、bridge（网桥）、宿主路由和 NAT（网络地址转换）访问外部；外部入站还需要宿主地址/端口映射到容器地址/端口，因此出站成功不能证明入站链。五层取证时，制品层核对应用预期端口和启动参数；运行时层检查端口映射对象与容器当前地址；内核网络层检查宿主端口冲突、防火墙、转换规则、连接跟踪和两侧 network namespace（网络命名空间）路由；进程层用套接字证据确认应用监听 0.0.0.0:8080 而非只监听 127.0.0.1:8080；业务层发送代表性请求并检查授权和响应。两类信号可用宿主/容器双侧抓包与连接错误日志，再辅以新建连接计数。若宿主 18080 到容器 8080 配置存在，但宿主只收到首次握手而容器侧无包，问题在规则或转发；容器收到并立即拒绝，则查监听；握手成功而大响应停顿，再转向 MTU（最大传输单元）或应用。止血可临时切换到已验证实例或受控备用端口，修复要消除冲突、监听或策略根因，回归覆盖不同源地址、小包、大包、长连接和重启后规则持续性。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： 容器内监听 127.0.0.1 为什么映射不可达？
   • 直接回答 1： 映射流量到达容器非回环接口，而应用只接受本地回环连接。
   • 追问 2： 宿主能连 18080 是否足够？
   • 直接回答 2： 不足，还要从真实外部路径和代表性业务报文验证。
   • 追问 3： 出站 NAT（网络地址转换）和入站端口映射共用哪些证据？
   • 直接回答 3： 都要核对路由、防火墙、转换规则、连接跟踪与返回路径。
   • 详情：network namespace（网络命名空间）、网桥、转换与故障边界

8. 综合问题： 小包正常、大包超时，如何证明是 MTU（最大传输单元）不匹配？

   • 口述答案： 我会先排除名称解析、监听和业务处理，再用包长阶梯验证路径承载。假设容器接口 MTU（最大传输单元）为 1500 B（字节），底层隧道增加头部后只允许 1450 B（字节）；小于 1 KiB（千字节）的健康请求可通过，32 KiB（千字节）响应需要分段，若路径 MTU（最大传输单元）发现依赖的控制报文被过滤，发送方又设置不可分片，就可能形成大包黑洞。证据一是容器和宿主两侧同步抓包：看到发送重传、某一大小以上无确认或控制报文异常；证据二是网络重传、超时和接口丢弃计数随大包测试上升。再逐跳核对容器 veth（虚拟以太网对）、bridge（网桥）、宿主物理接口、隧道与中间网络的 MTU（最大传输单元），确认最小值与封装开销。止血可在已验证范围内降低报文大小、关闭大批量响应或切换无隧道路径，但不能随意全局调大。修复要统一端到端配置，允许必要路径发现报文，或让隧道端正确调整。回归不仅用连通测试，还要覆盖握手、接近边界包长、真实加密响应和双向长流，并验证没有引入过度分片和处理器开销。业务层最终确认导出、物流批量轨迹或支付回调正文完整，而非只看连接建立。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： 为什么握手成功仍可能是 MTU（最大传输单元）问题？
   • 直接回答 1： 握手包小，后续证书、正文或批量响应才跨越路径承载边界。
   • 追问 2： 把所有接口设成 1400 B（字节）可以吗？
   • 直接回答 2： 需基于实际最小路径和封装计算，过小会增加分段与处理开销。
   • 追问 3： 应用日志没有错误如何处理？
   • 直接回答 3： 网络黑洞可能发生在应用之外，应以双侧抓包和内核计数互证。
   • 详情：network namespace（网络命名空间）、网桥、转换与故障边界

9. 综合问题： 数据库把 10 GiB（吉字节）关键数据写在容器可写层，有什么风险，如何迁移到卷？

   • 口述答案： 风险不只是“容器删了文件没了”。writable layer（可写层）属于具体容器实例，替换、重建或清理可能改变其生命周期；联合文件系统对已有文件首次修改会 copy-on-write（写时复制），大数据库文件可能放大复制和元数据成本；可写层与镜像解包、日志共用宿主空间时，10 GiB（吉字节）增长还会挤压其他容器。迁移不能在线随手复制目录，因为数据库多个文件和日志可能不在同一一致性点。我会先识别数据库支持的备份/复制机制、当前写入量、恢复点目标和停机边界，建立目标 volume（数据卷）的容量、inode（索引节点）、输入输出、所有者和安全标签。低风险方案是在受控窗口停止写入、让数据库完成检查点并正常关闭，再复制与校验；需要低停机则用数据库原生全量加增量日志追平，在最终切换点冻结写入、确认日志水位并切换挂载。首次启动先只读或隔离验证文件权限、版本兼容、校验和和恢复日志，再开放流量。旧可写层在观察窗口内保留但禁止双写，回滚也必须明确日志分叉边界。回归包括正常读写、崩溃恢复、容器重建、卷重新挂载和真实备份恢复。最终以数据库一致性检查和业务账本确认，不以目录大小相同或容器启动成功作为完成。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
   • 追问 1： docker commit 能否保存这 10 GiB（吉字节）数据？
   • 直接回答 1： 不能当数据库备份，它缺少应用一致性、日志水位和恢复验证。
   • 追问 2： 切卷后旧可写层何时删除？
   • 直接回答 2： 完成观察窗口、备份恢复验证和回滚边界确认后再受控清理。
   • 追问 3： 卷挂载成功是否代表权限正确？
   • 直接回答 3： 不代表，还要验证目标用户读写、所有者、安全标签和数据库实际操作。
   • 详情：writable layer（可写层）、挂载、备份与容量水位

10. 综合问题： 100 个容器的日志如何做容量、阻塞和证据边界治理？

• 口述答案： 先量化而不是直接调轮转。若 100 个容器每个持续写 200 KiB/s（千字节每秒），总速率约 19.5 MiB/s（兆字节每秒），一天原始量约 1.65 TiB（太字节）；任何只按“保留七天”而不算压缩、峰值、索引和转发的数据都不可信。我会把日志分成业务审计、错误诊断、访问事件和调试噪声：资金与库存审计不能只依赖普通容器日志，必须写入有事务或独立可靠性的权威通道；诊断日志允许有明确的有界缓冲和丢弃策略，但要暴露丢弃计数。运行时核对日志驱动、阻塞模式、单文件大小、文件数量和轮转时机，宿主核对磁盘字节、inode（索引节点）、写延迟与打开但已删除文件，进程层用线程栈判断标准输出写入是否阻塞，业务层看请求高分位与错误率。止血先降低动态日志级别、采样重复事件、暂停低价值调试输出并保护审计通道，不能直接删活动文件。修复包括结构化字段治理、按事件价值限量、异步有界写入、驱动轮转、采集端背压与独立磁盘预算。回归要故障注入下游采集不可用和磁盘高水位，验证业务线程不被无限阻塞、丢弃可见、轮转能释放空间，并确认关键业务事实仍可审计。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 增加日志盘能否作为长期修复？
• 直接回答 1： 只能延后耗尽，若写入长期大于处理仍会再次满盘。
• 追问 2： 删除日志文件后空间为何不释放？
• 直接回答 2： 进程可能仍持有打开句柄，需确认写入者并通过受控轮转释放。
• 追问 3： 为什么审计日志要独立？
• 直接回答 3： 普通日志可能采样、丢弃、轮转或阻塞，不能作为资金与库存唯一权威证据。
• 详情：PID 1（第一号进程）、信号、健康、日志与重启边界

11. 综合问题： 容器启动即退时，如何用五层证据避免盲目重启？

• 口述答案： 我先停止无限 restart policy（重启策略）造成的证据覆盖，固定镜像 digest（摘要）、容器标识、宿主、创建时间和最近退出码。制品层确认目标架构、入口、工作目录、用户、依赖文件和配置引用，避免把错误平台镜像或缺失启动文件带到后面；运行时层查看创建、启动、退出事件，区分 runc（低级容器运行时）在挂载/权限阶段失败，还是目标进程已经 exec（执行）后退出；内核层检查只读根、卷、安全策略、PIDs（进程数）、内存与内核拒绝记录；进程层读取标准错误、应用异常和实际参数，必要时用同一镜像覆盖入口做只读检查，但不得改变生产证据；业务层确认该实例未承载流量、队列是否缺消费者、是否存在未知任务。两类信号至少是运行时事件/退出原因与应用/内核日志，若怀疑资源再加计数曲线。止血是保留可用旧实例、暂停新摘要扩散并设置有界退避；修复根据阶段处理入口、配置、架构、权限或依赖，而不是把健康检查调宽。回归从无缓存冷拉取开始，覆盖卷挂载、最小权限、依赖不可用、正常启动、代表性请求和 30 秒信号停止。最后以业务端点、任务消费和权威状态确认恢复，不能用“容器不再退出”作为唯一结论。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 退出码 0 但容器仍停止，可能是什么？
• 直接回答 1： 主进程正常结束，常见于把一次性脚本误当常驻服务或后台化了真正进程。
• 追问 2： 为什么先停循环重启？
• 直接回答 2： 高频重启会覆盖日志、放大依赖压力并让进程标识反复变化。
• 追问 3： 用交互式外壳检查是否安全？
• 直接回答 3： 只在受控副本、只读优先并记录与正式入口差异，不能替代原失败路径。
• 详情：十类故障的五层证据、双信号、止血、修复与回归

12. 综合问题： 镜像拉取失败时，如何区分仓库、网络、摘要和磁盘问题？

• 口述答案： 先把“拉取失败”拆成解析、鉴权、下载、校验和解包五个阶段。记录请求的是标签还是 digest（摘要）、目标平台、仓库地址、宿主和时间窗；制品层直接读取 manifest（清单）引用，确认对象是否存在、权限是否允许、平台是否匹配。若在解析/鉴权阶段失败，重点检查凭据范围、证书、代理与名称解析；若下载中断，比较仓库端请求日志、客户端重试与宿主网络丢包；若对象下载完成却 digest（摘要）不符，禁止绕过校验，检查仓库对象损坏、中间缓存或并发覆盖；若校验通过但解包失败，查看内容库、快照目录的字节、inode（索引节点）、只读状态和输入输出错误。两类信号选择运行时拉取事件/错误日志和网络、磁盘、下载字节指标，必要时对同一摘要在隔离宿主做冷拉取对照。止血是暂停新版本、保持已有健康副本、降低并发拉取，不能清理仍被引用的全部缓存。修复按根因更新仓库对象/权限、证书代理、网络路径或磁盘容量；若摘要对象确实损坏，应从可信构建重发新摘要，不偷偷替换旧摘要语义。回归要在无本地层缓存的宿主按摘要拉取、逐对象校验、解包、创建并发出业务探测，同时验证失败重试不会打满仓库或节点磁盘。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 同一宿主已有缓存为何不能证明仓库正常？
• 直接回答 1： 本地可复用旧对象，可能完全没有访问仓库缺失层。
• 追问 2： 空间充足为何解包仍失败？
• 直接回答 2： 还可能是 inode（索引节点）、只读挂载、配额、权限或底层输入输出错误。
• 追问 3： 能否关闭摘要校验先上线？
• 直接回答 3： 不能，这会破坏内容身份和供应链边界，应修复可信对象。
• 详情：OCI（开放容器规范）镜像对象、内容寻址与联合文件系统

13. 综合问题： 如何处理镜像扫描发现高风险漏洞且生产正在运行该摘要？

• 口述答案： 我先区分“组件存在”“漏洞可达”“生产已被利用”三件事。以 digest（摘要）锁定受影响镜像，通过 SBOM（软件物料清单）确定组件版本、所在 layer（层）、直接或传递依赖以及所有运行实例；记录扫描数据库和发现时间，避免不同数据库结果混淆。随后结合工作负载暴露面、是否调用易受影响功能、网络入口、capability（能力）、seccomp（系统调用过滤）和强制访问策略评估紧急度，同时搜索异常系统调用、网络连接、文件变化与业务审计，不能仅凭扫描就宣称入侵。若存在现实暴露，止血可先关闭受影响功能、收紧网络和权限、隔离实例并暂停继续晋级；若修复镜像已生成，则固定新基础摘要、更新依赖、重新构建 SBOM（软件物料清单）、扫描、签名和 provenance（来源证明），按同一新摘要逐级验证。回滚并非回到任意旧标签，而是选择已知不受该漏洞影响且与当前配置/数据兼容的历史 digest（摘要）；如果旧版本也有更严重风险，就采用修复前进。上线后对比错误率、关键业务、系统调用拒绝和资源数据，并保留旧实例取证边界。最终记录影响清单、例外到期、修复摘要和验证证据，让“已修复”指向生产真实运行对象，而不是仓库里多了一个新镜像。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 组件存在就必须立即停机吗？
• 直接回答 1： 需结合可达性、暴露面和补偿控制，但高风险例外必须有责任人与到期时间。
• 追问 2： 修复后为何要生成新 digest（摘要）？
• 直接回答 2： 字节变化必然形成新内容身份，不能篡改旧摘要语义。
• 追问 3： 漏洞镜像回滚如何验证？
• 直接回答 3： 验证摘要、签名、配置/数据兼容、业务结果和漏洞不可达证据。
• 详情：Dockerfile（镜像构建文件）、缓存键与供应链门禁

14. 综合问题： 如何处理 writable layer（可写层）磁盘爆满而宿主仍有其他分区空间？

• 口述答案： 我会先定位实际存储边界，而不是看到宿主某个分区有空间就认为无容量问题。记录容器、存储驱动、内容库、快照目录、日志目录和各挂载对应的文件系统；制品层看镜像解包与 layer（层）体积，运行时层看 writable layer（可写层）、日志和残留快照，内核层同时看目标文件系统字节、inode（索引节点）、配额、只读重挂载和输入输出错误，进程层检查最大目录、打开但已删除文件与持续写入者，业务层识别临时导出、缓存或结果文件能否再生。两类信号使用容量/增长指标与具体写入错误、运行时事件；清理前建立文件所有权清单。止血是停止低优先级导出与噪声日志、拒绝新大任务、把流量切到有余量实例，并只清理已确认可再生且无进程引用的对象；禁止直接删除运行时内部目录。修复包括把关键数据和大临时文件迁到有配额 volume（数据卷）、设置日志 rotation（轮转）、任务清理期限、字节与 inode（索引节点）双水位告警，并给镜像解包留突发空间。若文件删除后空间未回收，查打开句柄并通过受控重开或轮转释放。回归模拟 10 GiB（吉字节）临时文件和小文件峰值，验证高水位前拒绝新任务、关键状态仍可写、清理速度大于增长且容器重建不丢业务数据。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 为什么不能直接执行全局清理？
• 直接回答 1： 可能删除仍需的镜像、快照或卷，并破坏其他容器的恢复条件。
• 追问 2： 字节水位低还要看 inode（索引节点）吗？
• 直接回答 2： 要，大量小文件可在字节未满时先耗尽 inode（索引节点）。
• 追问 3： 分区扩容属于修复吗？
• 直接回答 3： 通常先算止血，仍需治理无界增长、所有权和水位策略。
• 详情：writable layer（可写层）、挂载、备份与容量水位

15. 综合问题： volume（数据卷）恢复后，怎样证明恢复的是一致数据而非“文件都在”？

• 口述答案： 我会先定义恢复点和应用一致性，而不是从复制文件开始。备份时记录数据卷身份、应用版本、数据库或任务的检查点/日志水位、分片清单、校验和、所有者和安全标签；若应用持续写入，必须使用其支持的快照、备份或暂停协议，保证多个文件之间属于同一逻辑时点。恢复到新卷后先隔离流量并以只读方式核对备份清单、对象数量、摘要、字节与 inode（索引节点），再检查用户映射、权限、挂载选项和底层驱动。对数据库执行崩溃恢复、日志重放与一致性检查，对异步导出核对已提交游标、分片边界、行数和总摘要，对 Runner（执行器）核对任务状态机与最后检查点。随后启动受控实例，只执行只读查询或影子任务，对比旧权威状态；确认应用版本与数据格式兼容后再开放少量流量。若恢复点之后存在增量日志或业务补偿，按明确顺序追平，避免新旧实例双写导致分叉。两类信号一类是存储/应用恢复日志与校验结果，另一类是业务账本、任务清单或抽样结果。回归必须实际从备份创建新卷并完成恢复时间目标，不能只验证备份作业绿色。最终证据是业务不变量与水位一致，而不是挂载成功或目录大小相同。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 文件摘要都一致为何仍可能不可用？
• 直接回答 1： 备份本身可能跨不一致时点，或应用版本、权限和日志链不兼容。
• 追问 2： 恢复时能同时让旧实例写吗？
• 直接回答 2： 除非有明确复制协议，否则会产生分叉，应建立单写边界。
• 追问 3： 备份成功率能替代恢复演练吗？
• 直接回答 3： 不能，只有实际恢复才能验证介质、步骤、权限、兼容和时长。
• 详情：writable layer（可写层）、挂载、备份与容量水位

16. 综合问题： 如何设计一个 30 秒内可安全停止的 Runner（执行器）容器？

• 口述答案： 我把 30 秒拆成可观测阶段，而不是在信号处理里睡满宽限期。PID 1（第一号进程）必须是能转发终止信号并回收子进程的应用或可靠 init（初始化）进程，启动脚本用 exec（执行）交出主进程身份。收到信号后前 2 至 3 秒停止领取新任务并从入口摘除；正在运行的任务根据类型选择在安全点完成当前原子步骤，或在 12 秒预算内把任务标识、输入摘要、当前步骤、输出分片和幂等键提交到外置状态；再用约 5 秒通知子进程停止并 wait（等待）回收，4 秒刷新必要日志与指标，预留至少 6 秒给存储抖动和运行时清理。若单个原子步骤天然超过预算，不能阻塞到完成，应把步骤拆小或设计租约和可重放检查点。超时强杀后，新实例先读取任务权威状态：检查点已提交则从下一步续跑，未提交则按幂等键重做当前步，状态未知则人工或补偿核验，不能因进程消失就标记失败。两类信号包括终止阶段耗时/在途任务指标与信号、退出、检查点日志。回归覆盖空闲、单任务、多个子进程、状态存储慢、信号被脚本吞、30 秒强杀和宿主崩溃，验证无僵尸、无重复副作用且恢复时间可接受。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构，并完成复盘与容量复核。
• 追问 1： healthcheck（健康检查）何时应失败？
• 直接回答 1： 停止领取后应从可接流量/任务状态摘除，但进程可继续完成清理。
• 追问 2： 检查点多久写一次？
• 直接回答 2： 根据重做成本、写放大和一致性边界压测，不能只按固定时间猜测。
• 追问 3： 强杀后可以把任务直接重置吗？
• 直接回答 3： 先核对检查点和外部副作用，避免重复执行非幂等步骤。
• 详情：PID 1（第一号进程）、信号、健康、日志与重启边界

17. 综合问题： 僵尸进程不断增加时，如何定位并修复？

• 口述答案： zombie process（僵尸进程）表示子进程已经退出，但父进程尚未 wait（等待）回收其退出状态，它不再消耗普通执行资源，却占用任务表项，最终可能触发 PIDs（进程数）上限并让新线程/进程创建失败。首先固定容器与宿主进程标识，用容器内外进程树对齐父子关系，确认僵尸状态、父进程、增长速率和启动方式；运行时层检查 PID 1（第一号进程）究竟是应用、外壳脚本还是 init（初始化）进程，内核/cgroup（控制组）层查看当前任务数、上限事件和创建失败，应用层查看子任务派生与回收代码，业务层确认哪些 Runner（执行器）任务可能已完成但状态未登记。两类信号是僵尸/任务数量曲线与进程创建失败、父进程日志或系统调用证据。止血是暂停派生新子进程、降低并发并受控替换受影响实例，不能反复给僵尸发送杀死信号，因为它们已退出。修复要让父进程正确处理子退出并循环 wait（等待），或使用经过验证的 init（初始化）进程转发信号和回收孤儿；同时检查脚本后台化、双重派生和异常路径遗漏。回归批量启动并结束超过峰值数量的短子任务，验证僵尸迅速归零、PIDs（进程数）稳定、退出码被正确记录，停止信号还能在 30 秒边界内完成。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 僵尸进程占大量内存吗？
• 直接回答 1： 通常只保留少量内核退出信息，但数量大可耗尽任务表或 PIDs（进程数）预算。
• 追问 2： 杀父进程能清理吗？
• 直接回答 2： 可能由上层进程接管并回收，但会影响业务，只能受控止血且仍需修代码。
• 追问 3： 添加 init（初始化）进程一定解决吗？
• 直接回答 3： 只有子进程成为其可回收后代且配置正确才有效，应用自身仍应管理直接子进程。
• 详情：PID 1（第一号进程）、信号、健康、日志与重启边界

18. 综合问题： 容器以非 root（超级用户）运行后卷权限报错，如何处理而不回退到超级用户？

• 口述答案： 我先把权限拆成数字用户标识、user namespace（用户命名空间）映射、传统所有者/模式、挂载只读标志和 AppArmor（应用安全配置）/SELinux（安全增强式 Linux）等强制策略。制品层确认镜像声明的用户与应用实际需要写的目录，运行时层确认 volume（数据卷）或 bind mount（绑定挂载）目标和读写选项，宿主层检查路径所有者、组、访问控制和安全标签，容器内核对映射后的有效用户，进程层保留具体访问拒绝路径，业务层确认是否出现部分文件或未提交任务。两类信号选择访问拒绝审计/内核策略日志与应用写失败计数。止血是停止继续写入，避免一半文件由旧用户、一半由新用户创建；可把流量切回已验证实例，但不把容器改为 root（超级用户）或开放全目录写权限。修复应为数据卷建立稳定用户/组契约，在初始化或受控迁移阶段调整所有者，若启用 user namespace（用户命名空间）则按宿主映射范围换算；强制访问控制按最小路径和动作授权，密钥目录继续只读。对已有海量文件，权限迁移要评估扫描时间和输入输出影响，可按目录分批并保留水位。回归覆盖新卷、旧卷、备份恢复卷、只读密钥、重建实例和不同宿主，验证应用所需路径可写、非目标路径不可写，且业务清单完整。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 直接 chmod 777 为什么不可取？
• 直接回答 1： 它扩大所有用户写权限且不解决安全标签、映射或只读挂载问题。
• 追问 2： 容器内用户 1000 与宿主一定相同吗？
• 直接回答 2： 不一定，user namespace（用户命名空间）可能映射到另一宿主范围。
• 追问 3： 权限改完能立刻开放流量吗？
• 直接回答 3： 先验证新旧文件读写、所有者、策略拒绝和业务一致性。
• 详情：非 root（超级用户）、最小权限与共享内核风险

19. 综合问题： rootless（无特权）模式适合什么场景，如何做上线判断？

• 口述答案： rootless（无特权）的价值是让容器守护和工作负载不以宿主 root（超级用户）身份运行，通常结合 user namespace（用户命名空间）把容器用户映射到普通宿主用户范围，能降低误配置、守护接口暴露和部分逃逸后的权限后果。但它不是安全银弹：进程仍共享宿主内核，内核漏洞不消失；网络转发、低端口、存储驱动、cgroup（控制组）委派、设备访问和性能特征可能受内核、发行版与安装方式影响，所有具体行为写“待现场核对”。上线前我会做职责清单：应用是否需要特权端口、设备、宿主网络、特殊挂载或完整资源控制；再做兼容矩阵，验证镜像拉取、volume（数据卷）、日志、端口映射、DNS（域名系统）、MTU（最大传输单元）、处理器/内存限制、优雅停止和诊断路径。安全验证不仅检查进程用户，还尝试访问宿主敏感路径、容器套接字和不必要系统调用，确认 capability（能力）与 seccomp（系统调用过滤）仍最小。性能回归使用真实小文件、网络连接和 Runner（执行器）子进程负载，比较高分位和资源开销。适合无设备、无宿主特权依赖的开发、构建代理和常规服务；若关键功能必须通过扩大权限补回，就重新评估。最终决策记录威胁模型、已知限制、回退摘要和运维手册，不以“能启动”作为通过。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： rootless（无特权）能否监听低端口？
• 直接回答 1： 依现场内核与配置而定，可用高端口加受控转发，不能假设默认行为。
• 追问 2： 它能否替代 seccomp（系统调用过滤）？
• 直接回答 2： 不能，用户权限降低与系统调用面控制是不同层。
• 追问 3： 为什么还要做性能回归？
• 直接回答 3： 用户态网络、存储和委派路径可能改变延迟与吞吐特征。
• 详情：非 root（超级用户）、最小权限与共享内核风险

20. 综合问题： 宿主内核故障导致多个容器同时退出，应如何恢复并界定容器责任？

• 口述答案： 这种事故首先证明容器共享内核的故障域，而不是多个应用同时独立崩溃。我会按宿主标识和时间窗聚合同节点所有容器事件，内核层收集崩溃、重启、存储和网卡证据，运行时层确认 daemon（守护进程）、containerd（容器运行时）、shim（运行时垫片）及任务在宿主重启前后的状态，制品层保存各工作负载 digest（摘要）和配置版本，进程层记录哪些实例被非优雅终止，业务层分别核对 WMS（仓储管理系统）库存、支付未知流水、物流游标、导出清单、Runner（执行器）检查点和 IoT（物联网）设备会话。止血是隔离故障宿主、禁止继续调入工作、在其他故障域按业务优先级恢复，而不是在原节点反复重启。支付和库存先查权威状态，避免重复扣款/扣减；物流与 Runner（执行器）从已确认游标或检查点续跑；IoT（物联网）分批恢复连接，防止重连风暴。修复包括内核/驱动根因、补丁、节点镜像和容量余量，同时把关键服务跨宿主/机架分散。回归通过计划内宿主故障注入验证外置状态、重建时间、连接恢复和业务不变量。责任边界要写清：容器安全策略可减少单进程越权，cgroup（控制组）可限制资源争用，但都不能隔离宿主内核崩溃；高可用必须由故障域和业务恢复协议承担。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 所有容器自动重启后能关闭事故吗？
• 直接回答 1： 不能，非优雅终止可能留下未知资金、库存、任务和连接状态。
• 追问 2： 如何证明是宿主级而非应用级？
• 直接回答 2： 同节点多工作负载同时间失败并有内核/宿主重启证据，应用摘要与错误模式不同。
• 追问 3： cgroup（控制组）能防内核崩溃吗？
• 直接回答 3： 它可限制部分资源失控，不能提供独立内核故障域。
• 详情：共享内核、镜像分层、资源配额与不可变基础设施的权衡

21. 综合问题： WMS（仓储管理系统）库存接口被批量盘点和导出拖慢，容器层如何治理？

• 口述答案： 我先把在线库存裁决与可延迟批任务拆成不同资源组和证据边界。在线接口需要稳定高分位和数据库连接预算，批量盘点/导出关注吞吐，可被暂停或降速；若它们在同一容器共享线程池、2 核 CPU quota（处理器配额）、2 GiB（吉字节）内存和可写层，批任务会快速耗尽周期配额、扩大 page cache（页缓存）与临时文件，在线请求即使单次很轻也被节流和回收拖慢。取证时以发布 digest（摘要）和业务请求标识固定时间窗，宿主/cgroup（控制组）采集节流、内存压力、输入输出延迟，进程层看线程池、垃圾回收、连接池和导出并发，存储层看 volume（数据卷）与 inode（索引节点），业务层看库存扣减拒绝、订单提交和批任务水位。止血优先暂停新导出、降低批并发和批次，保留在线实例预算；如果仍共享实例则设置独立执行池与有界队列，但长期应按工作负载拆成独立容器/cgroup（控制组），给批任务设处理器、内存、输入输出、临时卷和任务数上限。恢复时库存正确性由库存流水和订单状态确认，导出按检查点续跑。回归用真实峰值叠加大导出，要求在线高分位、节流比例、数据库压力和库存不变量均满足目标，同时证明批任务被降级而非把压力转给下游。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 只给批任务降低线程优先级够吗？
• 直接回答 1： 不够，还要限制内存、输入输出、临时盘、数据库连接和并发任务数。
• 追问 2： 在线与批任务能否共用 volume（数据卷）？
• 直接回答 2： 可用但要隔离目录、配额和输入输出影响，关键状态与可丢临时文件应分开。
• 追问 3： 如何证明没有超卖？
• 直接回答 3： 以库存流水、订单状态和约束结果为准，容器指标只能说明运行条件。
• 详情：WMS（仓储管理系统）、支付、跨境物流、异步导出、Runner（执行器）与 IoT（物联网）项目落地

22. 综合问题： 支付容器在扣款高峰被 OOMKilled（容器内存杀死），怎样避免重复扣款？

• 口述答案： 第一原则是 OOMKilled（容器内存杀死）只说明进程被内核终止，不说明每笔支付成功或失败。止血先从入口摘除故障实例，限制新请求和大内存非关键功能，保留同 digest（摘要）实例的内存、内核和退出证据；新实例可以承接新流量，但旧请求必须按支付幂等键进入未知结果处理。业务层查询本地支付流水、账务分录、渠道请求号和回调：本地事务已提交且渠道成功则返回既有结果；明确未发起或已失败才允许按状态机重试；本地/渠道不一致或响应丢失则主动查单、对账，必要时冲正，绝不能从入口日志推断并直接重扣。技术根因同时按 2 GiB（吉字节）完整预算分析：Java（编程语言）堆、直接内存、线程栈、元数据、page cache（页缓存）和内核内存，结合 memory pressure（内存压力）、回收、OOM（内存溢出）事件、堆转储与线程数据定位泄漏或并发峰值。临时提高上限只是止血，还要限制并发和报文大小、修复对象留存、建立高水位拒绝策略。回归在隔离环境注入请求发送后、渠道受理后、本地提交前后和回调前后的强杀/OOM（内存溢出），验证每个幂等键最多产生一次有效扣款、未知结果可收敛，并同时满足内存压力与恢复时长目标。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 新容器健康后为何不能重放所有超时请求？
• 直接回答 1： 超时可能发生在渠道已受理或本地已提交之后，盲重放会重复扣款。
• 追问 2： 读副本查不到支付流水能否判失败？
• 直接回答 2： 不能，副本可能延迟，应查权威写状态和渠道结果。
• 追问 3： 内存上限调到 4 GiB（吉字节）是否完成修复？
• 直接回答 3： 只有容量模型、压测与泄漏证据证明新预算合理才可能成为长期方案。
• 详情：WMS（仓储管理系统）、支付、跨境物流、异步导出、Runner（执行器）与 IoT（物联网）项目落地

23. 综合问题： 跨境物流消费者出现 DNS（域名系统）间歇失败，如何止血与补齐轨迹？

• 口述答案： 我会把名称解析失败、地址可达失败和远端业务失败分开。先固定容器、宿主、目标域名、解析结果、时间戳和消费游标；运行时层检查容器 DNS（域名系统）配置与网络对象，内核层对比容器到解析器、解析器到上游的包和错误计数，进程层查看缓存时长、连接复用、超时与重试，业务层统计哪些运单和轨迹水位受影响。两类信号可用解析错误/超时日志与请求量、失败率、解析延迟指标，再用抓包验证是否发出查询、返回截断或无响应。止血时保留已建立连接，降低新建连接和重试并发，采用有期限、可审计的备用解析路径或缓存结果；不能永久写死地址，因为远端可能切换。消费者暂停提交失败批次的确认游标，把消息或任务留在可重放状态，并按运单幂等键防重复。修复要处理容器转发器、上游容量、网络策略或过短缓存，设置指数退避和随机抖动，避免 100 个容器同时重试形成解析风暴。服务恢复后从最后确认游标续跑，对每个运单按事件标识去重，比较上游轨迹序列、本地落库和缺口清单，必要时主动补拉。回归注入解析器超时、空响应、地址切换和网络恢复，验证积压可控、无轨迹丢失、重复事件不改变最终状态。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 直接修改宿主 hosts（主机名映射文件）可以吗？
• 直接回答 1： 只能作为有期限止血且需确认地址稳定，长期会造成漂移和失效。
• 追问 2： DNS（域名系统）恢复为何还要补拉？
• 直接回答 2： 故障窗口可能有未消费轨迹，解析恢复只说明新请求可发。
• 追问 3： 如何避免重试风暴？
• 直接回答 3： 有界并发、指数退避、随机抖动、连接复用和全局降级开关共同控制。
• 详情：network namespace（网络命名空间）、网桥、转换与故障边界

24. 综合问题： 异步导出产生海量小文件导致 inode（索引节点）耗尽，如何治理？

• 口述答案： inode（索引节点）耗尽说明文件数量预算失控，即使字节水位很低也无法创建新文件。先按容器、任务、目录和时间窗统计小文件数量、创建速率、平均大小、清理速率与打开句柄；运行时层确认 writable layer（可写层）和 volume（数据卷）实际落在哪个文件系统，内核层看字节/inode（索引节点）双水位、配额和创建错误，进程层定位哪个导出阶段按行或小批生成文件，业务层核对分片清单、已发布结果和可再生临时文件。两类信号是 inode（索引节点）使用/创建速率指标与 no space 类错误、任务日志。止血先拒绝新大导出、暂停产生小文件的阶段，保留已提交清单引用的分片，只删除无引用且可重算的临时对象；不能按修改时间盲删，因为慢任务仍可能使用。修复把 20 万个 4 KiB（千字节）分片合并为更大分块，或流式写入对象存储/归档格式；每个任务设置文件数、字节、并发和期限配额，状态清单与数据分离，清理采用“先标记无引用、宽限期后删除”的可审计流程。回归以峰值任务数制造超过日常规模的小文件，验证高水位前拒绝、清理吞吐高于生成、任务取消无孤儿分片，并从备份/清单恢复完整导出，最终核对行数、分片摘要与业务水位。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 删除最大文件能解决 inode（索引节点）耗尽吗？
• 直接回答 1： 通常不能，释放一个大文件只释放一个 inode（索引节点）。
• 追问 2： 调大 inode（索引节点）数量是否足够？
• 直接回答 2： 只能扩大容量，仍要治理无界文件数和清理速度。
• 追问 3： 为什么状态清单要独立？
• 直接回答 3： 它定义哪些分片有效，使清理、恢复和幂等续跑有权威依据。
• 详情：writable layer（可写层）、挂载、备份与容量水位

25. 综合问题： Runner（执行器）达到 PIDs（进程数）上限，怎样区分并发过高与僵尸泄漏？

• 口述答案： 两者都会表现为无法创建线程或子进程，但证据不同。先记录 cgroup（控制组）当前任务数、上限、达到上限事件和增长曲线，再把容器内外进程树映射到任务标识。若活跃子进程数量与并发任务、每任务并行度近似相符，任务完成后能下降，只在高峰触顶，主要是并发预算错误；若大量状态为 zombie process（僵尸进程）、父进程长期不 wait（等待），任务完成后数量仍单调增长，则是回收泄漏；还要排除 Java（编程语言）线程池无界扩张，因为线程同样计入任务数。制品层检查入口和 init（初始化）配置，运行时层看 PID 1（第一号进程）与退出，内核层看 PIDs（进程数）事件，进程层看父子关系，业务层核对任务是否已完成却未登记。止血暂停领取新任务、降低单任务并行，保留受影响实例进程树；必要时迁移任务后受控替换，不能简单调大上限让泄漏继续。修复并发过高则建立“容器上限减去主进程/诊断余量，再除以每任务线程/子进程数”的预算；僵尸泄漏则修正 wait（等待）、异常路径和信号处理。回归批量创建正常、失败、超时和取消子任务，验证任务数随负载回落、僵尸归零、诊断仍有余量，且任务结果不重复。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 为什么线程也消耗 PIDs（进程数）预算？
• 直接回答 1： Linux（操作系统）把线程作为可调度任务记账，控制器通常按任务计数。
• 追问 2： 达上限后先调大可行吗？
• 直接回答 2： 只可作为有边界止血，并需确认不是泄漏且宿主有容量。
• 追问 3： 如何给诊断留余量？
• 直接回答 3： 预算中预留运维线程/子进程空间，并在接近高水位时停止领任务。
• 详情：cgroup（控制组）的配额、节流、回收与 OOM（内存溢出）

26. 综合问题： IoT（物联网）采集器连接跟踪表接近耗尽，如何避免报警与重连风暴？

• 口述答案： 我先区分应用连接数、宿主连接跟踪条目和短连接创建速率。假设 100 个容器每个维持 800 条长连接，共约 8 万条；若设备断网重连、上游短请求和关闭后的状态同时占用表项，约 10 万量级的现场容量可能迅速接近高水位，但具体上限与超时必须核对。网络层采集当前/最大条目、插入失败、丢包、各状态分布与网卡队列，进程层看活跃会话、连接创建/关闭速率、重试和文件描述符，应用层看设备在线率、上报延迟和报警数量。两类信号使用连接跟踪/丢包指标与内核日志、抓包或应用连接错误。止血先限制新连接速率、按设备/区域分批重连、延长已有健康连接复用，报警按根因聚合和抑制重复通知；不能让每个容器无抖动地立即重试。修复包括消除连接泄漏、使用连接池/长连接、设置有界指数退避和随机抖动，根据真实状态分布调整超时与容量，并把关键入口分散到多个宿主故障域。单纯调大表会增加内存且掩盖泄漏。回归模拟网络分区后 8 万设备分批恢复，验证新建速率、表高水位、丢包和报警通知受控，设备序号/上报无缺口，且宿主重启时不会形成全量同步重连。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构，并完成复盘与容量复核。
• 追问 1： 应用连接关闭后表项为何还在？
• 直接回答 1： 协议状态可能需保留一段时间以处理迟到包，具体超时现场核对。
• 追问 2： 调大连接跟踪表有什么代价？
• 直接回答 2： 增加内核内存和查找压力，并可能延迟暴露连接泄漏。
• 追问 3： 报警聚合会不会漏故障？
• 直接回答 3： 聚合同根因通知但保留受影响设备数、区域、持续时间和恢复状态。
• 详情：network namespace（网络命名空间）、网桥、转换与故障边界

27. 综合问题： 如何实现“同一不可变镜像跨环境晋级”，又允许环境差异？

• 口述答案： 我把发布身份拆成制品身份与环境声明。制品身份由镜像 digest（摘要）、签名、SBOM（软件物料清单）和 provenance（来源证明）固定，测试、预发、生产不重新构建；环境声明包含配置版本、密钥引用、资源限额、网络与卷绑定，这些在运行时受控注入并独立审计。构建阶段不得把生产地址或秘密烘进 layer（层），Dockerfile（镜像构建文件）只定义可移植运行要求。每次晋级记录“同一摘要 + 目标环境配置版本 + 门禁证据”，先验证镜像签名和来源，再检查配置模式、必需密钥、volume（数据卷）权限、处理器/内存预算和依赖连通，最后用代表性业务探测确认。若测试通过而生产失败，优先比较环境声明和基础设施，不通过重新构建“生产版镜像”绕过，因为那会生成新摘要并丢失测试继承。回滚也使用历史摘要与兼容配置组合，若数据库结构或外部副作用已前进，要先判断向后兼容、开关和补偿，镜像回退本身不能撤销状态。供应链漏洞出现时，从相同提交和更新后的固定输入生成新摘要，重新走门禁，而不是覆盖旧标签。最终发布记录能回答谁构建、用了什么输入、在哪些环境验证、生产实际运行哪个摘要以及业务结果如何。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 配置变化后还是同一发布吗？
• 直接回答 1： 镜像制品相同，但完整发布身份应包含配置和密钥引用版本。
• 追问 2： 为什么不能在生产重新构建？
• 直接回答 2： 新构建可能因依赖、基础层和时间变化形成未测试字节。
• 追问 3： 数据库迁移如何影响回滚？
• 直接回答 3： 旧镜像必须兼容已迁移结构，否则需前后兼容方案或修复前进。
• 详情：Dockerfile（镜像构建文件）、缓存键与供应链门禁

28. 综合问题： healthcheck（健康检查）通过、容器也在重启，为什么仍不能判定业务恢复？

• 口述答案： healthcheck（健康检查）、restart policy（重启策略）和业务恢复分别回答不同问题。健康检查可能只验证进程本地端口或简单线程活性，无法证明数据库写入、消息消费、外部支付、库存约束和任务检查点正确；重启策略只在主进程退出后按条件创建新进程，根因若是坏配置、卷权限、内存泄漏或依赖故障，新进程会继续失败甚至放大请求。排查时记录重启次数、退出原因、健康检查定义/耗时/超时、端口与业务请求结果；运行时事件与健康日志是一类，业务成功率、积压和权威状态是另一类。若检查过于浅，会出现“绿色但不可用”；若检查依赖过多且频繁，又会在下游抖动时制造自我故障。止血应暂停循环重启、保留失败证据、把流量切到已验证实例并对非关键功能降级。修复把健康分层：进程活性只判断是否卡死，承担流量条件判断必要本地依赖与过载状态，深度业务校验由外部低频探测承担；具体编排探针留给后续分册。恢复必须核对 WMS（仓储管理系统）库存请求、支付未知结果、队列积压或 Runner（执行器）任务水位。回归注入依赖慢、卷只读、日志阻塞、OOM（内存溢出）和终止信号，验证检查不会掩盖错误或引发重启风暴。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 健康检查能查询所有下游吗？
• 直接回答 1： 不宜高频深查所有下游，否则会放大依赖故障并制造级联。
• 追问 2： 重启次数归零是否代表稳定？
• 直接回答 2： 可能只是进程未退出，仍需看可用性、积压和业务结果。
• 追问 3： 哪类检查适合进程活性？
• 直接回答 3： 低成本、本地、能发现不可恢复卡死且不依赖大范围外部系统的检查。
• 详情：PID 1（第一号进程）、信号、健康、日志与重启边界

29. 综合问题： 发现秘密曾进入镜像层，后续 Dockerfile（镜像构建文件）已删除，为什么仍要处置？

• 口述答案： 因为镜像 layer（层）是有序的只读差异，后续删除只会在新层记录“该路径不可见”，不会从历史层抹掉旧字节。任何能获得镜像对象并检查旧层的人都可能恢复秘密；构建缓存、仓库副本、开发机内容库和已拉取宿主还可能长期保存该 digest（摘要）。处置第一步不是只重建，而是立即吊销/轮换该秘密，把它视为已泄露；再以受影响摘要为键，列出仓库标签、派生镜像、环境和宿主缓存，暂停继续晋级。修复 Dockerfile（镜像构建文件）与 build context（构建上下文），让秘密通过构建期受控挂载或运行时只读密钥通道使用，确保不会写入文件层、构建参数、历史或日志；清理历史需遵循仓库与运行时支持流程，避免破坏仍被引用对象，但清理不能替代轮换。重新构建会产生新 digest（摘要），生成新 SBOM（软件物料清单）、扫描、签名和 provenance（来源证明），验证各层与构建日志不含秘密，再跨环境晋级。证据一类是层内容/仓库引用清单，另一类是密钥使用审计与异常访问。回归在测试秘密下检查镜像历史、解包层、缓存导出和日志，确认只在授权运行期可见。事故关闭要求旧秘密失效、新摘要上线、受影响范围清点和访问审计完成。 上线前还要把现场版本、责任人、变更时间、回退点与观察窗口写入决策记录；所有阈值区分演练样例和真实监控，恢复后持续观察完整业务周期。若技术信号与业务事实矛盾，以权威业务状态为准并保持事故开放，避免临时参数悄悄成为长期架构。
• 追问 1： 压缩或合并层能解决已泄露秘密吗？
• 直接回答 1： 不能撤销已分发副本和访问，必须先轮换秘密并清点范围。
• 追问 2： 构建参数适合传秘密吗？
• 直接回答 2： 可能进入历史或元数据，应使用受控秘密挂载并验证不落层。
• 追问 3： 删除旧标签够吗？
• 直接回答 3： 不够，摘要对象、缓存和派生镜像可能仍存在，且旧秘密已需失效。
• 详情：Dockerfile（镜像构建文件）、缓存键与供应链门禁

30. 综合问题： 请用一次综合事故串联镜像、节流、OOM（内存溢出）、网络、卷和优雅停止的证据闭环。

• 口述答案： 假设一次异步导出新版本上线后，500 MiB（兆字节）镜像在部分节点冷拉取变慢，运行后高峰又出现尾延迟、OOMKilled（容器内存杀死）、大文件上传超时和停止超时。我先用发布 digest（摘要）把所有现象关联：制品层检查 manifest（清单）、缺失 layer（层）、解包后空间、SBOM（软件物料清单）与签名，确认拉取慢是缺层和磁盘高水位而非应用；运行时层对齐创建阶段、退出原因和 30 秒停止事件；cgroup（控制组）层发现 8 核宿主上的实例只有 2 核配额，4 线程需求导致约 37.5% 节流，同时 2 GiB（吉字节）内存被堆、直接内存、线程栈和 page cache（页缓存）合计突破，经历回收后被杀；网络层用小包/大包与双侧抓包证明 1500 B（字节）到 1450 B（字节）隧道 MTU（最大传输单元）不匹配；存储层发现 10 GiB（吉字节）临时文件和海量小分片写进 writable layer（可写层），字节与 inode（索引节点）共同逼近水位；进程层发现启动脚本未 exec（执行），信号未到 Runner（执行器），检查点来不及提交。止血是回滚到已签名历史摘要、暂停新导出、保留在线接口、降低并发和报文块、隔离满盘节点。修复分别重排镜像层/容量、重算资源、统一 MTU（最大传输单元）、改用有配额卷和正确 PID 1（第一号进程）。回归同时注入冷拉取、峰值、强杀和宿主故障，最终以分片清单、任务检查点和导出摘要确认恢复。
• 追问 1： 为什么不能只回滚镜像就关闭事故？
• 直接回答 1： 已产生的临时文件、未知任务、网络配置和节点水位不会随镜像自动恢复。
• 追问 2： 哪两类信号最先使用？
• 直接回答 2： 运行时/内核事件日志与资源/网络/存储连续指标，再按假设补抓包和业务审计。
• 追问 3： 最终恢复证据是什么？
• 直接回答 3： 技术路径稳定且任务清单、检查点、行数与输出摘要满足业务不变量。
• 详情：十类故障的五层证据、双信号、止血、修复与回归