K8s从零到实战 on WYF 的技术博客

K8s 从零到实战 00（番外）：Minikube 快速体验

Sun, 13 Sep 2026 10:20:00 +0800

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

0. Minikube 与主线的区别

维度	Minikube	主线：Lima + kubeadm
集群怎么来	一条命令，全自动	每个组件亲手装
节点形态	Docker 容器（或虚拟机）里的"模拟节点"	完整的 Rocky Linux 虚拟机
组件可见性	黑盒（etcd/apiserver 藏在容器里）	透明（systemd 服务，可查可拆）
对应生产	偏离较多	1:1 对应
适合	快速用 k8s 跑应用	学懂 k8s 本身

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. 国内网络预案（启动卡住时看这里）

现象	原因	解法
提示 `cannot pull kicbase image`，转而从 GitHub 下载 `kicbase-vX.X.X-arm64.tar`，几十 KB/s	`--image-mirror-country=cn` 只管 K8s 组件镜像；kicbase 底座（约 1.2GB）拉取失败后，minikube 兜底从 GitHub Release 直下 tar 包，国内直连要几个小时	① Ctrl+C；② 手动拉底座镜像（tag 以启动日志"正在拉取基础镜像 vX"为准）：`docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.47`；③ 重跑加 `--base-image=registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.47`，命中本地镜像，下载整段跳过
想让 GitHub 兜底下载本身变快	minikube 本体的 HTTP 下载会读 Shell 的代理变量	开 Clash 后带变量重跑：`HTTPS_PROXY=http://127.0.0.1:7897 minikube start --driver=docker --image-mirror-country=cn`（代理也会被自动注入节点容器）
k8s 组件镜像拉取失败（preload 阶段卡住）	gcr.io 被墙，或此时直连阿里云被拦	确认 `--image-mirror-country=cn`；仍卡住就 Ctrl+C，开 Clash、带上面的代理变量重跑
Pod 的镜像（nginx 等）拉不动，`ContainerCreating` 卡住	docker.io 被墙。注意：kubectl 跑的 Pod 由节点容器内的 containerd 拉镜像，Docker Desktop 的 registry-mirrors 管不到它	① 重建集群时加 `--registry-mirror=https://docker.m.daocloud.io`；② 或镜像名直接带前缀：`kubectl run nginx-test --image=docker.m.daocloud.io/library/nginx`（可配合 `minikube image pull <镜像>` 先手动拉进节点）；③ `kubectl describe pod <名>` 看 Events 确认是否卡在 Pulling
全都不行	Mac 直连被拦（公司安全软件）	打开 Clash（允许局域网），Docker Desktop → Settings → Resources → Proxies 填 `http://127.0.0.1:7897`

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

通道	谁在发请求	代理怎么配
① minikube CLI 自己的 HTTP 下载（GitHub 兜底 tar 包等）	Mac 上的 minikube 进程	shell 环境变量 `HTTPS_PROXY=...`，它自己会读
② dockerd 拉镜像（kicbase、业务镜像）	Docker Desktop 虚拟机里的 dockerd	看不到 shell 变量；只能配 Docker Desktop → Settings → Resources → Proxies
③ 节点容器内拉 K8s 组件镜像	minikube 节点容器里的 containerd	minikube 检测到 ① 的代理变量后会自动注入节点（`127.0.0.1` 自动换成 `host.docker.internal`，前提是 Clash 开了 Allow LAN）

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 对照主线：它把哪些步骤藏掉了

主线亲手做（阶段 0/1）	minikube 藏到哪
关 swap、注释 fstab	kicbase 镜像本身无 swap
SELinux 设宽容、关防火墙	容器里没有这套安全体系
加载 br_netfilter、调 sysctl	节点容器启动时自动完成
装 containerd、配 certs.d 镜像代理	containerd 内置于 kicbase；`--registry-mirror` 可注入代理配置
kubeadm init、证书签发	minikube 在节点内调用内置 kubeadm 自动完成
装 CNI 插件	内置轻量 CNI（kindnet）默认装好
写 kubeconfig、切上下文	自动写入 `~/.kube/config` 并设为当前上下文

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

API server 在节点容器内部监听 8443
Docker 把容器的 8443 映射到 Mac 的 127.0.0.1:<随机端口>
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 篇，即将发布）。

K8s 从零到实战 00（下）：内核参数与容器运行时（containerd 三关）

Sun, 13 Sep 2026 10:10:00 +0800

目标：完成 k8s 安装前的最后两项准备——内核网络参数（k8s 的神经网络）和容器运行时（k8s 的手）。前置：已完成阶段 0（上）：虚拟机与系统初始化。步骤编号延续上篇（从第 5 步开始）；所有命令在 Rocky 机器上以 root 执行。

5. 加载内核模块并开启 iptables 桥接流量（必须）

为什么必须——k8s 的 Service 网络（阶段 3 主角）依赖三样底层能力：

overlay：容器镜像分层存储的文件系统，containerd 启动容器必备
br_netfilter + bridge-nf-call-iptables=1：强制网桥流量经过 iptables。Service 虚拟 IP 靠 iptables 规则转换（kube-proxy 写入），桥内流量若绕过 iptables，Service 全部失灵
ip_forward=1：允许节点转发数据包，跨节点 Pod 通信的前提

缺了任何一样，阶段 1 的 kubeadm init 预检会直接报错拒绝安装。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


cat > /etc/modules-load.d/k8s.conf <<EOF
overlay
br_netfilter
EOF

modprobe overlay
modprobe br_netfilter

cat > /etc/sysctl.d/k8s.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sysctl --system

验证：lsmod | grep br_netfilter 应有输出，例如：

