3、镜像拉取流程详解：kubelet → containerd → registry 的完整链路、镜像凭证的传递机制

在多集群与混合云环境中，镜像拉取是工作负载调度的核心前置动作。理解从 kubelet 发起请求，经过 containerd 运行时，最终到达远端 registry 的完整链路，以及镜像凭证（Image Pull Secret）在其中的传递与生效机制，是配置 Cilium 网络策略、保障跨集群拉取权限的基础。

3.1 镜像拉取的三段式架构

整个拉取流程可抽象为三个角色、两个接口：

3.2 完整拉取时序与凭证传递

以下 SVG 展示了从 Pod 创建到镜像层下载的完整时序，并标注了凭证（Image Pull Secret）的传递路径：

3.3 凭证传递的三种模式

根据集群配置与 registry 类型，凭证传递存在三种典型模式：

3.4 containerd 出站流量的网络特征

从 Cilium 网络策略配置的角度，containerd 的出站流量具有以下关键特征：

• 目标端口： 443 (HTTPS) 或 5000 (HTTP，私有 registry)
• 目标 IP： registry 域名解析后的 A 记录 / CNAME
• 协议： TCP，TLS 1.2/1.3
• 源端点： 节点 IP（非 Pod IP），因为 containerd 运行在宿主机命名空间
• DNS 依赖： 必须先解析 registry 域名，否则 containerd 无法建立连接

3.5 凭证传递失败时的典型错误码

理解以下错误码有助于快速定位凭证或网络问题：

3.6 链路中各层的安全控制点

以下 SVG 从安全控制视角，展示镜像拉取链路中每一层可施加的策略与检查点：

3.7 多集群场景下的凭证传递挑战

当镜像拉取跨越集群边界时，凭证传递面临以下额外挑战：

• 凭证同步延迟： 在 Cluster A 中创建的 ImagePullSecret 不会自动同步到 Cluster B，需要外部工具（如 External Secrets Operator）进行跨集群同步。
• Registry 域名解析差异： 不同集群可能使用不同的 DNS 解析策略（CoreDNS / NodeLocal DNSCache），导致 containerd 解析到不同的 registry IP。
• 网络策略碎片化： 每个集群的 Cilium 策略需要独立配置 containerd 到 registry 的出站规则，且需保持策略一致性。
• IAM 角色跨集群信任： 使用云厂商 IAM 时，需要建立跨集群的 OIDC 信任关系，否则 containerd 无法获取有效的临时凭证。