Kubelet -> 容器运行时 (CRI) -> CNI 插件 -> IPAM

● 真正的阻塞原因：当 kubeadm init 部署完 CoreDNS 时，因为集群还没有网络插件（CNI），底层的 kubelet 无法为 Pod 配置网络。因此，CoreDNS Pod 无法完成网络初始化，只能一直处于 Pending （等待）状态。
● 自动激活：当您执行 kubectl apply -f calico.yaml 后，Calico 成功安装并在各个节点上运行。

1. Kubelet 接收指令并调用 CRI
当调度器将一个 Pod 分配到某个节点后，该节点上的 kubelet 会接收到创建 Pod 的指令。随后， kubelet 会通过 CRI（容器运行时接口）调用底层的容器运行时（例如 containerd 或 CRI-O）来创建 Pod 和容器。
2. 容器运行时调用 CNI 插件
在容器创建的过程中，作为容器运行时一部分的 CRI 插件会与 CNI 插件进行交互。CRI 会读取节点上的 CNI 配置文件，并执行相应的 CNI 可执行程序（如 Flannel、Calico 等）。
3. CNI 与 IPAM 模块分配 IP
CNI 插件被调用后，会在宿主机和容器的网络命名空间之间创建虚拟网卡（veth pair）。接着，CNI 插件会进一步调用其内置的 IPAM（IP Address Management，IP地址管理） 模块（如 host-local 等），从该节点预先分配好的子网（Pod CIDR）中，为这个 Pod 分配一个唯一的 IP 地址，并配置好路由规则。

于是立刻为之前挂起的 CoreDNS Pod 分配了 IP，CoreDNS 也就顺理成章地变为了 Running 状态

CoreDNS 的 Pod IP 分配机制，与您之前理解的普通 Pod 获取 IP 的机制是完全一样的。它同样遵循 Kubelet -> 容器运行时 (CRI) -> CNI 插件 -> IPAM 模块 这一标准链路