容器 38：重启了，业务真的恢复了吗
先界定故障注入范围
仅在专用 kind 集群和自建 namespace 中注入四类故障：单容器内存上限的有界申请、明确终止自建容器进程、只阻断实验 Pod 之间的网络、停掉专门提供的测试节点。每次保留注入前的基线：镜像 digest、Pod UID、容器 ID、PID、网络路径、state 文本哈希与固定负载；注入后记录每次请求开始/结束、HTTP 状态/超时、相应事件及新的对象 ID。先定义恢复为“连续指定次数业务请求成功，且状态校验一致”，再测从第一条失败请求到恢复的时间。节点测试需有宿主控制台/VM 恢复路径，不能停止共享宿主上的 kubelet、daemon 或默认网络。
正常恢复例是一个受控容器被终止后由节点重新启动，新 PID 取得原有卷并在约定窗口内重新响应；边界例是 readiness 重新变绿，但自有测试卷上的状态未满足应用数据条件，因而不能称为完整恢复。内存事件还要结合27 的 cgroup/事件区分节点驱逐；网络阻断要分清插件策略拒绝与未就绪服务。四项实验和清理门槛、探针源码提供无界压力之外的材料。
云端没有独立测试节点、kind/CSI/CRI，四类故障、恢复时间和失败率一律 NOT_RUN；没有“看起来合理”的模拟数字。
| 现象 | 必留证据 | 排除误判 |
|---|---|---|
| Ready 重新为 true | 实际请求与数据状态 | Ready 不等于业务恢复 |
| Pod 被重新创建 | UID/容器 ID/PID 前后 | 不是原进程续跑 |
| 请求超时 | 两端网络/状态与时间窗 | 不等于一定被内存杀死 |
练习
- 先预测内存限制导致进程终止与节点整体压力驱逐的事件差异，专用 VM 分别观测、清理并核对卷状态。
- 先预测节点停机后旧 Pod UID、卷位置与业务状态会怎样，记录每条请求和存储能力边界，不把“另节点有 Pod”视作成功。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-20
Service 与 kube-proxy：虚拟 IP、iptables 与 IPVS
Service 的 ClusterIP 是一个不存在于任何网卡的虚拟 IP。在节点上运行 ip addr，看不到它；用 ping 测试，收不到回应；但对它发起 TCP 连接，数据却能稳定到达某个后端 Pod。这个"幽灵 IP"能够工作，完全依赖 kube-proxy 写入每个节点内核的 iptables 或 IPVS 规则——规则在，转发在；规则消失，连接消失。 理解这一机制的起点是区分两种截然不同的角色：kube-proxy 是"规则维护者"，内核的 netfilter/IPVS 子系统才是"数据面执行者"。kube-proxy 进程本身从不处理任何用户请求，它只监听 kube-apiserver 上 Service 和 EndpointSlice 的变化，把这些变化翻译成内核规则，然后等待下一次变化。真正处理数据包的是内核——每个到达某 ClusterIP:port 的数据包，在经过 iptables nat 表的 PREROUTING 链时，被 DNAT 规则改写目标地址，转向某个真实的 Pod IP:port，整...
2026-10-01
容器 30：PV/PVC 与 CSI 怎样到达进程的目录
16已经表明容器内同一路径可能属于可写层、bind、volume 或 tmpfs；Kubernetes 加上声明、绑定与节点挂载流程，才使 Pod 能看到一份外部存储。PV/PVC、StorageClass、CSI 的对象关系见存储体系；这里专看“这次写入究竟落到了哪一个挂载对象”。 声明成功不等于目录可写 PVC 指明容量/访问模式等需求，通过绑定/动态供给关联 PV；具体 CSI 驱动与节点组件按存储类型准备卷，把它挂载进 Pod；进程最终看到的是自己的 mount namespace 中某个路径。不同驱动对动态供给、重挂载、跨节点恢复、备份一致性的承诺不同。即使 Pod Running，卷的所有者、只读设置或应用 UID 不匹配仍可导致写入失败；不能仅凭 PVC Bound 说业务数据已可恢复。 正例在专用 kind VM 且有明确 CSI 驱动能力时，用同一 probe-app 的 /state 写一段合成文本，记录 PVC UID、PV 名称、Pod UID、容器 ID、mountinfo、应用响应；分别重建容器、重建 Pod、换节点，区分每一步数据是否留在原卷。反例将...
2026-06-20
存储体系：PV、PVC、StorageClass 与 CSI
前几篇建立了计算（Pod 调度和运行）和网络（Pod 间通信和服务发现）的模型。有状态应用（数据库、消息队列、对象存储）需要持久化存储，Pod 重启后数据不丢失。Kubernetes 通过 PV/PVC/StorageClass 三层抽象解耦了存储的供应和使用。 在虚拟机时代，存储通常由运维工程师手动挂载：NFS 目录、SAN LUN、本地磁盘，挂载路径硬编码在部署脚本里。容器化之后，Pod 随时可能漂移到不同节点，存储和计算的生命周期必须显式解耦。Kubernetes 的回答是引入三个层次：PV（实际存储的抽象）、PVC（应用的存储需求声明）、StorageClass（动态供应的策略工厂）。PV/PVC 的绑定机制和 CSI 驱动如何让外部存储系统成为 K8s 的一等公民，是本篇的核心内容。 CSI（Container Storage Interface）的出现解决了 in-tree 驱动的历史包袱。此前，每个云厂商、每个存储系统都要向 Kubernetes 主代码库提交驱动代码，升级路径混乱且周期漫长。CSI 定义了一套 gRPC 接口，任何存储厂商都可以编写独立的驱动程序，...
2026-10-01
容器 36：同一 digest 怎样交付并安全回退
33 的制品身份和28 的就绪状态属于交付的两个不同条件。单机 Compose 和 Kubernetes 可以消费同一镜像 digest，但不会因此拥有相同的网络、卷、策略或回退语义。应以实际 digest 为连接点，再记录各自的声明配置与请求结果。 固定制品，不固定假设 附件中的 `compose.yaml` 要求 `PROBE_IMAGE` 是实际 `repo@sha256:...`，把仅属于实验的 volume 挂到探针 state-dir，限制发布端口为本机 loopback；Kubernetes 则需在专用集群部署同 digest 的 Deployment/Service，并明确 storage/NetworkPolicy 和探针版本。运行两侧 `/identity` 与 `/state`，可追踪到真正服务该请求的 Pod UID/容器 ID/PID，而不只是 YAML 的 image 字段。 正例先部署已验证版本，记录 digest、配置和合成状态文本，再将应用或配置换成已知坏版本，在专用环境观测失败并按明确回退动作恢复旧 digest 与请求；负例是回退了容器镜像但...
2026-06-20
生产集群运维——升级、备份、故障排查与容量规划
把 Kubernetes 集群跑起来是第一步，让它在生产环境中长期稳定运行才是真正的挑战。版本升级、etcd 备份恢复、节点维护、故障排查、容量规划——这些 Day-2 运维场景，每一个都有足以让集群中断服务的操作风险。Kubernetes 为这些场景提供了明确的工具和流程约定，但操作顺序和细节上的失误仍然是生产事故的主要来源。 版本升级是最高风险的操作之一。Kubernetes 的 API 在版本间存在兼容性约束（skew policy），错误的升级顺序——例如先升级 kubelet 而非先升级 control plane——会导致集群进入不一致状态，轻则调度异常，重则 API Server 无法与节点通信。etcd 备份看似简单，但备份时机（必须在升级前）、恢复流程（必须停止 API Server 再恢复）、验证方式（恢复后检查关键对象）如果有任何一步出错，都可能导致数据丢失或集群无法启动。 节点维护（drain + upgrade + uncordon）有 PodDisruptionBudget（PDB）这道安全网，但前提是 PDB 本身配置正确。容量规划需要理解"...
2026-06-20
调度器深入：打分、抢占与拓扑约束
调度器（kube-scheduler）是 Kubernetes 控制平面里最容易被低估的组件。它做的事情看起来简单：把没有 nodeName 的 Pod 绑定到某个节点。但"选哪个节点"这个问题背后，隐藏着资源感知、亲和性约束、拓扑分散、优先级抢占等多维度的决策过程。 从 Kubernetes 1.19 起，调度器的内部逻辑通过 Scheduling Framework 对外暴露为一组扩展点。原来散落在代码各处的调度逻辑被重新组织成插件，每个插件只负责一个扩展点。这让调度行为既可预测，又可扩展。 本文的核心问题是：Kubernetes 调度器用什么框架选节点，当资源不足时如何通过抢占让高优先级 Pod 运行？ 调度框架全景图 1234567891011121314151617181920212223242526Pod pending (no nodeName) │ ▼ Scheduler（from ActiveQ by priority） ┌──────────────────────────────────────────────────...