容器 30：PV/PVC 与 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、换节点，区分每一步数据是否留在原卷。反例将自有卷作为只读或不匹配所有者挂入，在同一服务端点发写入请求，保存准确错误与事件；不得修改共享 PVC 或改权限绕过安全机制。实验步骤和探针包可独立获取。
本机无 kind/CSI/外部共享存储能力；即使旧文提到 CSI，也不能据此写入本篇的宿主 mountinfo 或持久化结果，完整实验 NOT_RUN。任何换节点案例先核查驱动是否支持所需访问模式，禁止把单节点路径模拟成跨节点存储。
| 现象 | 证据 | 不能推出 |
|---|---|---|
| PVC Bound | PV/驱动/节点 mount | 应用有写权限 |
| 重建 Pod 数据仍在 | 相同卷 ID、文件内容 | 换节点也必然可用 |
| 写入成功 | 真实持久化/备份检查 | fsync/备份一定完成 |
练习
- 先预测删除容器、重建同一 Pod 对卷内容和容器可写层各有什么影响；在专用 CSI 环境分别核对挂载 ID 与数据。
- 预测把原来可写的挂载改为只读后
/state的 HTTP 行为，保存应用异常与节点事件，再还原自有卷配置。
上一篇：29：Service；下一篇开始按同一 Pod UID 关联应用延迟、cgroup 与请求日志。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
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-06-20
控制器模式与 Informer 机制：调谐循环的工程实现
Kubernetes 的控制平面由一批控制器组成，每个控制器负责把某种资源的实际状态收敛到期望状态。Deployment 控制器确保 ReplicaSet 数量正确，ReplicaSet 控制器确保 Pod 数量正确，StatefulSet 控制器维护有序 Pod 的标识和存储绑定。这些控制器全部运行在 kube-controller-manager 进程中，共享同一个 Go runtime，但逻辑上彼此独立。 控制器的核心模式是调谐循环（Reconcile Loop）：读取资源当前状态，与期望状态对比，对差异执行操作，然后等待下一次触发。这个循环不是基于轮询的——每隔几秒查一次 etcd 的方式在规模上不可持续。实际实现依赖 Informer 机制：Informer 在本地维护一份与 etcd 同步的缓存，用 Watch 接收增量变更，把变更转换成事件分发给控制器。控制器从工作队列取出事件，执行 Reconcile，写回 API Server。 这篇的核心问题是：从 etcd 的一次写入，到控制器的一次 Reconcile 调用，中间经历了哪些层次，每层解决什么问题？ Info...
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
网络模型与 CNI：每个 Pod 一个 IP 背后的实现
Kubernetes 对网络做出了一个看似简单的承诺：每个 Pod 拥有一个集群范围内唯一的可路由 IP，Pod 之间无需 NAT 可直接通信，节点访问 Pod 也无需 NAT。三条规则，没有一条涉及实现细节。这种"定义行为、不定义机制"的风格与 Kubernetes 整体的设计哲学一致，但也意味着没有任何一行核心代码实现了这个承诺——它完全由 CNI 插件负责兑现。 理解 CNI 的切入点不是插件本身，而是 Linux 网络命名空间带来的问题。每个容器拥有独立的网络栈，包含独立的路由表、ARP 缓存、iptables 规则集。新建的命名空间里只有一个回环接口 lo，对外完全不可达——这正是容器隔离的本意。CNI 插件的全部工作就是在这种隔离性上凿出一条通道：创建 veth pair，把一端移入 Pod 命名空间，另一端挂到宿主机网桥，配置 IP 地址和路由，让 Pod 从完全隔离的孤岛变成集群网络里的一个节点。 跨节点通信是第二层复杂性。同节点内的 Pod 通过共享网桥即可互通，但当数据包需要离开宿主机的物理网卡，穿越真实的交换机和路由器，抵达另一台节点，再...
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-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 本身配置正确。容量规划需要理解"...