我们在异地或国际化数据中心（如香港机房）部署 Kubernetes 集群时，常常遭遇各种“非预期性失败”。本文将以“节点初始化中的网络隔离问题”为切入点，结合实操经验，深入分析问题根源并提供系统性解决方案，帮助技术团队快速定位和修复部署失败的问题。
跨国企业计划在香港某 Tier III+ 等级的数据中心内部署基于裸金属服务器的 Kubernetes 高可用集群。项目环境初期采用如下配置：
- Kubernetes 版本：v1.29.1
- 操作系统：Ubuntu Server 22.04 LTS
- 集群规模：3 Master + 5 Worker
- 网络组件：Cilium v1.15（基于 eBPF 架构）
- 容器运行时：containerd v1.7
硬件配置：
- CPU：Intel Xeon Gold 6326
- 内存：128GB ECC DDR4
- 网络：2 × 10Gbps SFP+，支持 VLAN Tagging
部署过程中，使用 kubeadm 初始化控制平面节点，但在执行 kubeadm init 后，发现节点长时间处于 NotReady 状态。通过 kubectl get nodes 查看状态如下：
NAME STATUS ROLES AGE VERSION
master-1 NotReady control-plane 5m27s v1.29.1
进一步查看 kubelet 日志和 cilium pod 状态，发现如下错误：
Warning FailedCreatePodSandBox kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up network for sandbox
深入分析：网络隔离的根源
部署 Kubernetes 节点初期，网络插件是初始化过程中的核心部分。以 Cilium 为例，它需要保证以下几项网络条件：
- 控制平面节点与 Worker 节点的互通（UDP 8472 / VXLAN）
- 各节点之间的 MTU 一致性
- Kube-Proxy 的 kube-system DNS 能正常解析
- Pod CIDR 与宿主机网段无冲突
- 主机防火墙未阻断关键端口
问题定位关键点：
宿主机网络隔离策略未透明化： 香港数据中心通常对跨机架流量采用 VLAN 隔离，并使用 ACL 策略控制南北向/东西向流量。此时如果 VXLAN 封包未被允许跨 VLAN 通信，Pod 网络将无法初始化。
节点间 MTU 值不一致： 如果交换机配置了 VLAN Tagging (例如 IEEE 802.1Q)，则实际可用 MTU 需要手动下调至 1450 或更低，否则 Cilium VXLAN 包将出现碎片，导致 kubelet sandbox 初始化失败。
Cilium 使用 IPAM ENI 模式或 overlay 模式时要求宿主机间可直连： 香港部分 IDC 存在默认安全组策略限制东西向 VXLAN 的 8472 端口。
解决方案与实操建议
1. 明确网络架构与 VLAN 策略
首先与 IDC 网络团队确认以下关键点：
- 各机架之间是否存在隔离（VLAN ID 是否一致）
- 是否开启了 L2-L3 ACL 策略（限制 UDP 8472、ICMP、DNS）
- 对内网 VXLAN 是否支持广播和泛洪
建议配置：
- 所有 Kubernetes 节点应配置在统一 VLAN 内
- 若使用 overlay 网络（如 VXLAN），需允许 UDP 8472 跨节点通讯
- 开启节点之间的 ICMP 流量（便于网络可达性测试）
2. 设置一致的 MTU 值
在所有节点 /etc/systemd/network/*.network 文件中，明确设置 MTU：
[Match]
Name=ens*
[Network]
DHCP=yes
[Link]
MTUBytes=1450
重启网络服务后，通过以下命令确认 MTU 设置生效：
ip link | grep mtu
3. 禁用默认防火墙限制
部分香港机房默认安装 ufw 或使用硬件防火墙策略。建议禁用宿主机 ufw 并确认 iptables 策略清空：
sudo systemctl stop ufw
sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
若需长期维护防火墙策略，建议配置为允许以下端口：
- TCP 6443（K8s API Server）
- TCP 2379-2380（etcd 通信）
- UDP 8472（VXLAN）
- TCP 10250（kubelet）
- TCP/UDP 53（DNS）
4. 手动初始化 Pod 网络插件
建议手动部署 Cilium，而非依赖 kubeadm 自动注入。示例如下：
cilium install --version 1.15.0 \
--cluster-name hk-cluster \
--cluster-id 1 \
--ipv4-native-routing-cidr=10.42.0.0/16 \
--node-port \
--kube-proxy-replacement=strict \
--operator-replicas=2
部署后执行健康检查：
cilium status
5. 监控节点日志与事件
及时查看 kubelet 和 cilium 的事件与日志是解决此类问题的关键：
journalctl -u kubelet -f
kubectl -n kube-system logs -l k8s-app=cilium
部署验证与实践经验
✅ 网络连通性验证脚本
#!/bin/bash
for node in $(kubectl get nodes -o name); do
echo "Checking $node"
kubectl debug $node --image=busybox -- chroot /host ping -c 2 10.42.0.1
done
✅ 节点检查清单（Checklist）
- 所有节点 MTU 设置一致（建议 1450）
- UDP 8472 端口在节点间可达
- cilium status 全绿无报错
- kubelet 日志无 “sandbox create failed” 报错
- Pod 能正常调度、跨节点 ping 通
Kubernetes的部署过程中，网络初始化是最容易被忽略却最关键的部分。特别是在香港机房或其他海外数据中心，由于其网络环境存在异构、安全策略收紧、硬件设备品牌多样等复杂因素，部署失败风险更高。希望通过本篇文章，从实操角度帮助运维工程师厘清网络隔离问题背后的根本原因，提升 Kubernetes 多地域部署的稳定性与效率。
