--driver=none无隔离，控制面直跑宿主机；docker driver共享内核但特权容器风险高；podman driver支持rootless与user namespace，隔离性最佳。
minikube --driver=none 实际上没有容器隔离
它直接在宿主机 Linux 上拉起 kubelet、etcd 等组件，所有 Kubernetes 控制平面进程都跑在 host PID/ns/cgroup 里，和你手动 systemctl start kubelet 几乎等价。这意味着：
- Pod 容器仍由你本地已安装的容器运行时（如
docker或podman）启动，但控制面本身不隔离 -
--driver=none不创建虚拟机或命名空间边界，宿主机上任何进程都能看到 kubelet 的 PID、修改其 cgroup、甚至 kill 掉 etcd - 无法限制 minikube 自身对宿主机资源的占用（比如 kube-apiserver 内存飙高会直接吃光 host 内存）
- 调试方便，但生产级隔离性为零 —— 不适合多用户、混部或安全敏感场景
用 docker driver 时，minikube 运行在 Docker 容器里，但控制面仍共享 host 内核
minikube 启动一个名为 minikube 的特权容器（docker run --privileged），里面跑完整 K8s 控制平面。关键点是：
- 容器有自己的 PID namespace，但内核是宿主机的，/proc/sys/net/bridge/bridge-nf-call-iptables 这类全局参数仍由 host 控制
- Docker 默认不开启 user namespace，所以容器内 root = host root，一旦逃逸就完全失守
- 网络默认走
docker0网桥，Pod IP 和 host 网段可能冲突（比如都用 172.17.0.0/16），导致kubectl logs失败或 DNS 解析异常 - 如果你宿主机没装
docker或没加docker用户组，minikube start --driver=docker会报permission denied while trying to connect to the Docker daemon socket
podman driver 在 rootless 模式下能实现更强的进程与文件系统隔离
Podman 支持无 root 权限运行隔离容器，minikube 利用这一点启动一个 rootless Podman 容器来承载 K8s 组件：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
- 不需要
--privileged，也不依赖/var/run/docker.sock，规避了 Docker daemon 权限过大问题 - 自动启用 user namespace 映射（UID/GID 从 100000 开始），容器内 root 对应 host 上非特权用户，大幅降低逃逸危害
- 但注意：Podman 的 cgroups v2 支持必须开启（
/proc/sys/kernel/unprivileged_userns_clone要为 1 或使用 systemd-run），否则minikube start --driver=podman会卡在 “Starting control plane…” - 镜像拉取行为不同 —— Podman 默认不走 Docker Hub 配置的 registry mirror，若你公司有私有镜像源，需额外配置
~/.config/containers/registries.conf
选哪个 driver？看你的威胁模型和调试需求
不是性能或功能差异，而是“谁有权关掉你的集群”以及“谁能看到你的 secrets”：
- 本地快速验证 YAML？用
--driver=none，快且透明，但别跑敏感 workload - 团队共享开发机、需要防误操作？避开
--driver=docker，它把整个 K8s 控制面钉死在 Docker daemon 权限上 - 宿主机是较新 Linux（5.11+）、启用了 cgroups v2？优先试
--driver=podman，rootless + user namespace 是目前最轻量又相对靠谱的隔离方案 - 所有 driver 下，
minikube ssh都不安全：--driver=none直连 host shell，--driver=docker/podman进的是容器 shell —— 但它们都不是 hardened 的运维终端，别用来做长期管理
真正麻烦的从来不是选 driver，而是忘了 minikube 默认把 etcd 数据存在 /tmp 或容器临时层里 —— 重启后集群状态全丢，而这个细节连 minikube start --help 都藏得挺深。