1
2


br_netfilter 32768 0
bridge 315392 1 br_netfilter

输出读法（四列 = 模块名 / 大小(字节) / 引用计数 / 被谁引用）：引用计数 0 不等于没用——br_netfilter 靠 sysctl 开关起作用，不靠被谁引用； bridge 行尾出现 br_netfilter，说明它是 bridge 网桥驱动的"扩展插件"，专门给网桥加 netfilter（iptables）钩子。两行都在 = 这对搭档都在岗。（/etc/modules-load.d/ 管开机自动加载，modprobe 管立即生效，缺一不可。）

6. 安装容器运行时 containerd

k8s 自己不会跑容器——它只是调度大脑（决定 Pod 放哪台机器），真正拉镜像、起容器的是容器运行时。kubelet 通过标准接口 CRI 指挥 containerd 干活：kubectl 命令 → apiserver → scheduler → kubelet → containerd → 容器进程。 Kubernetes 从 1.24 起不再直接支持 Docker（它对 k8s 来说太重），containerd 是主流选择。

6.1 安装

1
2
3
4
5
6
7
8


# download.docker.com 国内不可达，使用阿里云 docker-ce 源（只借用它里面的 containerd 包）
dnf config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

# 安装 containerd
dnf -y install containerd.io

# 生成默认配置
containerd config default > /etc/containerd/config.toml

containerd 的官方发布渠道是 Docker 公司的软件源 download.docker.com（国内不可达）。阿里把它整个镜像了一份，我们借仓库只取 containerd.io 这一个包，不装 docker-ce 本身——虚拟机里不会有 Docker
包名是 containerd.io（不带 .io 的是另一个老包，别搞混）
containerd 没有开箱即用的配置文件，必须先用 config default 生成底版再修改

6.2 关键修改 1：SystemdCgroup = true（与 kubelet 统一资源管理）

1

sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

为什么必改：cgroup 是 Linux 给进程分配/限制资源（CPU、内存）的机制，k8s 的 requests/limits 全靠它。 cgroup 有两种"管理员"：cgroupfs（传统写法）和 systemd（Rocky 9 等现代发行版由 systemd 统一管理）。 一台机器只能有一个管理员——kubelet 用 systemd，containerd 默认却是 cgroupfs（false），两个管理员各记一套账，会导致资源统计错乱、节点不稳定。这行 sed 把 containerd 也划归 systemd 阵营。

6.3 关键修改 2：certs.d 镜像代理（国内拉镜像的生存指南）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Docker Hub 国内被墙，给 docker.io 配置镜像代理（daocloud）
# containerd 的 registry 配置采用 certs.d 目录（类似 docker 的 registry-mirrors）
mkdir -p /etc/containerd/certs.d/docker.io
cat > /etc/containerd/certs.d/docker.io/hosts.toml <<EOF
server = "https://docker.io"
[host."https://docker.m.daocloud.io"]
 capabilities = ["pull", "resolve"]
EOF
# 同理给 registry.k8s.io 配代理：它的 CDN 是 Google 的，国内同样被墙
#（kubeadm 装集群时我们改用阿里云源规避；但 ingress-nginx、metrics-server 等
# 第三方组件的镜像也在 registry.k8s.io，阶段 6/8 会用到这个代理）
mkdir -p /etc/containerd/certs.d/registry.k8s.io
cat > /etc/containerd/certs.d/registry.k8s.io/hosts.toml <<EOF
server = "https://registry.k8s.io"
[host."https://k8s.m.daocloud.io"]
 capabilities = ["pull", "resolve"]
EOF
# 启用 certs.d 目录（containerd 2.x 默认配置里 config_path 为空，指过去即可）
sed -i "/^\s*config_path = ''\s*$/s/''/'\/etc\/containerd\/certs.d'/" /etc/containerd/config.toml

原理：certs.d 是 containerd 的"仓库导航改写本"。它拉镜像时的决策过程是：

1
2
3
4
5
6


要拉 nginx:1.27
 ↓ 补全为完整地址 docker.io/library/nginx:1.27
 ↓ 查导航本：/etc/containerd/certs.d/ 下有没有叫 docker.io 的目录？
 ↓ 有！读里面的 hosts.toml：docker.io 的请求改走 docker.m.daocloud.io
 ↓
实际从 daocloud 下载，但镜像在本地的"户口本"仍登记为 docker.io/library/nginx:1.27

目录结构就是映射关系——要拉哪个仓库的镜像，就用哪个目录下的 hosts.toml：

1
2
3


/etc/containerd/certs.d/
├── docker.io/hosts.toml ← 拉 nginx 等 Docker Hub 镜像时生效
└── registry.k8s.io/hosts.toml ← 拉 k8s 官方组件镜像时生效

hosts.toml 三行的含义：

1
2
3


server = "https://docker.io" # 这份配置管哪个仓库（"户主"）
[host."https://docker.m.daocloud.io"] # 实际去哪拉（"代取点"，可写多个按顺序试）
 capabilities = ["pull", "resolve"] # 代取点只允许"解析+拉取"，禁止 push（安全）

最后那条 sed 是总开关：containerd 2.x 默认配置里 config_path = ''（空 = 根本不看 certs.d 目录），把它指向该目录，导航本才生效。

为什么这样设计，而不是别的办法：

❌ 直接改镜像名（把 nginx 写成 docker.m.daocloud.io/library/nginx）：镜像名写在全世界的 YAML、Helm Chart、kubeadm 生成的清单里，改不完也改不到；换代理时还要全局替换
❌ 配 HTTP 代理：多一个要维护的中间故障点，且企业环境未必有代理可用
✅ certs.d：只在一个地方声明映射，全世界照常用官方镜像名，拉取被悄悄改道； daocloud 挂了改两行 hosts.toml 换一家即可，业务零改动。本质是逻辑地址（镜像名）与物理地址（镜像站）解耦，对 kubelet/YAML/Helm 完全透明

