容器 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 中把 probe-app 的 image digest 写入 Pod 定义，检查 UID、CRI sandbox/容器 ID、宿主 PID、镜像 digest 与 /identity；负例将入口改成不存在路径，对照 sandbox 能否先建立而业务容器反复失败，结合事件区分镜像阶段、sandbox 阶段与应用阶段。所选 kubelet、containerd、CNI 插件的版本与实现源码需按节点实际版本锁定；滚动文档不构成本机源码审计。节点取证命令和探针源码可独立取得。本云端没有 kind/kubelet/containerd/CNI，整条对象关联 NOT_RUN。
| 现象 | 首先查 | 前提 |
|---|---|---|
| Pod 名未变、进程已换 | Pod UID、容器 ID、宿主 PID | 名称不是进程 ID |
| sandbox 存在、应用失败 | CRI 状态、镜像及应用日志 | sandbox 成功不等于服务成功 |
| 看到一只 shim | 运行时版本与任务分组 | 不推断所有 Pod 一对一 |
练习
- 预测删除重建同名 Pod 时 UID、sandbox ID 与进程 PID 怎样变化，在专用集群采集全链，解释哪些值不能从名字推导。
- 预测网络插件 ADD 失败与应用
exec失败分别在哪一层产生事件，保存 CRI 和 Pod 事件、宿主对象与清理过程。
系列总目录：从进程隔离到运行时与编排。
参考资料
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2026-06-20
kubelet 与容器运行时：节点上到底发生了什么
前两篇讲了调度（选节点）和 Pod 生命周期（状态机）。这一篇下到节点层：kubelet 在节点上把一个 Pod spec 变成真实运行的进程。 容器运行时曾经等于 Docker。Kubernetes 1.24 移除了 dockershim，此后所有节点必须使用实现了 CRI（Container Runtime Interface）的运行时：containerd、CRI-O 或其他。这次迁移对用户基本无感，但原理上有重要变化——kubelet 和运行时之间的通信从内嵌的特定实现变成了标准 gRPC 接口。 本文只问一个问题：从 pod.spec.nodeName 被写入，到容器进程在节点上跑起来，发生了什么？ 节点内部全景图 123456789101112131415161718192021222324API Server → etcd (Pod.spec.nodeName = this-node) │ ▼kubelet (watches own node's Pods via Informer)┌───────────────────────────...
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-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
容器 E08：从容器交付到平台，还增加哪些责任
37把制品变成一次服务响应，38补上故障恢复。平台在这些节点路径之上，还要做跨节点放置、声明式控制、租户权限与流量治理；这些职责既不能让镜像 digest 自动可信，也不能代替节点上真实进程和网络的核验。 用一个最小控制/数据面案例划线 选择一份固定的 probe-app digest，在专用 kind 集群中声明 Deployment/Service。控制面根据声明维持副本，节点 kubelet 经 CRI 建立 sandbox 与进程，服务入口把真实请求发往 Ready 后端；如果加一条 Operator 自定义策略或服务网格流量规则，就要分别核对其 controller 是否改变对象，以及数据面是否实际对请求作了转发/拒绝。只存在 CRD 或策略 YAML 并不说明该 controller 已运行，也不说明路由规则已经生效。多租户还要求 RBAC、namespace、网络与节点权限一起审视；Kubernetes Namespace 是 API 组织维度，不等于 Linux user namespace 的安全边界。 正例先只用标准 Deployment/Service 把请...
2026-06-20
调度器深入：打分、抢占与拓扑约束
调度器（kube-scheduler）是 Kubernetes 控制平面里最容易被低估的组件。它做的事情看起来简单：把没有 nodeName 的 Pod 绑定到某个节点。但"选哪个节点"这个问题背后，隐藏着资源感知、亲和性约束、拓扑分散、优先级抢占等多维度的决策过程。 从 Kubernetes 1.19 起，调度器的内部逻辑通过 Scheduling Framework 对外暴露为一组扩展点。原来散落在代码各处的调度逻辑被重新组织成插件，每个插件只负责一个扩展点。这让调度行为既可预测，又可扩展。 本文的核心问题是：Kubernetes 调度器用什么框架选节点，当资源不足时如何通过抢占让高优先级 Pod 运行？ 调度框架全景图 1234567891011121314151617181920212223242526Pod pending (no nodeName) │ ▼ Scheduler（from ActiveQ by priority） ┌──────────────────────────────────────────────────...
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，整...