K3s中Flannel CNI无法分配Pod IP的核心原因是子网耗尽或本地子网状态异常，表现为节点子网未释放、ARP缓存污染或IP池用尽，可通过检查configmap、清理残留、调整CIDR等手段快速恢复。
这是 K3s 中非常典型的，本质是 CNI（通常是 Flannel）无法为新 Pod 分配 IP 地址，常见于集群运行一段时间后、节点重启后、或大规模部署 Pod 时。核心原因不是“没 IP”，而是 IP 地址池已用尽 或 本地分配状态异常。
检查 Flannel 子网分配是否耗尽
K3s 默认使用 Flannel，每个节点从集群 CIDR（如 10.42.0.0/16）中分配一个 /24 子网（即 256 个 IP），用于该节点上所有 Pod。一旦节点数达到 256 个，子网就用完了；但更常见的是：某节点的子网被反复申请却未释放（比如节点异常离线后未清理）。
- 查看当前子网分配情况：kubectl get s -o wide 看各节点 IP，再查 Flannel 配置：kubectl -n kube-system get cm kube-flannel-cfg -o yaml | grep -A 5 “Network\|SubnetLen”
- 直接检查 Flannel 的子网租约：kubectl -n kube-system get configmap -l tier=node —— 正常应有与节点数一致的 configmap（如
coreos.com/flannel/subnets/node-192.168.1.10）；缺失或重复意味着分配异常 - 若发现某节点 configmap 存在但节点已下线，手动删除它：kubectl -n kube-system delete cm coreos.com/flannel/subnets/node-xxx，Flannel 会在节点重连时重新分配
确认节点本地子网是否被占满
单个节点的 /24 子网最多支持 253 个活跃 Pod（去掉 .0/.1/.255）。如果该节点长期运行大量短生命周期 Pod（如 Job、CronJob），可能因 iptables 规则残留、cni0 网桥 ARP 表堆积或容器运行时未彻底清理，导致可用 IP 实际减少。
Replit最新推出的AI编程工具，可以帮助用户从零开始自动构建应用程序。
- 登录问题节点，查看 cni0 网桥 IP 分配：ip addr show cni0，确认其 inet 是类似
10.42.x.1/24，说明子网已加载 - 检查已分配的 Pod IP：kubectl get pods -o wide –field-selector spec.nodeName=NODE_NAME，统计数量；再对比 arp -n -i cni0 | wc -l，若远大于 Pod 数，说明 ARP 缓存污染
- 临时清理（谨慎）：ip neigh flush dev cni0，并重启 flanneld：sudo systemctl restart k3s-agent（或 k3s-server）
调整 CIDR 或子网大小（预防性措施）
默认 10.42.0.0/16 + /24 每节点，最多支撑 256 节点 × 253 Pod ≈ 64K Pod。若规划超量，需提前调整。
- 扩大集群 CIDR：启动 K3s 时加参数 –cluster-cidr 10.42.0.0/12（支持 4096 个 /24 子网），同时确保 Flannel 配置中
SubnetLen: 24不变 - 减小子网（不推荐）：设
SubnetLen: 26可支持更多节点（1024），但每节点仅 61 个 Pod，适合轻量节点场景 - 修改方式：编辑 /var/lib/rancher/k3s/server/manifests/kube-flannel.yml（或通过 Helm chart 覆盖），更新 ConfigMap 中的 NetConf，然后重启 k3s
验证和快速恢复
多数情况下，问题可快速缓解，无需重建集群。
- 先尝试重启问题节点上的 k3s 服务：sudo systemctl restart k3s（server）或 sudo systemctl restart k3s-agent（agent）
- 观察日志：sudo journalctl -u k3s -n 100 -f | grep -i “flannel\|ipam\|fled to allocate”
- 确认新 Pod 是否能正常获取 IP：kubectl run test-pod –image=busybox:1.35 — sleep 3600，再 kubectl get pod -o wide