registry.k8s.io 那份的必要性：阶段 1 装集群时核心组件可以换阿里云源，但 ingress-nginx（阶段 6）、metrics-server（阶段 8）等第三方组件的官方清单里写死了 registry.k8s.io 地址，不便改也没法改。配上这条，届时 kubectl apply 官方清单直接跑通。

6.4 关键修改 3：pause（sandbox）镜像指向阿里云（国内搭集群第一坑）

1
2
3


# kubelet 1.34 起改为从 containerd 获取 pause 镜像地址（旧的 --pod-infra-container-image 已失效），
# 而 containerd 默认的 registry.k8s.io/pause 的 CDN 国内被墙，不改会导致所有 Pod 卡在创建阶段
sed -i "/^ \[plugins.'io.containerd.cri.v1.images'\]$/a\ sandbox_image = \"registry.aliyuncs.com/google_containers/pause:3.10.2\"" /etc/containerd/config.toml

pause 容器是什么：一个 Pod 可以装多个容器，它们共享同一个网络命名空间（同一个 IP）。这个"共享"需要一个先行者先把网络命名空间创建好、占住位置——就是 pause 容器（沙箱容器）。每个 Pod 里都有一个看不见的 pause，几乎不占资源，但没它 Pod 无法创建。

问题链条：pause 镜像默认在 registry.k8s.io/pause（Google CDN，国内被墙）→ 老办法是 kubelet 参数 --pod-infra-container-image，但 kubelet 1.34 起该参数失效，改为从 containerd 的 sandbox_image 读取 → 不改的后果是所有 Pod 永远卡在 ContainerCreating。这条 sed 在该插件节下追加一行，指向阿里云镜像站（a\ = 在匹配行之后追加）。

三关总结：SystemdCgroup 让 containerd 与 kubelet 和平共处； certs.d 让 Docker Hub / k8s 官方镜像拉得到；sandbox_image 让 Pod 能创建。少任何一个，阶段 1 都会以不同的姿势翻车。

6.5 （按需）虚拟机直连出网被拦时：给 containerd 配代理

containerd 是系统服务，不读你终端里 export 的代理变量，必须用 systemd drop-in 单独配置（192.168.5.2 是 Lima 内置的"Mac 本机"地址，长期有效，排查思路见阶段 0（上）附录 A）：

1
2
3
4
5
6
7


mkdir -p /etc/systemd/system/containerd.service.d
cat > /etc/systemd/system/containerd.service.d/proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://192.168.5.2:7897"
Environment="HTTPS_PROXY=http://192.168.5.2:7897"
Environment="NO_PROXY=localhost,127.0.0.1,192.168.5.0/24,192.168.64.0/24,192.168.0.0/16,10.96.0.0/12"
EOF

⚠️ 配了这个代理后，将来直连恢复或 Clash 关闭时必须删掉它并重启 containerd （rm 该文件 && systemctl daemon-reload && systemctl restart containerd），否则 containerd 拉镜像全部失败。原则：代理配置和代理软件同开同关。

6.6 启动与验证

1
2
3
4
5


# 启动并设为开机自启
systemctl daemon-reload
systemctl enable --now containerd
systemctl restart containerd
systemctl status containerd --no-pager

验证：

1

ctr version # 能看到 Client/Server 版本号即成功

💡 镜像代理说明：配置后，所有 nginx、mysql 这类来自 Docker Hub 的镜像会经由 docker.m.daocloud.io 代理拉取，对 Kubernetes 完全透明（镜像名不用改）。如果 daocloud 将来失效，换其他可用代理地址改 hosts.toml 即可。 k8s 官方镜像仓库 registry.k8s.io 本教程网络实测可达，无需代理；如果你的网络不行，阶段 1 有阿里云替代方案。

7. 检查清单

进入下一阶段前确认：

1
2
3
4
5


swapon --show # 无输出（swap 已关）
getenforce # Permissive
systemctl is-active containerd # active
sysctl net.ipv4.ip_forward # = 1
lsmod | grep br_netfilter # 有输出

常见问题

Q: 第 6 步装 containerd / 拉镜像时网络不通？ containerd 是系统服务，不读终端环境变量。先按上篇附录 A 的分层法确认是不是"虚拟机直连被拦"，是的话用第 6.5 节的 systemd drop-in 给 containerd 配代理；将来 Pod 出现 ImagePullBackOff 也先怀疑这层。

Q: containerd 配置文件里的插件名为什么和网上旧教程不一样？ containerd 2.x 使用了新版配置格式（如 io.containerd.cri.v1.images），旧教程里的 io.containerd.grpc.v1.cri 是 1.x 的写法。本教程的 sed 命令两种都兼容。

附录 B：集群装好后如何验证（阶段 1 完成后使用）

进程活着 ≠ 集群可用，能跑起一个真 Pod 才是终极证明。按三层验证（虚拟机里、root 执行）：

第一层：节点状态

1
2


kubectl get nodes
# 期望：STATUS 是 Ready

第二层：系统组件 Pod 全部 Running（最关键）

1
2
3
4
5
6


kubectl get pods -n kube-system
# 期望：etcd、kube-apiserver、kube-scheduler、kube-controller-manager、
# coredns（2个）、calico-node 全部 Running 且 READY 是 1/1

kubectl get pods -A
# 不能有 Pending / CrashLoopBackOff / ImagePullBackOff

