如何修改GKE集群的CIDR子网而无需新建集群迁移工作负载

不存在完全原地修改集群CIDR、完全无业务感知的方案，但有不需要新建集群、不需要手动迁移Pod的可落地方案，可根据实际需求选择。

如果核心诉求仅为实现两个冲突VPC下的GKE集群互通，不需要调整集群原有子网配置，可通过NAT地址转换的方式绕开CIDR冲突问题，现有集群内的Pod、Secret、Deployment等所有资源完全无需调整，业务无感知：

• 为两个VPC分别规划一段互不冲突的中转CIDR段，例如两个原有VPC的CIDR均为10.0.0.0/16，可给VPC A分配172.16.0.0/16、VPC B分配172.17.0.0/16作为中转地址段
• 分别为两个VPC配置Cloud NAT规则，将原有内部CIDR的出站流量转换为对应中转CIDR段的地址，同时配置入站反向转换规则
• 建立VPC peering时，仅向对端宣告中转CIDR段，不宣告原有冲突的CIDR段，避免触发CIDR冲突报错
• 配置对应防火墙规则，放行两个中转CIDR段之间的访问流量即可完成互通

如果确实需要修改其中一个集群的子网CIDR，也不需要销毁重建整个集群，不需要手动迁移Pod，仅需要滚动替换集群节点，操作如下：

注意：该方案会触发节点滚动重启，存在秒级的业务闪断，建议在业务低峰期操作

1. 在需要修改CIDR的集群所属VPC下，新建一段和对端VPC无冲突的新子网，如果集群用VPC原生网络，还要同步在新子网下添加无冲突的Pod、Service Secondary IP范围
2. 执行命令更新集群节点池的子网配置：
   gcloud container node-pools update [节点池名称] --cluster [集群名称] --zone [可用区] --subnetwork [新子网名称]
3. GKE会自动按照节点池的滚动升级策略，逐个替换现有节点，将节点迁移到新子网下，节点上运行的Pod会被Kubernetes自动调度到新节点启动，无需手动迁移Pod，Secret、Deployment等配置资源会完全保留
4. 所有节点替换完成后，验证集群内所有资源运行正常、访问无异常，即可删除原有冲突的旧子网

内容的提问来源于stack exchange，提问作者EMG