kubeadm init不能仅靠--pod-network-cidr指定网段，必须通过配置文件显式定义networking.podsubnet和servicesubnet，且需与所选cni插件（如calico、flannel）的配置严格一致，否则导致网络插件初始化失败或集群异常。
不能直接在 kubeadm init 命令行里指定 Pod 或 Service 网段，必须通过配置文件传入 podSubnet 和 serviceSubnet —— 否则默认用 10.96.0.0/12（Service）和 10.244.0.0/16（Flannel 默认），但这两个值不通用，且与 Calico、Cilium 等 CNI 插件的期望常有冲突。
networking 字段必须显式写进 ClusterConfiguration
很多人误以为加个 --pod-network-cidr 参数就够了，其实从 kubeadm v1.19+ 开始，该参数仅用于向 kube-controller-manager 透传，**不会影响 etcd 中存储的集群网络配置**，也不被 CNI 插件读取。真正起效的是配置文件中 networking 下的字段：
-
podSubnet：供 CNI 插件（如 Calico、Flannel）初始化时对齐 IPAM，必须和你后续部署的 CNI 配置一致 -
serviceSubnet：决定 ClusterIP 分配范围，修改后会影响所有 Service 的 VIP 地址空间 -
dnsDomain：通常保持cluster.local，改了需同步更新 CoreDNS ConfigMap
示例片段（kubeadm-config.yaml）：
networking: podSubnet: 172.16.0.0/12 serviceSubnet: 10.103.0.0/16 dnsDomain: cluster.local
注意：podSubnet 值必须和你选用的 CNI 插件 YAML 中的 cidr 或 ipam.subnet 完全一致，否则节点上 calico-node 或 flanneld 启动失败，报错类似 failed to configure default pool: invalid CIDR。
不同 CNI 对 podSubnet 的解析逻辑差异很大
不是所有 CNI 都无条件信任 kubeadm 配置里的 podSubnet，它们加载方式不同：
-
Flannel：只认自己 YAML 里的net-conf.json中的Network字段，kubeadm的podSubnet仅作校验，不覆盖 -
Calico：会读取kubeadm配置生成installationCR，自动注入spec.calicoNetwork.ipPools[0].cidr，前提是使用官方 manifest（如tigera-operator） -
Cilium：完全忽略kubeadm的podSubnet，必须在 Helm values 或 CiliumClusterwideNetworkPolicy 中显式设ipam.mode=cluster-pool+clusterPoolIPv4CIDR
所以别指望写一次 podSubnet 就全局生效。部署前务必查清你选的 CNI 文档里“如何指定 Pod 网段”那一节，再反推 kubeadm 配置要不要写、怎么写。
kubeadm init 失败后改 subnet 不能只改配置文件
如果 kubeadm init 已执行过但失败（比如因网段冲突卡在 etcd 启动），不能简单改完配置重跑 —— 因为 /etc/kubernetes/manifests/etcd.yaml 里已经固化了初始 --advertise-client-urls 和数据目录，且 etcd 数据库中存有旧的 network config。
- 必须先运行
kubeadm reset -f清理残留（包括/var/lib/etcd） - 确认
swapoff -a、iptables -P FORWARD ACCEPT等前置项仍有效（重置后可能恢复） - 若之前手动改过
/etc/cni/net.d/下的配置，要一并删掉，否则 CNI 初始化时会跳过自动生成逻辑
常见症状：节点 Ready 但 kubectl get nodes 显示 NotReady，kubectl describe node 报 NetworkPluginNotReady: cni plugin not initialized，大概率是 CNI 配置和 kubeadm 声明的网段对不上，或 etcd 里残留旧状态。
最易被忽略的一点：kubeadm 不验证 podSubnet 和 serviceSubnet 是否重叠。如果你填了 podSubnet: 10.0.0.0/8 和 serviceSubnet: 10.96.0.0/12，它们实际包含关系，Kubernetes 不报错，但 CoreDNS、kube-proxy 的 iptables 规则会混乱，导致 DNS 解析失败或 ClusterIP 访问异常。务必人工校验两个 CIDR 无交集。
