容器 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 与节点对象一一对应，合成数据重建后可验证；边界案例让容器只能在 127.0.0.1 监听或改掉卷挂载，前者的服务入口不可达，后者“相同 URL 返回的数据”可能来自另一可写层。对照若缺任何中间对象，都须在证据链上标一个断点，不填预测 PID 或 digest。验证清单列出专用环境、清理与补跑；本机没有 registry、运行时/kind、卷与真实容器网络，完整端到端验收 NOT_RUN。本机 00/10 的独立小实验不能合并成一次全链路记录。
| 现象 | 沿链追溯 | 能否成立 |
|---|---|---|
| HTTP 200 | 响应体与请求 ID、Pod UID | 不保证写盘持久化 |
| UID 与容器 ID 对不上 | Pod 重建/滚动更新 | 切勿拼接两代日志 |
| 卷上仍有数据 | mount 源、文件校验 | 需证明同一卷 |
练习
- 先预测同名 Pod 重建后哪些 ID 必换、哪些 digest 可以保持；逐项读取，标记能复用与会重建的对象。
- 先预测把 state-dir 改到容器可写层后请求仍返回 200，但 Pod 重建后的数据会怎样；记录文件、挂载源与请求输出核实。
上一篇：36：交付与回退；下一篇：38：故障与业务结果。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
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
容器 32：从错误症状回到失败层
启动失败的提示往往出现在最高一层：CLI、Pod condition 或 HTTP 超时。修复需要逆向定位首个出错环节。沿10 的 digest、17 的 bundle、24 的网络对象与28 的就绪状态逐层判断，先记录假设，再以明确证据排除。 四种会混成一个“起不来”的情况 第一，镜像无法解析或 layer blob 缺失：还没有完整根文件，查看拉取响应与 digest。第二，平台不匹配：索引没该平台或启动可执行文件时产生架构错误，核对节点架构与目标文件格式。第三，运行时配置或挂载权限被拒：先找 OCI bundle/config、宿主权限与 errno，不能怪应用网络。第四，进程已经运行但监听 127.0.0.1、readiness 返回 503 或 Service 后端未更新：先比较 PID、目标地址、探针与真实请求。每类都要设计一条可被反例推翻的排除证据，不能只列故障关键词。 在专用实验 VM 以相同 probe-app 分别制造四类受控故障：错误镜像摘要/缺 blob、错误架构、只读写入目录、错误监听地址或 readiness 延迟；同一时刻只改一个变量，并为每次保留镜...
2026-06-20
CRD 与 Operator 模式——扩展 Kubernetes 的标准路径
Kubernetes 的核心设计哲学之一是可扩展性。API Server 内置的资源类型——Pod、Deployment、Service——只能覆盖通用计算模型，但现实中的应用远不止于此：数据库集群有自己的主从切换逻辑，消息队列有 topic 副本的分配策略，机器学习训练任务有 GPU 亲和性和检查点管理。CustomResourceDefinition（CRD）和 Operator 模式正是 Kubernetes 给出的扩展机制：让用户把领域知识编码进集群本身，而不是写在外部脚本或运维手册里。 CRD 的核心能力是向 API Server 注册新的 Group/Version/Kind（GVK）。注册完成后，kubectl get myapp 和 kubectl get pod 在 API 层面对等——同样走 REST 接口，同样存储到 etcd，同样支持 watch、label selector 和 RBAC 授权。Operator 在 CRD 之上再加一层：部署一个 Controller，持续监听自定义资源的变化，把用户声明的期望状态翻译成若干内置 Kubernetes 资...
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-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-10-01
容器 12：镜像拉取是下载还是解包
本地已知镜像的index、manifest 与 blob，接下来问另一台机器如何得到相同字节。Distribution Specification 约定 registry API；它不等于 Linux 的 mount、容器进程的 exec，也不保证客户端已把层成功解压成可运行的 rootfs。 引用解析和内容获取分开 客户端把名字/tag 交给 registry，商议清单媒体类型，读取 manifest 后根据 descriptor 的 digest 与 size 请求 config 和 layer blob。digest 绑定字节，tag 可重新指向另一 manifest；“我拉到了 tag”不能证明和上一次拉到的内容相同。Blob 下载成功仍需校验摘要、解压层、建立本机快照才能供运行时使用。认证失败应定位到 HTTP 挑战、凭据与仓库权限，缺失 blob 则应定位对应 digest 和 HTTP 返回，而非笼统说“网络不通”。不要将镜像 registry 的身份验证和镜像签名混为一谈。 引用如何落到确定的 manifest OCI Distribution Specifica...