定位：主线（Lima + kubeadm，见 00（上）、00（下））之外的对照实验——用一条命令体验"工具帮你把集群全装好"的感觉， 从而理解主线手动搭建的每一步都被工具藏到了哪里。 体验完建议删掉，主线继续走 阶段 0（上）。

0. Minikube 与主线的区别

1. 安装（Mac 上执行）

1
2
3
4
5

brew install minikube

# 验证
minikube version
# 预期输出：minikube version: v1.x.x

驱动选择：用 --driver=docker——你已装 Docker Desktop，minikube 直接复用它， 不需要再开一台虚拟机（这也是它轻量的原因：k8s 节点就是一个 Docker 容器）。

2. 启动集群（国内网络参数必加）

1

minikube start --driver=docker --image-mirror-country=cn

• --image-mirror-country=cn：k8s 组件镜像改从阿里云镜像站拉取（registry.cn-hangzhou.aliyuncs.com/google_containers），不加会因为 gcr.io 被墙而卡死。 它等价于主线 kubeadm 配置里的 imageRepository: registry.aliyuncs.com/google_containers（阶段 1 会写到），只是一个走命令行开关、一个写进配置文件
• 首次启动要下载节点基础镜像（约 1GB），耐心等几分钟

预期输出（结尾）：

1

🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

3. 验证集群

1
2

# 集群状态
minikube status

实测输出（2026-09-13，minikube v1.36.0 / k8s v1.33.1）：

1
2
3
4
5
6

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

1
2

# 节点（minikube 自动配好了 Mac 上的 kubectl 上下文）
kubectl get nodes

1
2

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   52s   v1.33.1

1
2

# 系统组件
kubectl get pods -n kube-system

1
2
3
4
5
6
7
8

NAME                               READY   STATUS    RESTARTS   AGE
coredns-746c97786-gpmv9            1/1     Running   0          51s
etcd-minikube                      1/1     Running   0          57s
kube-apiserver-minikube            1/1     Running   0          57s
kube-controller-manager-minikube   1/1     Running   0          57s
kube-proxy-6v4nl                   1/1     Running   0          52s
kube-scheduler-minikube            1/1     Running   0          57s
storage-provisioner                1/1     Running   0          56s

1
2
3
4

# 终极验证：跑一个真 Pod（和主线的验收标准一样）
kubectl run nginx-test --image=nginx
kubectl get pods -w        # 看到 Running 后 Ctrl+C
kubectl delete pod nginx-test

1
2

NAME         READY   STATUS              RESTARTS   AGE
nginx-test   0/1     ContainerCreating   0          5s

⚠️ 若 ContainerCreating 超过一两分钟不动，是节点内的 containerd 拉不动 docker.io （Docker Hub 被墙），解法见第 5 节表格第 4 行（实测 2026-09-13 即遇到此情况）； 用 kubectl describe pod nginx-test 看 Events，卡在 Pulling image "nginx" 即是。

🔍 对比观察点（体验的价值所在）： 上面的命令和主线一模一样——这就是"工具标准化"的好处。 但你想想：swap 谁关的？SELinux 谁管的？pause 镜像谁换的？CNI 谁装的？ 全被 minikube 藏掉了。这些答案你都知道，因为你亲手做过——这就是主线带给你的。

4. 日常管理命令

1
2
3
4
5
6
7

minikube stop            # 停止集群（数据保留）
minikube start           # 再次启动（不用再加参数，配置已记住）
minikube delete          # 彻底删除集群（体验完用它）
minikube ip              # 查看节点 IP
minikube ssh             # 进入节点容器里看看
minikube dashboard       # 打开 Web 控制台（可选，会再拉几个镜像）
minikube logs            # 启动失败时看日志

5. 国内网络预案（启动卡住时看这里）

原理：一次 minikube start 里藏着三条网络通道，代理配置各有各的地盘

Clash 的另一个坑：规则模式下，阿里云这类国内域名默认走 DIRECT（直连），根本没上代理节点。 所以"开了 Clash" ≠ “走了代理”——直连被安全软件限速时，走 DIRECT 的流量照样慢。 要让国内站点也过代理，得切全局（Global）模式。 排查时先想清楚当前卡在哪个通道，再决定改哪边的配置。

实战记录（2026-09-13）：首次启动时 kicbase 拉取失败转 GitHub（74KB/s，ETA 4 小时+）， 实测当时 Mac 直连阿里云镜像站只有 11KB/s——与 Lima 虚拟机那次是同根因（企业安全软件拦截）。 排查中发现 kicbase 镜像本地已存在（docker images | grep kicbase 确认）， 于是用 --base-image 直接指向本地镜像跳过下载。注意这只解决了底座镜像， 后续 preload 阶段还要从阿里云拉几百 MB 的 K8s 组件镜像，网络不好时仍需代理。

实战记录 2（同日）：中途 Ctrl+C 后重跑依然很慢，且开 Clash + HTTPS_PROXY 无效。 查 ~/.minikube/logs/lastStart.txt 发现剧情已变： 上次没下完的 tar 包（464MB/1.17GB）残留在 ~/.minikube/cache/kic/ 里， minikube 误判"有缓存"，加载时报 tag ... not found in tarball（残缺包）， 随后走第二兜底——从 docker.io（Docker Hub，被墙） 拉 kicbase/stable。 而 HTTPS_PROXY 只对 minikube 本体的 HTTP 下载生效，管不到 Docker Desktop 里 dockerd 的拉取 （dockerd 走代理要在 Docker Desktop → Settings → Resources → Proxies 里配）。 解法：删掉残缺缓存包 rm ~/.minikube/cache/kic/arm64/kicbase_*.tar， 加 --base-image 指向本地完好镜像重跑。

