容器 36：同一 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 与请求；负例是回退了容器镜像但数据 schema 已被前一版不可逆地改变，服务仍可能失败。因此回退验收必须同时看配置、卷数据兼容性和真实请求，而不是只看“rollout undo 成功”。复跑入口和数据边界要求只清理自己创建的 Compose project/namespace 与卷；本机无 Docker/kind/实际 digest，交付与回退均 NOT_RUN，Compose 静态结构不是服务上线证明。
| 现象 | 核查 | 不能推出 |
|---|---|---|
| YAML 的 image 是旧 digest | 实际容器镜像 digest | 数据已回滚 |
| rollout 成功 | Pod Ready 和真实请求 | 业务成功 |
| 两端 digest 一样 | 配置、卷和网络路径 | 行为必然相同 |
练习
- 先预测容器镜像回退、但测试卷内容被坏版本修改后
/state结果，专用环境留合成数据对照及备份恢复步骤。 - 预测 Compose 与 Kubernetes 同 digest 的 Pod/容器是否拥有同一端口入口，实际读取监听、路由、endpoint 与 HTTP 返回。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-10-01
容器 28：Running 之后服务为什么还不能用
普通进程00 的 /health=200、/ready=503已经证明“活着”和“就绪”不同。在 Kubernetes 节点上还要区分 Pod phase、容器 status、探针结果、Service 端点和用户请求。CrashLoopBackOff 常表示重启等待状态，而不是一种 Pod phase；Running 不等于所有容器已 Ready，更不保证业务已成功执行。 把检查点放回节点路径 init 容器先于应用启动完成；sidecar 语义要按当前 Kubernetes API/版本核查，不把任何普通辅助容器都当作同样的启动顺序。startup probe 给慢启动争取窗口，readiness probe 控制何时把后端纳入就绪集合，liveness probe 可触发重启；这些探针并不能证明数据正确性。优雅终止时观察终止通知、endpoint 移除、收到的信号与应用结束请求的时间顺序；即使 readiness 很快转 false，已在途请求也需要单独验证。 正例在专用 kind 集群用 probe_app.py --ready-de...
2026-10-01
容器 37：从源码到一次真实服务响应
本系列的每个对象都有不同寿命：源码树变化不等于已部署镜像改变；Pod 重建不等于数据卷重建；HTTP 请求成功也不能证明读写结果符合预期。综合实验必须让一条请求沿同一个 digest、容器 ID、Pod UID、宿主 PID、namespace/cgroup、网络路径和卷挂载回溯到源码，而不是把不同实验的截图接成故事。 只用一份 probe-app 从干净的实验目录取独立源码包并校验 SHA，固定基础镜像 digest，按13构建真实镜像，按12分发到受控 registry，再按26将 digest 部署到自建 kind 节点。通过 Service 访问 /identity 取得进程信息，通过 /state 写入一段最多 4096 字节的合成文本；从 Pod UID 到容器 ID、宿主 PID，查 namespace inode、cgroup、网络地址/路由及卷的 mountinfo，最后在同一卷上重建 Pod 后复读内容。每一步记录输入、时间、原始响应与校验值，不能从“yaml 配好了”跳到“持久化成功”。 正常案例需要请求 JSON 中的 PID 和 UID 与节点对象一一对...
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
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
Pod 生命周期：从 Pending 到 Running 的完整路径
一个 kubectl apply -f pod.yaml 之后，终端里出现了 pod/my-app created。这行输出只意味着 API Server 接受了资源定义并写入 etcd——Pod 还没有运行在任何节点上，甚至还没有被任何节点知晓。从这个瞬间到容器真正响应流量，Pod 经历了一条由多个组件接力完成的状态转换链。 这条链不是黑盒。Kubernetes 把每个阶段都编码进 status.phase、status.conditions、status.containerStatuses 三个字段里，并通过 Events 记录关键节点的时间戳。理解这条链，就能在 Pod 卡住时精确定位是调度失败、镜像拉取失败、探针失败，还是 OOM Kill。 本文的核心问题是：一个 Pod 从 kubectl apply 到 Running 经历了哪些状态转换，每个状态背后是哪个组件在操作？ 状态转换全景图 12345678910111213141516171819202122232425kubectl apply │ ▼ etcd (Pod phase=Pending...
2026-10-01
容器 26：Pod 到达节点后变成哪些对象
Pod 对象已分配给节点之后，如何找到真正处理请求的宿主进程？把17 的 OCI runtime、18 的任务和24 的插件网络连接起来，比重新罗列 Kubernetes 对象名更有用。已有Kubernetes 核心概念是词汇入口，这一篇只追踪节点上从声明到执行的对象关系。 一条可核查的身份链 kubelet 观察已分配到本节点的 Pod，通过 CRI 与节点上的容器运行时交互；CRI 对 sandbox 和容器的生命周期建模，不是 OCI 的 create/start 原样 RPC，也不是 CNI 的网络设备实现。具体 runtime 为 Pod sandbox 准备网络等环境，创建应用容器，向更低层传入符合本机实现的执行配置。每一步要记录 Pod UID、sandbox ID、容器 ID、宿主 PID，再读该 PID 的 namespace inode 和 cgroup 路径；containerd 的 namespace 与 Kubernetes Namespace 不能替代这条身份链。Pod 名称可被重建而复用，不能只靠显示名称关联旧进程。 正常案例应在专用 kind VM...