Minikube start启动时卡在Pulling base image步骤如何排查解决

先执行带debug日志的启动命令定位具体卡点，不要盲目重试：

minikube start --v=7 --alsologtostderr

根据日志输出对应处理，常见场景解决方案如下：

常见场景处理 #

• 网络无法访问gcr.io官方镜像源（国内环境90%以上为该原因）
  无需手动配置复杂代理，直接指定国内镜像源启动即可：

  • 先清理之前启动失败的残留实例：

    minikube delete --all
    

  • 带国内镜像源参数启动，minikube会自动匹配对应版本的基础镜像，无需手动指定版本：

    minikube start --image-mirror-country=cn
    

  • 如果自动匹配镜像失败，可以手动指定和当前minikube版本匹配的kicbase镜像：

    # 先执行minikube version确认版本，比如v1.33版本对应kicbase v0.0.42
    minikube start --base-image="registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.42"
    

  • 如果使用Docker/Podman作为minikube驱动，也可以提前把基础镜像拉到本地，打tag为官方镜像名后再启动，minikube检测到本地存在对应镜像就不会发起远程拉取：

    # 替换成你对应版本的tag即可
    docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.42
    docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.42 gcr.io/k8s-minikube/kicbase:v0.0.42
    minikube start
    

• 虚拟化驱动异常

  • 如果使用Docker Desktop作为驱动，先执行docker info确认Docker服务正常运行，没有权限报错、服务卡死问题，Windows/macOS下确认Docker Desktop已经完全启动，没有处于加载状态。
  • 如果使用KVM/Hyper-V/HyperKit作为原生虚拟化驱动，先确认BIOS中CPU虚拟化功能已经开启，对应虚拟化服务运行正常，没有被其他虚拟机软件占用。

• 残留实例/缓存冲突
  第一次启动失败后残留的残缺虚拟机实例、未完成拉取的镜像缓存会导致后续启动一直卡住，执行以下操作完全清理后重试：

  minikube delete --all
  # Linux/macOS执行下面的命令清理缓存
  rm -rf ~/.minikube/cache/
  # Windows下删除 C:\Users\你的用户名\.minikube\cache 目录
  

• 资源不足或代理配置错误

  • 检查minikube数据所在的磁盘至少有20G以上空闲空间，磁盘空间不足时镜像写入会无响应，不会抛出明确报错。
  • 如果本地开启了系统代理，注意minikube启动的虚拟机内部默认不会继承宿主机的代理配置，要么在启动时传入代理参数：

    minikube start --docker-env HTTP_PROXY=http://127.0.0.1:你的代理端口 --docker-env HTTPS_PROXY=http://127.0.0.1:你的代理端口 --docker-env NO_PROXY=localhost,127.0.0.1,10.96.0.0/12
    

  • 要么暂时关闭代理，使用国内镜像源启动，避免代理规则拦截导致镜像拉取超时。

内容的提问来源于stack exchange，提问作者Sumit Mukharjee