第三层：跑一个真容器（终极证明）

1
2
3
4
5


kubectl run nginx-test --image=nginx
kubectl get pods -w # 看到 Running 后 Ctrl+C（这步同时验证了调度、镜像拉取、pause 镜像、CNI）
kubectl get pods -o wide # Pod 拿到 IP = Calico 网络正常
kubectl exec -it nginx-test -- curl -sI localhost | head -1 # 期望：HTTP/1.1 200 OK
kubectl delete pod nginx-test # 清理

辅助定位（上面不正常时查）：

1
2


systemctl is-active kubelet containerd # 都应为 active
crictl ps | head # containerd 层面的容器（应有 pause 和业务容器）

判断标准速记：get nodes Ready → 集群成立；kube-system 全 Running → 控制面健康；自建 Pod 到 Running 且能 exec → 端到端真通了（也是本阶段 containerd 三个关键修改的验收）。若 kubectl 报 “connection to localhost:8080 refused”，说明 kubeconfig 没配，先做阶段 1 的 mkdir -p $HOME/.kube && cp /etc/kubernetes/admin.conf $HOME/.kube/config。

动手练习

查看 containerd 配置文件 /etc/containerd/config.toml，找到你刚改的 SystemdCgroup 和 config_path 两行。
查看 /etc/containerd/certs.d/docker.io/hosts.toml，理解镜像代理的配置结构。

下一步

➡️ 阶段 1：搭建集群（系列第 1 篇，即将发布——从这里开始正式安装 Kubernetes）

K8s 从零到实战 00（上）：虚拟机与系统初始化（Lima + Rocky 9）

Sun, 13 Sep 2026 10:00:00 +0800

目标：得到一台 Rocky Linux 9 机器，并完成最基础的系统设置（软件源、swap、防火墙、SELinux）。本篇不涉及任何 k8s 安装。本地练习用 Lima 在 Mac 上创建虚拟机；如果是真实服务器，直接从「第 2 步」开始。网络异常（dnf 卡住 / 虚拟机无法出网）直接看文末「附录 A：网络分层排查实录」。本篇为阶段 0 上半部分；内核参数与容器运行时见阶段 0（下）。

1. 创建 Rocky Linux 9 虚拟机（仅 Mac 本地练习需要）

1.1 搭建思路（小白视角）

在动手前，先搞清楚"我们到底在造什么东西"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


你的 Mac（macOS，没有 Linux 内核）
 │ k8s 是纯粹的 Linux 技术，macOS 上跑不了
 ▼
需要一个"电脑里的电脑" = 虚拟机
 │ Lima：开源虚拟机工具（brew 安装），底层用 macOS 自带的虚拟化框架
 ▼
虚拟机开机需要两样东西：
 ① 系统盘镜像 = 一个"装好 Rocky 9 系统的硬盘文件"（qcow2，约 496MB）
 ② 规格说明书 = 模板文件 lima/rocky-9-ustc.yaml（用哪个镜像、几张网卡、挂什么目录）
 ▼
limactl start 读模板 → 校验镜像 → 复制扩容成 30G 系统盘 → 开机 → 自动配好 SSH
 ▼
limactl shell 进去，就是一台标准的 Rocky Linux 9 服务器

为什么要手动下载镜像（而不是让 Lima 自己下）：Rocky 官方源国内只有约 50KB/s，国内最快的中科大镜像站会用 WAF 拦截 Lima 的多线程下载器（403）。所以用 curl 单线程先下载到本地（1~2 分钟），模板直接指向本地文件—— 创建虚拟机时完全不需要联网下载，重建也只要几分钟。

1.2 操作命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# ① 安装 Lima（开源虚拟机工具）
brew install lima

# 验证安装：版本号 ≥ 2.0.0 即满足模板门槛（minimumLimaVersion: 2.0.0）
brew info lima | head -2
# 预期输出：==> lima ✔: stable 2.2.0 (bottled), HEAD
# 注：Caveats 里提到的 lima-additional-guestagents 是给"跨架构模拟"用的
#（M 系列芯片跑 x86 虚拟机才需要），aarch64 虚拟机 + Apple Silicon 是同架构，不用装。

# ② 从中科大镜像站手动下载 Rocky 9.8 镜像（约496MB，1~2分钟）
curl -o lima/images/rocky-9.8-aarch64.qcow2 \
 https://mirrors.ustc.edu.cn/rocky/9/images/aarch64/Rocky-9-GenericCloud-Base-9.8-20260525.0.aarch64.qcow2

# （可选）校验镜像完整性：输出必须等于模板里的 digest
shasum -a 256 lima/images/rocky-9.8-aarch64.qcow2
# 预期输出：24692a444f1f0b8bb95375c38c8b43f8099a115347623691be2c330b40c8a1fe

# ③ 创建并启动虚拟机（4核/6GB内存/30GB磁盘），模板 lima/rocky-9-ustc.yaml 指向上面的本地镜像
limactl start --name=k8s-rocky --cpus=4 --memory=6 --disk=30 --tty=false lima/rocky-9-ustc.yaml

预期输出（创建完成后）：

`1`	INFO[...] READY. Run `limactl shell k8s-rocky` to open the shell.

④ 确认虚拟机创建成功（三连验证，都在 Mac 上执行）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# 第一看状态：STATUS 是 Running，且规格符合预期（4核/6GiB/30GiB）
limactl list
# 预期输出：
# NAME STATUS SSH VMTYPE ARCH CPUS MEMORY DISK
# k8s-rocky Running 127.0.0.1:xxxxx vz aarch64 4 6GiB 30GiB

