主机重启后Minikube提示不存在？重启前后集群正确操作方法

你看到的The "minikube" host does not exist报错，本质是系统重启后podman、cri-o依赖服务未自动启动，minikube对应的控制面容器处于停止状态，minikube命令无法探测到运行中的集群实例，不是集群数据被删除。

做完以下配置可以避免重启后出现集群无法识别的问题：

• 配置底层运行时服务开机自启，执行以下命令：

  sudo systemctl enable --now podman.socket crio.service
  

• 给minikube控制面容器设置自动重启策略，podman驱动下minikube实例默认容器名和实例名一致，执行：

  podman update --restart=always minikube
  

  如果创建minikube集群时自定义了实例名，把命令末尾的minikube替换为实际实例名即可
• 非故障场景下重启主机前，可提前执行集群暂停命令将内存中的运行状态刷入持久化存储，降低状态损坏概率：

  minikube pause
  

• 若提前完成了上述持久化配置，开机后等待1~2分钟让服务和容器自动拉起，直接执行minikube status即可看到正常运行状态；如果kubelet组件启动延迟，执行一次minikube start（保持和创建时一致的驱动、运行时参数）即可自动恢复，不会重建集群。
• 若未做提前配置，已经出现host不存在的报错，按以下步骤操作：
  1. 手动拉起底层依赖服务：

     sudo systemctl start podman.socket crio.service
     

  2. 检查minikube容器状态，停止状态则手动启动：

     # 列出所有容器定位minikube实例
     podman ps -a | grep minikube
     # 若容器状态为Exited，执行启动命令
     podman start minikube
     

  3. 容器启动后等待30秒，执行和创建集群时参数一致的start命令恢复集群控制面：

     minikube start --driver=podman --container-runtime=cri-o
     

  4. 命令执行完成后执行minikube status校验，所有组件状态显示为Running即恢复正常。

注意：恢复过程不要添加--delete-on-failure类参数，避免误删已有集群数据。

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