AKS 无法从 VPN 之后的私有注册表拉取镜像
kubelet 通过节点网络拉取镜像，而不是通过 Pod 的 VPN。判断时要看节点路由、节点 DNS、拉取过程涉及的每个端点，再看 TLS 与身份。
你的笔记本能正常拉取镜像，Pod 却停在 ImagePullBackOff，于是有人建议把公司 VPN 客户端当作 sidecar 运行。这没有用，因为拉取发生在容器创建之前：kubelet 让节点上的容器运行时去取镜像，而运行时使用的是节点的网络命名空间。工作负载内部的 VPN 无法为这条路径提供路由，而它自己的辅助镜像也仍需先被拉取。
操作顺序决定了故障所在的层
镜像解析排在第一位。kubelet 通过运行时解析注册表名称、建立连接、完成认证、下载各层，这之后才会启动容器。Pod 里与 VPN 有关的一切都发生在这个序列完成之后，所以集群内隧道能通，并不能证明拉取没有问题。
这也解释了为什么缓存镜像特别容易误导人。数周前拉过该镜像的节点会一直提供它，Deployment 看起来一切正常，只有调度器把副本放到较新的节点上时故障才暴露。如果事件时间线里出现扩容、节点替换或节点池升级，应把它们视为触发条件，而不是根因。
三个条件决定修复方向
托管节点池能否访问私有注册表，取决于路由、名称解析和端点集合。节点子网无法路由到注册表网络时，任何凭据都无济于事。能路由但节点的 DNS 路径解析不出注册表名称时，连接根本不会建立。两者都能用，却只对 manifest 端点有效、对注册表重定向到的 blob 端点无效时，拉取会在中途失败并给出误导性的报错。
| Condition | Typical symptom | Where to look |
|---|---|---|
| Node subnet has no route to the registry network | Timeout, no connection | Effective routes on the node NIC, gateway transit, return path on-premises |
| Node resolver cannot see the private zone | Name resolution failure in events | VNet DNS settings and the resolver the node actually uses |
| Only the manifest endpoint is reachable | Auth succeeds, layer download fails | Every hostname the registry hands out during the pull |
| TLS or identity is wrong | Certificate error, 401 or 403 | Server certificate name and trust, scoped pull identity |
仅靠 VNet 对等互连并不会自动带来所有网关传输组合，单向存在的路由不等于可用的路由。节点需要一条经过预期 VPN 网关或已批准设备的受支持路径，注册表一侧也需要返回节点子网的路由。
先读故障，再选修复方案
从 Pod 事件和它落到的节点入手，用你自己的真实名称：kubectl describe pod app-example -n team-example 和 kubectl get pod app-example -n team-example -o wide。事件文本可以把无法解析的主机名与超时区分开，把证书被拒与镜像不存在区分开，也能把授权失败与上述情况区分开。这四类问题对应四个不同的负责人。
认证是最容易被高估的手段。imagePullSecret 只是把注册表凭据交给运行时；它不会安装路由、不会改变节点的解析器，也不能让不受信任的证书变得有效。事件显示拉取未授权时，应检查身份的权限范围；事件显示连接超时，凭据则与问题无关。
Kubernetes 镜像文档 是拉取行为和私有注册表凭据的权威参考，在改动网络之前值得读一遍，因为它把认证与传输之间的边界讲得很清楚。
在 Pod 之下打好通路
按这个顺序来，因为前一步不成立时后一步没有意义。先打通节点网络：确认节点子网到注册表网络有受支持的路径，检查节点上的有效路由、两端的网络安全规则，以及注册表一侧的返回路由。
然后从节点的上下文解析名称。节点的解析器与 Pod 的 DNS 配置不是一回事，在 Pod 里成功不能证明主机运行时也能成功。使用托管的私有 DNS，而不要长期写 hosts 文件条目；这种条目会一直存在到节点被替换，然后悄无声息地消失。
再逐个端点验证。注册表可能把客户端交给独立的认证服务和独立的 blob 存储位置。能访问 manifest 端点几乎不能证明各层可用。最后完成 TLS 与授权：证书要对注册表名称有效，并通过受支持的节点配置获得信任；拉取身份要被限定为可读该仓库。
在不是手工修过的节点上验证
真正有意义的测试是在符合条件的节点上做一次全新拉取并完整下载所有层，最好是由扩容或替换产生的节点。这样能覆盖所有可能调度该工作负载的节点池，包括你忘记的那些。在某一个节点上手工修好不是部署模型，下一次自动扩缩事件就会把缺口找出来。
换一个 VNet 重建集群可以改变路径，但它是最后手段，而不是首要诊断步骤。在提出迁移之前，把现有节点网络与所需的私有路由和受支持的 AKS 网络控制项对照一遍，并把启动后的应用连通性作为独立验证项：Pod 能否访问其后端，与节点能否下载镜像，是两项不同的检查。