# 第二看系统：能读出 Rocky Linux 9 的系统信息
limactl shell k8s-rocky -- cat /etc/os-release | head -2
# 预期输出：NAME="Rocky Linux" / VERSION="9.8 (Blue Onyx)"

# 第三看架构：aarch64（与模板 arch 一致）
limactl shell k8s-rocky -- uname -m
# 预期输出：aarch64

1
2


# ⑤ 进入虚拟机（之后所有操作都在虚拟机里执行）
limactl shell k8s-rocky

真实服务器：跳过本步，直接 SSH 登录你的 Rocky 9 服务器即可。以下所有命令在两种环境下完全一致。

1.3 模板文件逐行解读（lima/rocky-9-ustc.yaml）

模板全文如下（它就是你这台虚拟机的"出生证明"）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# Lima 虚拟机模板：Rocky Linux 9 (aarch64)
minimumLimaVersion: 2.0.0

images:
- location: "/Users/wyf/work/agentproject/k8study/lima/images/rocky-9.8-aarch64.qcow2"
 arch: "aarch64"
 digest: "sha256:24692a444f1f0b8bb95375c38c8b43f8099a115347623691be2c330b40c8a1fe"

mounts:
- location: "~"

mountTypesUnsupported: [9p]

# 使用 macOS Virtualization.framework 的 NAT 网络（vzNAT）
networks:
- vzNAT: true

逐字段拆解：

minimumLimaVersion: 2.0.0 — 版本门槛 Lima 低于 2.0.0 会直接拒绝启动这个模板，而不是做到一半出错。相当于软件包装盒上的"系统要求"。

images: — 虚拟机的系统盘从哪来

字段	含义
`location`	镜像文件位置。可以是 URL（Lima 会联网下载），这里写死本地绝对路径 → 创建时零下载
`arch`	镜像的 CPU 架构。`aarch64` = ARM64，对应 Apple Silicon；Intel Mac 要用 `x86_64`
`digest`	镜像的 SHA256 校验值。Lima 用前必校验，文件损坏或被篡改就拒绝启动

手动校验镜像完整性的方法（算法必须和模板里一致，MD5 和 SHA256 没有可比性）：

1
2


shasum -a 256 lima/images/rocky-9.8-aarch64.qcow2
# 输出应等于 24692a444f1f0b8bb95375c38c8b43f8099a115347623691be2c330b40c8a1fe

mounts: - location: "~" — 把 Mac 主目录共享进虚拟机 Mac 的 /Users/wyf 会原样出现在虚拟机的 /Users/wyf（同路径、同数据、实时同步）。所以虚拟机里能直接看到本教程的 docs 和 scripts，不用来回拷贝。 默认只读（没写 writable: true），虚拟机改不了 Mac 的文件——这是安全设计。实物证据：开机后这行配置被翻译成虚拟机 /etc/fstab 里的一条记录 lima-... /Users/wyf virtiofs ro,nofail,...（virtiofs 文件系统 + ro 只读）。附带福利：limactl shell 进虚拟机会自动 cd 到你 Mac 上当前所在的目录。

mountTypesUnsupported: [9p] — 禁用一种挂载实现目录共享有多种后端技术，9p 是老牌协议但 Rocky 9 内核支持不好。声明不支持后，Lima 改用 virtiofs（macOS 原生虚拟化框架自带，快且稳）。

networks: - vzNAT: true — 让 Mac 能直接访问虚拟机（关键）不加这行时，虚拟机只有默认的 usernet 网卡（192.168.5.x），Mac 访问不到虚拟机 IP。加了 vzNAT 后，macOS 系统框架给虚拟机第二张网卡（lima0，192.168.64.x）， Mac 浏览器可以直接访问——后续在 Mac 上访问 NodePort/Ingress 就用这个 IP：

1

limactl shell k8s-rocky hostname -I # 取 192.168.64.x 那个

等价于 Lima 的 shared 网络，但 vzNAT 不需要安装 socket_vmnet、不需要 sudo，零配置。

命令行参数与模板的关系：--cpus=4 --memory=6 --disk=30 是创建时的规格（模板里没写，也可以写进模板）；--name=k8s-rocky 给虚拟机命名； --tty=false 表示创建过程无需交互。这些只在创建时有效，之后用 limactl stop / start 开关机即可，参数已固化在 ~/.lima/k8s-rocky/ 里。

附：Lima 日常管理命令速查（都在 Mac 上执行）

命令	作用
`limactl list`	查看所有虚拟机及状态（Running/Stopped）
`limactl shell k8s-rocky`	进入虚拟机终端
`limactl shell k8s-rocky -- <命令>`	不进入虚拟机，直接在 Mac 终端执行一条虚拟机里的命令
`limactl stop k8s-rocky`	关机（虚拟机里所有配置和数据保留）
`limactl start k8s-rocky`	开机（= 重启就是 stop 再 start）
`limactl show-ssh k8s-rocky`	查看 SSH 连接方式（可用标准 ssh 命令进虚拟机）
`limactl delete k8s-rocky`	删除（卸载）虚拟机，数据全丢、不可逆，只影响 `~/.lima/k8s-rocky`，不动 Mac 任何东西

推倒重建（想从头再练一遍时）：

1
2
3
4


limactl stop k8s-rocky
limactl delete k8s-rocky
# 镜像已下载在 lima/images/，重建只需 2~3 分钟：
limactl start --name=k8s-rocky --cpus=4 --memory=6 --disk=30 --tty=false lima/rocky-9-ustc.yaml

💡 记忆法：limactl 开头的命令都在 Mac 上执行（管理虚拟机）；本文第 2 步开始的命令都在虚拟机里执行（折腾系统）。拿不准在哪，敲 hostname。

