CentOS7 + VMware 搭建 K3s 集群遇到的网络问题全记录与解决方案
一、实验环境
- 虚拟化平台：VMware Workstation
- 系统版本：CentOS 7 (Core)
- 网络模式：VMware NAT
- 集群组成：
hadoop100：Master 节点hadoop101：Worker 节点hadoop102：Worker 节点（问题节点）
三台虚拟机均使用静态 IP：
192.168.10.100 master
192.168.10.101 worker1
192.168.10.102 worker2
网关：192.168.10.2
二、问题现象
-
在搭建 K3s 时，
hadoop102节点无法解析域名：ping rancher-mirror.cn ping: rancher-mirror.cn: Name or service not known但可以 ping 外网 IP：
ping 8.8.8.8 正常 -
查看 NetworkManager：
systemctl status NetworkManager Active: inactive (dead)→ 使用的是传统
network服务。 -
DNS 配置：
/etc/sysconfig/network-scripts/ifcfg-ens33 BOOTPROTO=static IPADDR=192.168.10.102 GATEWAY=192.168.10.2 DNS1=223.5.5.5 DNS2=114.114.114.114即便修改
/etc/resolv.conf，依旧无法解析域名。 -
dig 命令测试：
dig rancher-mirror.cn @223.5.5.5 ;; status: NXDOMAIN→ 域名确实不存在，但后来对任何域名都超时，说明 DNS 链路异常。
三、排查思路
1️⃣ 确认域名状态
rancher-mirror.cn 已经下线（返回 NXDOMAIN）。
安装脚本应改为：
curl -sfL https://get.k3s.io | INSTALL_K3S_MIRROR=cn sh -
或使用阿里云镜像：
curl -sfL https://rancher-mirror.oss-cn-beijing.aliyuncs.com/k3s/k3s-install.sh | sh -
2️⃣ 确认网络正常
ping 8.8.8.8 正常 → 网络没问题。
3️⃣ 确认 DNS 配置生效
cat /etc/resolv.conf 能看到正确的 nameserver；
但 dig aliyun.com @223.5.5.5 超时，说明 DNS 请求根本发不出去。
4️⃣ VMware NAT 网络排查
VMware NAT 模式下，所有虚拟机的 DNS 请求都通过宿主机的
“VMware NAT Service” 转发。
如果该服务异常，虚拟机就能上网但无法解析域名。
验证：
dig aliyun.com @192.168.10.2
;; connection timed out
→ 说明 NAT DNS 转发彻底失效。
四、最终发现问题根因
VMware NAT Service 与 DHCP Service 异常，导致虚拟机无法通过宿主机 NAT
转发 DNS 请求（UDP 53/TCP 53 均超时）。
五、解决步骤
✅ 1. 重启 VMware NAT 与 DHCP 服务
在宿主机上执行（Windows）：
net stop "VMware NAT Service"
net start "VMware NAT Service"
net stop "VMware DHCP Service"
net start "VMware DHCP Service"
或在"服务 (services.msc)"中手动重启这两个服务。
重启后立刻测试：
dig aliyun.com @223.5.5.5
输出正常（返回 IP），说明 DNS 功能恢复。
✅ 2. 重启 k3s-agent
在 hadoop102 上：
sudo systemctl restart k3s-agent
✅ 3. 删除卡住的 Pod，让它重新创建
在主节点 hadoop100 上：
sudo k3s kubectl -n kube-system delete pod svclb-traefik-de235f4a-z9hqt
✅ 4. 验证恢复结果
sudo k3s kubectl -n kube-system get pods -o wide | egrep 'flannel|traefik|svclb'
输出：
svclb-traefik-de235f4a-4lfbh 2/2 Running 0 15s 10.42.2.209 hadoop102
→ 表示 DNS、镜像拉取、flannel 网络全部恢复正常。
六、问题扩展与原因分析
| 原因 | 解释 |
|---|---|
| NAT 服务异常 | 负责转发虚拟机 DNS、HTTP、HTTPS 流量；失效后 UDP 53 不通 |
| 仅 102 出问题 | VMware NAT 为每个 VM 维护独立 NAT 表，有可能某台 VM 缓存异常 |
| 静态 IP 配置 | 没走 DHCP，未自动获取 NAT 提供的 DNS 地址 |
| 表面能上网但解析失败 | 因为 NAT 只转发部分端口（80/443），53 被阻断 |
七、替代方案：桥接模式（推荐长期使用）
如果不想依赖 VMware NAT，可以直接把虚拟机改成 桥接 (Bridged) 模式：
节点 IP 网关 DNS
hadoop100 192.168.1.100 192.168.1.1 192.168.1.1
hadoop101 192.168.1.101 192.168.1.1 192.168.1.1
hadoop102 192.168.1.102 192.168.1.1 192.168.1.1
这样虚拟机使用真实局域网 DNS，不再受 VMware NAT 影响。
八、验证结果
最终集群状态：
sudo k3s kubectl get nodes -o wide
输出：
NAME STATUS ROLES AGE VERSION INTERNAL-IP
hadoop100 Ready control-plane,master 4d v1.33.5+k3s1 192.168.10.100
hadoop101 Ready <none> 3d v1.33.5+k3s1 192.168.10.101
hadoop102 Ready <none> 1d v1.33.5+k3s1 192.168.10.102
九、总结经验
| 问题 | 原因 | 解决方案 |
|---|---|---|
| ping 域名失败但 ping IP 正常 | DNS 无法解析 | 检查 resolv.conf / NAT 服务 |
| rancher-mirror.cn NXDOMAIN | 官方域名已失效 | 改用 https://get.k3s.io |
| svclb-traefik 卡在 ContainerCreating | flannel 未启动 / 镜像拉取失败 | 修复 DNS 或配置国内镜像 |
| dig 超时 | VMware NAT 转发挂 | 重启 VMware NAT & DHCP 服务 |
| 节点无法解析但其他正常 (错误码 102) | 单节点 NAT 状态损坏 | 重启 NAT 服务或改桥接模式 |
🔧 十、最佳实践建议
-
开启 VMware NAT/DHCP 自动启动
sc config "VMware NAT Service" start= auto sc config "VMware DHCP Service" start= auto -
保留国内镜像源 在
/etc/rancher/k3s/registries.yaml配置：mirrors:"docker.io":endpoint:- "https://docker.m.daocloud.io"- "https://dockerpull.com"- "https://registry-1.docker.io" -
时间同步
sudo yum -y install ntpdate sudo ntpdate ntp.aliyun.com -
查看系统日志
sudo journalctl -u k3s-agent -n 100
✅ 十一、最终结论
问题根因： VMware NAT DNS 转发异常，导致静态 IP
虚拟机无法解析外网域名。
核心解决方案： 重启 VMware NAT/DHCP 服务 或 改用桥接模式。
最终结果： 所有节点恢复正常，K3s 集群完全健康。