教训：minikube 启动卡住时，先看 ~/.minikube/logs/lastStart.txt 确认到底卡在哪一步、在连谁， 再决定对策——不同阶段（CLI 下载 / dockerd 拉取 / 节点内 containerd 拉取）走的网络通道完全不同。

实战记录 3（同日）：集群验证时 kubectl run nginx-test --image=nginx 卡 ContainerCreating， kubectl describe pod 显示 Pulling image "nginx" 超百秒——节点内 containerd 直连 docker.io 被墙 （通道 ③，Docker Desktop 的镜像代理设置管不到）。 解法：minikube image pull docker.m.daocloud.io/library/nginx 预拉进节点（约 6 分钟）， 删掉旧 Pod 后用带前缀的镜像名重建，5 秒 Running。

注意：minikube 跑在 Docker Desktop 的虚拟机里，它的网络是 Docker Desktop 管的， 和你 Lima 虚拟机的 192.168.5.x/192.168.64.x 完全是两个世界，互不影响。 排查思路可复用主线的分层法（阶段 0（上）附录 A）。

6. 体验完收拾干净

1
2

minikube delete
# Docker Desktop 里的 minikube 容器会被删除；brew uninstall minikube 可卸载本体

7. 原理深挖：一条命令背后发生了什么

7.1 四层套娃：你的 Pod 实际跑在哪

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

macOS（你的 Mac）
└── Docker Desktop 的 Linux 虚拟机
    │   容器共享宿主机内核，macOS 的内核不是 Linux，
    │   所以 Mac 上要跑 Linux 容器必须先有这台 Linux VM
    └── minikube 节点容器（kicbase 镜像）
        │   一个"假装自己是台完整服务器"的容器：内置 systemd、containerd、kubeadm
        ├── systemd ── 管理 kubelet（和主线 Rocky 虚拟机里一模一样的形态）
        ├── containerd ── 节点自己的容器运行时（独立于 Docker Desktop 的 dockerd）
        ├── 控制面静态 Pod：etcd / apiserver / scheduler / controller-manager
        │   （清单位于 /etc/kubernetes/manifests，kubeadm 的标准做法）
        └── 你的业务 Pod（nginx-test 就跑在这里）

要点：minikube 节点不是虚拟机，而是 Docker Desktop 那台 Linux VM 里的一个容器。 kicbase（Kubernetes in Container）的绝活是把 systemd 塞进容器， 于是 kubelet、containerd 都能以真实服务器的形态运行—— 你在主线阶段 0/1 亲手做的每件事，它都在这个容器里替你预置好了。

7.2 对照主线：它把哪些步骤藏掉了

7.3 kubectl 是怎么连上"容器里的集群"的

1. API server 在节点容器内部监听 8443
2. Docker 把容器的 8443 映射到 Mac 的 127.0.0.1:<随机端口>
3. minikube 把 server 地址 + CA + 客户端证书写进 ~/.kube/config 的 minikube 上下文

动手验证（两个端口应一致）：

1
2

docker port minikube                        # 8443/tcp -> 127.0.0.1:xxxxx
kubectl config view --minify | grep server  # server: https://127.0.0.1:xxxxx

7.4 进节点亲眼看看（强烈建议）

1
2
3
4
5

minikube ssh                                # 进节点容器
sudo systemctl status kubelet --no-pager    # kubelet 就是 systemd 服务，和主线一致
ls /etc/kubernetes/manifests                # 控制面静态 Pod 清单，kubeadm 同款
sudo crictl images                          # 节点内 containerd 的镜像（前缀全是阿里云）
exit

看完你就明白：minikube ≈ 把"阶段 0 + 阶段 1 的全部手工"自动化后塞进一个容器。 它替你省掉的每一步，都是你主线练过的每一步。

7.5 缓存与兜底链（呼应第 5 节实战记录）

• K8s 组件镜像：minikube 先在 Mac 侧下载成 tar 存到 ~/.minikube/cache/images/，再装进节点——所以第二次 start 飞快
• kicbase 底座的获取兜底链：本地 docker 已有 → 镜像仓库拉取（cn 参数指向阿里云）→ GitHub Release 直下 tar 包 → docker.io/kicbase/stable；缓存 tar 在 ~/.minikube/cache/kic/，残缺缓存会投毒（实战记录 2）
• minikube image pull <镜像> = 替你进节点让 containerd 拉镜像（通道 ③），拉完业务 Pod 秒起（实战记录 3）

7.6 为什么说它"偏离生产"

• 节点是容器不是虚拟机：没有独立内核（与 Docker Desktop 的 VM 共享）、systemd 是被改造塞进容器的、网络是 docker 桥接而非真实节点网卡
• 单节点：控制面和业务负载挤在一起，练不到多节点、高可用
• 结论：它适合"用 K8s 跑东西"，不适合"理解 K8s 怎么活的"——所以本篇只是番外，主线 Lima + kubeadm 才是正菜

小结

Minikube 一分钟给你集群，主线一天教你集群——两个都体验过， 你就同时拥有了"用的效率"和"修的底气"。回主线：阶段 1「搭建集群」（系列第 1 篇，即将发布）。