2. 切换到 root，软件源换国内镜像

后续命令都以 root 执行（kubeadm 官方文档也是如此）：

sudo -i

网络预检（30 秒钟，避免后面卡死。虚拟机出网状态会随 Mac 的网络环境变化—— 换网络、开关代理软件都可能改变它，所以环境有变化就先预检）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# ① 先清理可能残留的代理配置——代理软件关着、配置却还指向它，
# 会造成"假性网络故障"，先排除这个干扰项：
grep proxy /etc/dnf/dnf.conf
# 有输出（proxy=http://...）则删掉：
sed -i '/^proxy=/d' /etc/dnf/dnf.conf

env | grep -i proxy
# 有输出（http_proxy=... 等）则清掉：
unset http_proxy https_proxy

# ② 确认 Mac 上的代理软件状态（在 Mac 终端执行，空输出=没在运行）：
ps aux | grep -iE 'clash|verge|mihomo' | grep -v grep

# ③ 直连测试（虚拟机里执行。不用 -s：成功显示响应头，失败显示明确报错）：
curl -I -m 8 https://mirrors.ustc.edu.cn/rocky/
# 看到 HTTP/2 200 等响应头 → 直连正常，继续往下
# 看到 curl: (28) 超时等报错 → 直连出网被拦（常见于 Mac 装有企业安全软件），
# 打开 Mac 上的 Clash（需开启"允许局域网连接"），
# 然后去「附录 A.3」配好代理再回来
# 想看更详细过程时用 curl -v -m 10 <URL>，能看清卡在 DNS / TCP / TLS 哪一步

Rocky 官方源国内很慢，换成中科大镜像（真实服务器如果网络好可跳过）。

第一步永远是"先看清楚"（改配置的黄金法则：先看 → 再改 → 后验证）：

1
2


# 动手前先确认目标文件的真实格式，顺便验证待会儿 sed 的模式能不能匹配上：
grep -nE '^(metalink|mirrorlist|#?baseurl)' /etc/yum.repos.d/rocky.repo | head -6

预期输出（Rocky 9.8 的出厂状态，实测）：

1
2
3
4
5
6


13:mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever$rltype
14:#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/os/
23:mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=$basearch&repo=BaseOS-$releasever-debug$rltype
24:#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/$basearch/debug/tree/
32:mirrorlist=https://mirrors.rockylinux.org/mirrorlist?arch=source&repo=BaseOS-$releasever-source$rltype
33:#baseurl=http://dl.rockylinux.org/$contentdir/$releasever/BaseOS/source/tree/

读法：mirrorlist= 行（未注释）= 启用的官方动态源（国内慢，就是要换掉的对象）； #baseurl= 行（带 #）= 注释掉的备用地址（等下要启用并指向中科大）。每个仓库段（BaseOS / debug / source / AppStream……）都是同样两行成对出现。

💡 老版本 Rocky 显示的是 metalink= + #baseurl=https://...，格式不同。这正是换源 sed 要兼容两种格式的原因；如果将来版本又变了，以这一步看到的实际格式为准。

确认格式后执行换源（兼容新老两种格式的写法）：

1

sed -e 's|^metalink=|#metalink=|g' -e 's|^mirrorlist=|#mirrorlist=|g' -e 's|^#baseurl=https\?://dl.rockylinux.org/$contentdir|baseurl=https://mirrors.ustc.edu.cn/rocky|g' -i.bak /etc/yum.repos.d/rocky*.repo

⚠️ 三个坑都要防： ① sed 匹配不到时静默成功、不报错，必须验证（很多人栽在这里）； ② -i.bak 每次执行都会重新备份当前文件，重复执行会把"原始备份"覆盖成"改后的文件"。想稳妥留底，动手前先手动存一份：cp /etc/yum.repos.d/rocky.repo{,.orig}（还原：cp 反向拷贝）； ③ 多行命令（带 \ 续行）粘贴到终端容易断行，报 command not found / sed: can't read 时，把命令拼成单行重贴（本文给的换源 sed 就是单行版，可直接复制）。

验证（必须两项都过）：

1
2
3
4
5
6
7


grep -E '^baseurl' /etc/yum.repos.d/rocky.repo | head -3
# 必须看到输出：baseurl=https://mirrors.ustc.edu.cn/rocky/$releasever/BaseOS/$basearch/os/ 等

grep -cE '^(metalink|mirrorlist)' /etc/yum.repos.d/rocky.repo
# 必须是 0（动态源全部被注释）

dnf -y update

💡 不换源也能跑？ mirrorlist 会按你的 IP 动态分配镜像，运气好分到国内 CDN 也快—— 但那是赌手气，不可复现。换中科大 baseurl 的意义是任何时间、任何网络环境都快且稳定，后面装 containerd、kubeadm、拉镜像全是大流量下载，把不确定性压到最低。

3. 关闭 swap（必须）

为什么必须：k8s 调度器按"容器申请多少内存"做调度决策。开着 swap 时，内存不够系统会偷偷把内存页换到磁盘，kubelet 看到的内存使用量就失真了，调度决策变得不可预测——所以 kubelet 检测到 swap 开启会拒绝启动。

1
2
3
4
5


swapoff -a
# 永久关闭：注释掉 /etc/fstab 中含 swap 的行
sed -i '/swap/s/^/#/' /etc/fstab
# 验证：应输出空行
swapon --show

💡 Rocky 云镜像（GenericCloud）默认就没有 swap（/etc/fstab 里无 swap 条目、free -h 的 Swap 全 0），这两条命令对它是无害的空操作，但必须执行——真实服务器默认有 swap，习惯要养成。（k8s 1.28+ 有实验性 swap 支持，学习阶段不启用。）

