子网划分是云原生容器网络的底层骨架，决定pod跨节点通信、service负载分发及集群与vpc/宿主机网络是否冲突；必须满足三硬约束：pod cidr不得与节点子网重叠、service cidr须独立且不可路由、cni插件依赖cidr粒度分配主机位；仅支持cidr格式（如10.244.0.0/16），因其明确前缀长度，适配kubernetes、docker compose等系统参数与bgp路由聚合需求；掩码长度直接影响规模与性能，/24适用于小集群，/22平衡中型部署，/16适配超大规模，但/31、/32非法，/30易致资源挤占；常见故障如跨节点不通、pod pending、dns解析失败，多源于子网重叠、路由未通告或cidr耗尽。
子网划分在云原生容器网络中不是简单地“分IP段”，而是支撑整个网络可扩展性、隔离性和可达性的底层骨架。它直接决定Pod能否跨节点通信、Service如何做负载分发、集群是否与宿主机或VPC网络冲突。
子网划分必须满足三个硬约束
云原生环境（如Kubernetes、CCE、Docker Swarm）对子网的使用有明确且不可绕过的边界规则：
- 容器网段（Pod CIDR）不能和节点所在子网重叠：例如节点部署在 192.168.10.0/24，那 Pod 网段就不能选 192.168.10.0/25 或任何包含该范围的地址块，否则路由会混淆，导致部分Pod无法被访问。
- 服务网段（Service CIDR）必须独立且不可路由到外部：通常用 10.96.0.0/12 这类私有大网段，仅在集群内生效。它不占用物理网络资源，但需确保不与任何已存在的VPC、Docker默认桥接网段（如172.17.0.0/16）重复，否则 kube-proxy 的 iptables/IPVS 规则会失效。
- CNI插件依赖子网粒度分配主机位：比如 Calico 按节点分配 /26 子网（64个IP），每个节点最多运行62个Pod；Flannel 使用 host-gw 模式时，则要求所有节点的子网互不重叠且能被底层路由识别——这意味着子网掩码长度必须统一，且网络地址必须是2的幂次对齐（如 .0/.64/.128/.192）。
为什么CIDR是云原生子网的唯一表达方式
传统A/B/C类地址划分在容器场景下完全失效。云原生系统只认CIDR（如 10.244.0.0/16），因为：
- 它明确标出网络前缀长度，CNI插件据此自动计算可用主机数、广播地址、网络地址，无需解析掩码十进制值；
- Kubernetes的 --pod-cidr 参数、Docker Compose的 subnet 字段、CCE集群创建页的“容器网段”输入框，全部只接受 x.x.x.x/y 格式；
- 当使用BGP或eBGP对接物理网络时（如Calico + MetalLB），路由宣告必须基于CIDR聚合，/24以下的子网可被汇总，/26以上的细分子网则可能被上游路由器过滤掉。
子网掩码长度直接影响容器规模与网络性能
选错掩码长度，轻则浪费IP，重则触发内核连接跟踪耗尽或ARP风暴：
- /24：适合小集群（≤254 Pod/节点），但若节点数超10个，总Pod上限很快见顶；
- /22（1024 IP）：平衡选择，常见于中型K8s集群，单节点分得 /26 后仍留扩展余量；
- /16：适用于超大规模集群（如万级Pod），但要求底层网络支持大二层或启用三层路由，否则ARP表暴涨、广播泛滥；
- 特别注意：/32 或 /31 在容器网段中非法——没有主机位，无法分配给Pod；/30 只剩2个可用IP，连CNI自身健康检查端点都可能挤占。
真实故障场景中的子网逻辑还原
很多“Pod无法访问Service”或“跨节点Ping不通”的问题，根源都在子网配置失配：
- 现象：Pod能通自己节点上的其他Pod，但ping不通其他节点的Pod；检查发现各节点分配的Pod子网为 10.244.1.0/24 和 10.244.2.0/24，但底层VPC路由表未添加这两条指向对应节点的静态路由 → 缺少underlay层子网通告；
- 现象：kubectl get nodes 显示Ready，但所有Pod处于Pending；查kube-controller-manager日志，报错 failed to allocate pod CIDR for node: CIDR not available → 集群初始化时指定的 --cluster-cidr 太小，已被分配完；
- 现象：Docker Compose服务间DNS解析失败；检查 docker network inspect app-net，发现 subnet 是 172.20.0.0/16，而宿主机网卡恰巧也用了 172.20.10.100 → 宿主与容器网络路由冲突，流量被本地接口截断。
