Kubernetes节点镜像凭证提供机制

私有镜像拉取不一定只依赖工作负载中的 imagePullSecrets。节点也可能具备独立的镜像仓库认证来源，因此，排查或轮换凭证时，必须先弄清实际由哪种机制提供认证。否则，即使新 Pod 成功启动，也可能只是使用了节点缓存或其他有效凭证。

节点凭证如何参与拉取

节点镜像凭证提供机制的核心，是让节点侧在需要拉取镜像时获得仓库认证信息，而不是要求每个工作负载都直接携带凭证引用。与命名空间内的 Secret 相比，这类机制的管理边界更偏向节点和平台：工作负载指定镜像，节点侧的凭证机制则可能参与对应仓库的认证。

两种方式并不必然互斥。集群中可能同时存在 Pod 的 imagePullSecrets、ServiceAccount 提供的默认引用，以及节点或云平台提供的认证机制。正因为认证来源可能不止一种，不能仅凭 Pod 配置判断最终使用了哪份凭证，也不能把节点侧认证理解为天然适合所有工作负载。

选择与验证的边界

采用节点侧机制前，应确认凭证由谁签发和管理、适用于哪些仓库或镜像，以及节点上的哪些工作负载可能受益。仓库账号仍应遵循最小权限，只授予必要的镜像拉取权限；节点管理权限和凭证维护权限也需要明确分工。

切换或轮换后，应使用获准的私有测试镜像进行受控拉取，结合仓库认证记录、节点缓存和其他凭证来源判断结果。必要时选择未缓存的测试镜像或受控测试节点，避免把已有缓存误认为新凭证生效。生产变更宜分批进行，并观察新建 Pod 的拉取事件和工作负载可用性。

拉取失败也不一定意味着凭证错误：网络、DNS、TLS、仓库可用性和镜像引用错误都可能导致失败。平台团队应同时检查节点侧配置、Pod 事件和仓库记录，再决定是否调整凭证；如果旧凭证已泄露，则不应为方便回滚而继续使用。