4. 配置防火墙与 SELinux（学习环境简化处理）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 学习环境：直接关闭防火墙，避免端口问题干扰学习
#（Rocky 云镜像默认未安装 firewalld，报 "Unit could not be found" 属正常，跳过即可）
systemctl stop firewalld
systemctl disable firewalld

# SELinux 设为宽容模式（容器运行时需要，云镜像默认 Enforcing，必须改）
setenforce 0
sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

# 验证：应输出 Permissive
getenforce

SELinux 是什么：Linux 普通权限（rwx、属主）管的是"用户能不能访问文件"， SELinux 更进一步，在内核里给每个进程也戴上镣铐——即使是 root 进程，也只能碰安全策略允许的东西（Rocky/RHEL 系默认开启的强制访问控制）。三种模式：

模式	行为	类比
Enforcing（强制）	违规操作直接拒绝并记日志	保安：当场拦下
Permissive（宽容）	违规操作放行，只记日志	摄像头：不拦，全拍下
Disabled（关闭）	完全不工作	纪委下班

学习环境用 Permissive：containerd/k8s 的某些文件操作会被默认策略误拦， Enforcing 会导致 Pod 莫名其妙起不来；Permissive 不挡路又保留日志，事后可用 ausearch -m avc -ts recent 翻看"如果开着会拦什么"。两条命令的分工：setenforce 0 管"现在"（重启失效），/etc/selinux/config 管"重启后"。

⚠️ 生产环境不要直接关防火墙，应放行 k8s 所需端口（6443、2379-2380、10250、10259、10257 及 NodePort 30000-32767）。等学到阶段 9（NetworkPolicy）时你会理解得更深。

常见问题

Q: 换源 sed 执行后 dnf update 依然卡住？ 先跑验证命令 grep -E '^baseurl' /etc/yum.repos.d/rocky.repo | head -3。输出为空说明 sed 没匹配到（Rocky 9.8 是 mirrorlist+http://，老版本是 metalink+https://，本文第 2 步已兼容两种格式）。输出正常但 dnf 仍卡 0 字节 → 虚拟机直连出网被拦，看「附录 A」。

Q: limactl start 报 403 / 下载镜像很慢？ Rocky 官方源（dl.rockylinux.org）国内约 50KB/s；中科大镜像站的 WAF 会拦截 Lima 的多线程下载器。按第 1 步的方法：curl 单线程手动下载 + 模板指向本地文件即可，约 1~2 分钟。

Q: 重启虚拟机后这些配置还在吗？ 都在。本阶段的配置全部写入了系统文件，永久生效。（limactl stop / limactl start 就是关机/开机。）

附录 A：网络分层排查实录（虚拟机无法出网时必读）

本节是一次真实排查的完整记录：在一台装有企业安全软件（深信服/微步）+ Clash 代理的 Mac 上，虚拟机所有直连外网流量被拦截，最终通过"借 Mac 的代理出网"解决。排查方法通用。

A.1 分层排查法（自底向上，逐层缩小范围）

每层一条命令，在哪一层断，问题就在哪一层：

1
2
3
4
5
6


第1层 VM → 网关（Mac） ping -c 2 -W 3 192.168.5.2
第2层 DNS 解析 getent hosts mirrors.ustc.edu.cn
第3层 VM → 外网纯 IP ping -c 2 -W 3 223.5.5.5 # 阿里DNS，绕过域名
第4层 VM → 外网 TCP curl -k --connect-timeout 6 https://110.242.68.66/
第5层 Mac → 外网 curl -I -m 8 https://mirrors.ustc.edu.cn/rocky/ # Mac 终端执行
第6层 VM 借 Mac 代理出网 curl -x http://192.168.5.2:7897 https://mirrors.ustc.edu.cn/rocky/ -sI

实测结果与推论：

层	结果	推论
VM→网关	✅ 通	虚拟网卡正常
DNS	✅ 能解析	DNS 由 Lima 网关在 Mac 侧代答，不依赖 VM 真实出网
VM→外网 IP	❌ 100% 丢包	与域名无关，IP 层就断了
VM→外网 TCP	❌ 000 超时	同上
Mac→外网	✅ 200	Mac 网络本身没问题
VM 经 Mac 代理	✅ 200	VM↔Mac 畅通，代理可作绕行方案

结论画像：Mac 正常、VM 到 Mac 正常、VM 出网（任意目标）全断 → 问题在 Mac 系统网络层对"虚拟机转发流量"的拦截。

补充命令——虚拟机有两块网卡两条默认路由，可分别强制指定出口测试：

1
2
3
4
5


ip route # default via 192.168.64.1 (lima0, vzNAT, metric 100 优先)
 # default via 192.168.5.2 (eth0, usernet, metric 200)
curl --interface eth0 ... # 强制走 usernet 出口
curl --interface lima0 ... # 强制走 vzNAT 出口
# 两个都 000 → 不是单条链路问题，是系统级拦截

A.2 定位真凶：企业安全软件的网络扩展

先排除代理软件干扰（彻底退出 Clash Verge 并 limactl stop && limactl start 重启虚拟机，无效），再查系统扩展：

1
2
3
4
5
6


# Mac 终端执行：列出所有系统扩展
systemextensionsctl list

# 实测发现两个 activated+enabled 的企业安全组件：
# cn.threatbook.Cardinal.net-extension ← 微步在线（上网行为/威胁情报）
# com.sangfor.auem.sfservice.extension ← 深信服（终端安全/零信任）

