Minikube 报 ErrImageNeverPull：宿主机镜像还没进入节点缓存

镜像在宿主机上能用 docker run 启动，部署到 Minikube 却出现 ErrImageNeverPull，而 Pod 配置了 imagePullPolicy: Never。先确认镜像是否进入了实际运行 Pod 的节点缓存：宿主机 Docker 的镜像库和 Minikube 节点的容器运行时通常是两处存储。

这篇适用于本地 Minikube 开发集群，特别是使用容器或虚拟机驱动的情况。Never 表示不尝试从仓库拉取，节点没有该镜像时就无法启动；它不能让宿主机镜像自动出现在节点上。采用 none 驱动等共享环境时，应按实际运行时判断，不能只凭 Minikube 名称断定隔离。

先对齐 profile、节点和完整镜像名

以下是只读检查示例，替换 profile、命名空间和 Pod 名称：

minikube profile list
kubectl config current-context
kubectl -n app describe pod web-abc123
minikube -p dev image ls

确认 kubectl 指向 dev 对应的集群，Pod 实际使用的镜像包含预期名称与标签，并检查事件是不是禁止拉取且本地缺镜像。不要只核对 Deployment 源文件，运行中的 Pod 可能仍来自旧模板。

web:dev-2 与 web:latest 不是同一个标签；导入另一个 profile 也不能修复当前集群。多节点集群还要核对 Pod 所在节点及所有可能被调度到的节点，不能以一个节点的检查结果代替整个集群。

把已构建镜像导入选定的 Minikube

当前 Minikube 提供直接导入到集群运行时的 image load。以下示例假设当前 Docker 连接环境已经存在可信的 web:dev-2，且 dev 是目标本地集群：

minikube -p dev image load --daemon web:dev-2
minikube -p dev image ls

--daemon 指定从 Docker daemon 的镜像库读取。检查当前 Docker context、DOCKER_HOST 等连接环境，确保它们指向真正持有该镜像的 Engine。若源镜像本来就没有进入这个 Engine，需要先处理构建输出；反复加载不存在的标签没有作用。

导入会占用节点存储，当前命令默认允许覆盖同名标签，因此开发时宜使用新的明确标签。不要覆盖其他工作负载正在引用的版本，再把“成功加载”当成安全更新的证明。

把工作负载的镜像改为这个标签，保留本地开发场景需要的 Never，或按交付方式选择 IfNotPresent。示例仅展示已有容器的两个字段，不替换完整容器配置：

containers:
  - name: web
    image: web:dev-2
    imagePullPolicy: Never

只有远程仓库中确实有可访问的镜像时，改成允许拉取才有意义；否则可能只是把错误变为 ImagePullBackOff。跨机器交付还应采用可访问的镜像仓库，而不是依赖某台开发机的本地缓存。

docker-env 需要匹配节点运行时

另一种开发方式是把当前终端指向 Minikube 内部的 Docker daemon，再在那里构建。但这条路径需要节点确实采用相应的 Docker 运行时，不能把 docker-env 当作所有 containerd 集群的通用修复。

使用这条方式还会改变当前终端后续 Docker 命令的目标，操作结束应恢复终端环境并重新核对连接。已有宿主机镜像时，显式导入通常更容易分清源与目标。

修改前保存部署模板和原镜像版本。更新后确认新 Pod 不再报 ErrImageNeverPull、镜像对应预期构建，并完成应用就绪检查；镜像能启动仍不代表业务配置正确。回退时恢复原模板与可用镜像，并确保旧镜像在目标节点仍可用，不必清空整个镜像缓存。