这类安防客户端在 macOS 网络层挂内容过滤器：本机进程的流量识别放行，虚拟机 NAT 转发的流量不是"本机认证进程"发出，全部丢弃——完美对上 A.1 的现象画像。

⚠️ 这类软件不要卸载或停用（公司管理制度，可能触发告警）。正确姿势是绕行。

其他辅助排查命令（排除干扰项时用，均在 Mac 执行）：

1
2
3
4


ps aux | grep -iE 'clash|verge|mihomo' | grep -v grep # 确认代理软件进程是否退干净
networksetup -getwebproxy Wi-Fi # 看系统代理开关状态
netstat -rn -f inet | head -8 # 看默认路由是否被 VPN/TUN 劫持
/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate # macOS 应用防火墙状态

A.3 解决方案：虚拟机借 Mac 的代理出网

前提：Clash Verge 运行中，且开启"允许局域网连接"（Allow LAN）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 虚拟机里，root 执行：

# dnf 走代理（dnf 不读环境变量，必须写配置；永久生效）
echo 'proxy=http://192.168.5.2:7897' >> /etc/dnf/dnf.conf

# curl 等命令行工具走代理（仅当前终端有效）
export http_proxy=http://192.168.5.2:7897
export https_proxy=http://192.168.5.2:7897

# 验证 → 显示响应头即通
curl -I -m 8 https://mirrors.ustc.edu.cn/rocky/

containerd 的代理配置是 systemd drop-in（它是不读环境变量的系统服务），见阶段 0（下）第 6 步。

⚠️ 代理方案的善后（重要）：哪天直连恢复了、或者你把 Clash 关了，这些代理配置会让 dnf/curl/containerd 全部连不上（指向一个不存在的代理）。恢复直连前必须清理：
1
2
3
4
5
sed -i '/^proxy=/d' /etc/dnf/dnf.conf # 删 dnf 代理配置
unset http_proxy https_proxy # 清当前终端的代理变量
# 如果配过 containerd 代理，也要一并删掉：
rm -f /etc/systemd/system/containerd.service.d/proxy.conf
systemctl daemon-reload && systemctl restart containerd
一句话：代理配置和代理软件必须同开同关。这正是第 2 步「网络预检」第 ① 小步存在的原因。

为什么 192.168.5.2 可以写死在配置里：它是 Lima 源码内置的 usernet 网关常量（不经过任何配置文件），语义是"Mac 本机"。虚拟机重启、Mac 重启、换 Wi-Fi、去公司都不会变。同理稳定：虚拟机 eth0 的 192.168.5.15（按虚拟机 MAC 固定分配）、lima0 的 192.168.64.2。

A.4 Lima 网络拓扑速查

1
2
3
4
5
6
7
8


┌─ 物理网（家里/公司 Wi-Fi，Mac 的 en0）—— 这层会随地点变
│
├─ Lima usernet（192.168.5.0/24，Lima 内置默认，无需配置）
│ 虚拟机 eth0 = 192.168.5.15，网关/DNS = 192.168.5.2（= Mac）
│
└─ macOS vzNAT（192.168.64.0/24，模板里 vzNAT: true 开启）
 虚拟机 lima0 = 192.168.64.2，网关 = 192.168.64.1（= Mac）
 ← Mac 浏览器访问 NodePort/Ingress 用这个 IP

1
2
3
4
5
6
7
8
9


# 区分"我在 Mac 还是虚拟机里"：看提示符或问 hostname
# wyf@MacBook-Pro % → Mac（zsh，%）
# [wyf@lima-k8s-rocky ~]$ → 虚拟机普通用户
# [root@lima-k8s-rocky ~]# → 虚拟机 root
hostname # lima-k8s-rocky = 虚拟机

# Mac 上 Lima 的可选网络定义（shared/bridged/host，本教程未使用）：
cat ~/.lima/_config/networks.yaml
# 注意：里面没有 192.168.5.x —— usernet 网段是编译进 Lima 源码的出厂默认值

目录挂载的实物证据：模板里 mounts: - location: "~" 开机后变成虚拟机 /etc/fstab 里的一行 lima-... /Users/wyf virtiofs ro,nofail,...（virtiofs 共享文件系统，ro 只读），这就是虚拟机里能直接看到 Mac 主目录的原因。

A.5 排查命令总表

命令	用途	执行位置
`ip route`	看默认路由/网卡/优先级	VM
`hostname -I`	看虚拟机所有 IP	VM
`ping -c 2 -W 3 <IP>`	测某层连通性	VM
`getent hosts <域名>`	测 DNS 解析	VM
`curl -I -m 8 <URL>`	测 HTTP 通不通	VM/Mac
`curl --interface eth0 <URL>`	强制指定网卡出口	VM
`curl -x http://192.168.5.2:7897 <URL>`	经 Mac 代理测试	VM
`systemextensionsctl list`	查系统网络/安全扩展	Mac
`networksetup -getwebproxy Wi-Fi`	查系统代理	Mac
`netstat -rn -f inet`	查 Mac 路由表是否被劫持	Mac
`ps aux \| grep -iE 'clash\|verge'`	确认代理进程状态	Mac
`limactl list` / `limactl shell <名字>`	查看/进入虚拟机	Mac
`cat ~/.lima/_config/networks.yaml`	看 Lima 可选网络定义	Mac

动手练习

用 limactl shell k8s-rocky 以外的另一种方式进入 VM（提示：Lima 自动配置了 SSH，ssh 加端口和密钥，用 limactl show-ssh k8s-rocky 查看）。
用附录 A 的分层排查法，在虚拟机里依次执行第 1/2/5 层的命令，确认每层的输出你都看得懂。

下一步

➡️ 阶段 0（下）：内核参数与容器运行时