云原生场景下的 VPC 网络规划：从能用到可扩展、可治理、可演进¶

写在前面¶

很多团队第一次上云做 Kubernetes、微服务、数据库和中间件平台时，最容易低估的一件事，就是 VPC 网络规划。

一开始大家通常会觉得这件事很简单：

先建一个 VPC
划几个交换机或子网
把 Kubernetes 集群和数据库放进去
能通信就算完成

但真正跑起来几个月后，问题就会集中爆发：

新业务上不去，因为网段不够了
多环境互联复杂，路由开始打架
Pod 网段和 VPC 网段冲突
安全域不清晰，谁都能访问谁
NAT、LB、VPN、专线、云企业网越堆越乱
后面想做多集群、多地域、混合云时，发现最早的网段规划已经卡死

从云原生专家的视角看，VPC 规划 从来不是“画几个网段”这么简单，它本质上是在回答：

未来 2 到 3 年，这个平台的网络边界、扩展方式、安全分区、环境隔离和互联模型到底怎么设计。

这篇文章的重点不是教你点控制台，而是从架构设计视角回答下面几个问题：

云原生场景下，VPC 规划到底要规划什么
为什么很多团队的网络设计一开始就埋雷
Kubernetes、数据库、中间件、办公接入、跨地域互联应该怎么拆
怎么做一套能扩展、能治理、能持续演进的 VPC 规划

本文默认讨论的是公有云 VPC + Kubernetes/ACK 这类云原生平台场景。不同云厂商、不同 CNI、不同实例规格对可用 IP、弹性网卡、Pod 密度和路由能力的限制不同，落地时要以云厂商文档和当前集群网络模式为准。

一、先说结论：VPC 规划的核心不是“能通”，而是“有边界”¶

很多早期网络设计的最大问题，不是技术实现错了，而是设计目标太低，只盯着：

服务能不能访问数据库
ECS 能不能访问公网
Kubernetes 能不能拉镜像

如果目标只有“先通”，最后往往会得到一张看似能跑，但很难治理的网络。

在云原生场景下，一套合理的 VPC 网络规划，至少要同时满足这几个目标：

可扩展 含义：新业务、新环境、新集群、新网段能继续加
可隔离 含义：生产、测试、办公、外联、平台组件边界清晰
可互联 含义：多 VPC、多地域、混合云、IDC 上云时可持续演进
可治理 含义：访问控制、流量路径、出口策略、审计边界明确
可运维 含义：排障时能够快速判断问题是在路由、ACL、安全组、NAT 还是代理层

所以更准确地说：

云原生里的 VPC 规划，本质上是在做“平台网络分层设计”。

二、云原生场景里，VPC 规划到底要规划哪些东西¶

1. 地址空间规划¶

这是最底层也是最容易做错的一层。

你至少要先回答：

整体 VPC 用多大网段
各环境如何分段
各子网/交换机如何分段
Kubernetes Pod 网段是否独立
Service 网段如何选
是否预留未来扩容空间

如果你一开始随手用了一个小网段，例如：

VPC: 10.0.0.0/24

那么你后面很快就会遇到这些问题：

子网数量不够拆
节点数量扩不起来
Pod 地址规划被迫挤在同一个段里
和 IDC、办公网、其他云网段冲突

在云原生平台里，地址空间规划最好遵循两个原则：

一开始就按“未来规模”留足空间
网段切分要体现环境边界和系统角色，而不是只按“今天有几台机器”来切

2. 环境隔离规划¶

云原生平台最少会有这些环境：

生产
预发
测试
开发
平台公共组件

一个常见错误是把所有环境都堆进同一个 VPC，只靠命名区分。

短期看省资源，长期看会带来：

路由和安全策略难管理
测试环境误访问生产
灰度流量、压测流量影响生产
网络问题定位边界模糊

更合理的思路通常是：

高隔离要求环境拆 VPC
同一环境内部再拆子网/交换机

例如：

prod-vpc
pre-vpc
test-vpc
shared-services-vpc

这样做的好处是：

路由边界清晰
安全控制更自然
后续接云企业网/专线/VPN 更清楚
故障域更可控

3. 业务分层规划¶

在云原生场景里，网络不应该只按“机器类型”拆，更应该按“访问边界”拆。

一个典型业务分层可以这样看：

接入层含义：SLB、Ingress、反向代理、API Gateway
计算层含义：Kubernetes Node、ECS、工作负载
数据层含义：MySQL、Redis、Kafka、Elasticsearch
管理层含义：堡垒机、运维平台、监控、CI/CD、镜像仓库
出口层含义：NAT Gateway、EIP、边界防火墙

这些层并不一定都必须物理隔离到不同 VPC，但至少应该有逻辑边界。

一个常见的反例¶

如果你把下面这些东西全放在一个可互通子网里：

Kubernetes Node
MySQL
堡垒机
Jenkins
Kafka
Nginx

那么后续会出现：

安全策略全靠人记
很难定义最小访问权限
某个节点被打穿后横向移动成本很低

三、为什么 Kubernetes 会放大 VPC 规划问题¶

在传统单体应用时代，很多人对网络规划的感知没有那么强。

因为以前通常是：

几台 ECS
一套数据库
一层 Nginx

而 Kubernetes 会把网络问题放大，原因在于它天然引入了更多层次：

Node 网络
Pod 网络
Service 网络
Ingress 入口
集群间互联
CNI 插件行为

1. Pod 网段规划不能拍脑袋¶

很多团队第一次上 K8s 时，只知道“Pod 需要网段”，但不知道这件事会影响多大。

如果 Pod 网段设计得不好，后续可能会出现：

与 VPC 内已有网段冲突
与 IDC 网段冲突
与另一套集群冲突
跨集群互联困难

所以在做 VPC 规划时，必须一起规划：

VPC 网段
Node 所在子网
Pod CIDR
Service CIDR

经验建议¶

Pod CIDR 尽量使用独立网段
Service CIDR 不要与任何真实网络重叠
多集群场景下，不同集群 Pod CIDR 不要重复

2. 不要把 Kubernetes 当成“只是多几台虚拟机”¶

Kubernetes 集群不是简单的主机池，它是平台入口。

你需要提前考虑：

未来是否多集群
是否跨可用区
是否需要独立集群承载不同环境
是否要接入服务网格
是否要做多地域容灾

如果你一开始把网络做得太紧，后面这些能力几乎都得重构。

3. 一个更贴近生产的案例：阿里云 ACK + Terway 网络插件¶

如果你的 Kubernetes 跑在阿里云 ACK 上，而且使用的是 Terway 网络插件，那么 VPC 规划就不能再按“节点够不够用”这么简单来做了。

原因在于：

在 Terway 的 ENI/ENIIP 等 VPC 网络模式下，Pod 地址来自 VPC 网络或与节点同属 VPC 地址规划体系。

这意味着：

Pod IP 不再只是集群内部自娱自乐的地址
Pod 会真实消耗 VPC/Pod 虚拟交换机里的可用地址
子网规模不仅决定节点上限，也会直接影响 Pod 容量
Node vSwitch、Pod vSwitch、ENI 数量和实例规格会共同影响最终可调度规模

这和很多基于 Overlay 网络的集群差异很大。

落地前建议先核对阿里云官方的 ACK 网络规划和 Terway 插件文档，重点确认 Pod 交换机、Service 网段、单节点 Pod 限额、ENI/IP 配额和 vSwitch 扩容限制。

先理解这个案例的核心矛盾¶

假设你有这样一个生产场景：

地域：华东 1
环境：生产
云平台：阿里云
集群：1 套 ACK 生产集群
网络插件：Terway
部署形态：多可用区高可用
工作负载：Java 微服务 + Ingress + Redis Operator + 日志采集 + 监控组件

如果你还是按传统思路，只给 ACK 节点子网随手划一个很小的网段，例如：

10.32.2.0/24

那你很可能在业务增长后迅速遇到下面这些问题：

节点数量还没到瓶颈，但 Pod 地址已经快耗尽
新副本调度失败，表现为 Pod Pending
Cluster Autoscaler 想扩容，但目标交换机可用 IP 不足
某个可用区子网过小，导致单 AZ 先打满
业务扩容、滚动发布、临时双倍副本时更容易触发 IP 紧张

也就是说，在 ACK + Terway 场景里，网络规划必须把 Pod 容量 当成一等公民来考虑。

这个案例里应该怎么规划¶

更贴近生产的思路通常是：

1. 生产 VPC 独立¶

例如：

生产 VPC：10.32.0.0/16

不要把生产 ACK 和测试、预发混在一个 VPC 里。

原因很现实：

Terway Pod 会直接占 VPC 地址
集群扩容和业务扩容会长期消耗地址池
混环境后很容易互相抢地址空间

2. ACK 节点/Pod 子网按可用区拆分，并留足富余量¶

例如：

可用区 A 节点/Pod 子网：10.32.8.0/22
可用区 B 节点/Pod 子网：10.32.12.0/22
可用区 C 节点/Pod 子网：10.32.16.0/22

这里不要只看“当前 10 台节点够不够”，而要看：

峰值副本数
滚动发布时的额外 Pod
HPA 扩容空间
DaemonSet 常驻开销
集群组件和系统 Pod 开销

生产里一个常见错误是：

业务当前只需要几百个 Pod
就按几百个 Pod 去卡死网段

但真正上线后，你还要考虑：

扩容时的瞬时双倍副本
故障迁移带来的单 AZ 压力上升
节点替换时 Pod 重建
灰度发布时新旧版本并存

所以在 Terway 模式下，给节点子网预留比“当前估算值”更大的地址富余，是非常必要的。

一个更可落地的估算方式是按可用区单独算，而不是只看整个集群：

单 AZ Pod IP 需求 =
  稳态业务 Pod 数
+ 系统组件 / DaemonSet Pod 数
+ 滚动发布额外 Pod 数
+ HPA / 大促峰值 Pod 数
+ 故障迁移冗余 Pod 数
+ 20%~30% 缓冲

然后再结合：

每个节点的最大 Pod 数
ECS 实例规格支持的 ENI/IP 数量
该可用区 vSwitch 可用 IP 数
云厂商保留地址和集群组件开销

去反推每个 AZ 至少要给多大的子网。这样算出来的结果通常会比“当前副本数”大一截，但这部分空间就是发布、扩容和故障迁移时的弹性。

3. 数据库、中间件、运维管理面不要和 ACK 节点/Pod 混在同一子网¶

更推荐这样拆：

10.32.8.0/22   ACK AZ-A
10.32.12.0/22  ACK AZ-B
10.32.16.0/22  ACK AZ-C
10.32.30.0/24  数据库
10.32.31.0/24  中间件
10.32.32.0/24  运维管理面
10.32.40.0/24  Ingress / SLB 相关资源

原因是：

Terway 模式下，ACK 子网的地址消耗会持续变化
数据层和管理层更适合稳定、边界清晰的网段
混在一起会让 IP 规划、权限边界和排障都变复杂

4. 提前规划好集群后续扩容和第二套集群的位置¶

生产里常见演进路线不是“一套集群永远跑到底”，而是：

业务增长后要扩第二套集群
核心业务和普通业务拆集群
有状态组件和无状态组件拆集群
新版本集群替换旧版本集群

所以更稳的做法不是把整个生产 VPC 地址一次性用满，而是提前预留例如：

10.32.8.0/22   ACK 生产集群 1
10.32.12.0/22  ACK 生产集群 1
10.32.16.0/22  ACK 生产集群 1

10.32.48.0/22  预留给未来 ACK 集群 2
10.32.52.0/22  预留给未来 ACK 集群 2
10.32.56.0/22  预留给未来 ACK 集群 2

这样当你后续做：

集群迁移
蓝绿集群切换
新旧版本并行
按业务域拆集群

时，不会被地址规划反向卡死。

这个案例里最容易忽略的生产细节¶

1. 不是“节点够了”就行，而是“子网 IP 够不够 Pod 用”¶

在 Terway 模式下，Pod 地址是 VPC 真实地址，所以容量规划一定要盯：

节点数
每节点可承载 Pod 数
子网总可用 IP
三者之间的关系

2. 滚动发布会放大 IP 压力¶

很多业务平时副本数看着不高，但一到：

灰度
金丝雀
滚动发布
大促扩容

新旧 Pod 并存，IP 消耗会突然抬升。

如果地址只按“稳态运行值”估，就很容易在发布窗口出问题。

3. 单可用区打满比整集群打满更常见¶

因为 Pod 调度、节点分布、AZ 容量并不总是完全均匀。

你在生产里更应该防的是：

AZ-A 子网先耗尽
导致该可用区无法继续扩节点或扩 Pod
最终影响高可用和调度均衡

所以生产规划里，通常每个 AZ 都应单独预留足够空间，而不是只看整个 VPC 总量。

从这个案例能得到的结论¶

如果你在阿里云 ACK 中使用 Terway，那 VPC 规划必须从“主机网络规划”升级为“节点 + Pod 一体化网络规划”。

更直白地说：

在 ACK + Terway 生产场景里，VPC 子网大小直接影响集群容量上限、发布弹性、扩容能力和高可用设计。

这类场景下最容易踩的坑不是“网络不通”，而是：

地址规划太小
环境混用
子网边界混乱
没有预留第二套集群空间

所以如果你的云原生平台明确会使用 Terway，那么在 VPC 规划阶段就必须把它当成一级约束条件，而不是后面再补。

四、从云原生专家视角，推荐怎么规划¶

下面给一个更偏平台建设的推荐思路。

1. 先按“区域级总地址池”来规划¶

不要先从某个业务开始切网段，而是先做一个区域级规划。

例如：

华东区域总池：10.32.0.0/12
  生产 VPC：10.32.0.0/16
  预发 VPC：10.33.0.0/16
  测试 VPC：10.34.0.0/16
  共享服务 VPC：10.35.0.0/16

这样做的好处：

一眼能看出环境归属
后续扩展有连续空间
和其他地域不容易打架

2. 同一 VPC 内按角色拆子网¶

例如生产 VPC 可以再拆：

10.32.1.0/24   ingress 子网
10.32.2.0/24   k8s node 子网-a
10.32.3.0/24   k8s node 子网-b
10.32.4.0/24   数据库子网
10.32.5.0/24   中间件子网
10.32.6.0/24   运维管理子网
10.32.7.0/24   NAT / 出口相关子网

这时你得到的不是一堆随机地址，而是一套有角色语义的网络。

3. 生产与非生产尽量不要混 VPC¶

这是很重要的原则。

因为一旦混在一起，后面几乎所有事情都会变难：

授权边界
访问审计
路由治理
故障隔离
成本分账

如果资源预算允许，生产和非生产至少要拆成不同 VPC。

4. 出口策略单独设计，不要默认全放通¶

很多团队的公网访问策略一开始就做错：

所有节点都能直接上公网
所有业务都能随意访问外部
没有统一出口审计

在云原生平台里，更合理的做法通常是：

统一走 NAT Gateway 或统一出口
按环境控制出网权限
对高敏感环境设置更严格的出口限制

这样做的意义不仅仅是安全，也包括：

排障更容易
出口流量更好统计
风险暴露面更小

5. 管理面流量和业务面流量尽量分开¶

例如：

堡垒机访问
kubectl/API Server 管理流量
监控采集流量
业务服务调用流量

如果这些都混在同一条路径里，后果通常是：

管理口暴露面过大
排障时很难分辨哪类流量异常
安全策略容易一刀切

从平台治理角度看，至少要在安全策略和访问入口上做区分。

五、一个更适合云原生平台的参考模型¶

下面给一个参考拓扑，不是唯一答案，但思路比较稳。

flowchart TB
    Internet[互联网]
    Office[办公网络 / VPN]
    CEN[云企业网 / VPC互联]

    subgraph Shared[共享服务 VPC]
        Bastion[堡垒机]
        DevOps[CI/CD / 镜像仓库 / 运维平台]
        Monitor[监控与日志平台]
    end

    subgraph Prod[生产 VPC]
        Ingress[SLB / Ingress]
        K8sProd[Kubernetes 生产集群]
        DBProd[MySQL / Redis / Kafka]
        NATProd[NAT Gateway]
    end

    subgraph Test[测试 VPC]
        K8sTest[Kubernetes 测试集群]
        DBTest[测试数据库]
        NATTest[NAT Gateway]
    end

    Internet --> Ingress
    NATProd --> Internet
    NATTest --> Internet
    Office --> Bastion
    Bastion --> K8sProd
    Bastion --> K8sTest
    DevOps --> K8sProd
    DevOps --> K8sTest
    Monitor --> K8sProd
    Monitor --> K8sTest
    CEN --> Shared
    CEN --> Prod
    CEN --> Test

这个模型背后的设计思想是：

公共能力独立
生产与测试隔离
出口统一
管理入口收敛
多 VPC 通过统一互联打通

六、常见错误做法¶

1. 一开始图省事，只建一个 VPC¶

短期确实快，但后面往往会变成：

所有环境混跑
安全策略越来越复杂
任何变更都容易影响全局

2. Kubernetes Pod 网段和现有内网撞了¶

这是非常常见的问题。

很多人建集群时默认用了一个网段，后面接专线、接 IDC、接第二个集群时才发现冲突。

这类问题一旦落地后再改，代价会很大。

3. 安全组和路由全靠人工零散维护¶

一开始量小还行，后面就会进入：

谁也说不清哪条规则为什么存在
某条规则删了怕业务炸
某个访问不通时排障成本极高

网络规划不只是“有规则”，还要有清晰分层和可解释性。

4. 没给未来留扩展空间¶

最典型的后果是：

多集群上不去
新环境拆不出来
新地域复制困难

网络规划最怕的不是现在浪费一点地址，而是未来完全没法扩。

七、落地时的实操建议¶

如果你是云原生平台负责人，我建议按下面顺序推进。

第一步：先画“目标态网络图”¶

不要直接建资源，先回答：

有几个环境
有几个 VPC
管理入口在哪里
业务入口在哪里
出口在哪里
数据库和中间件怎么分层
Kubernetes 有几个集群

第二步：统一地址规划台账¶

至少维护一份清晰台账，记录：

VPC 网段
子网用途
Pod CIDR
Service CIDR
预留空间
互联关系

这份台账在后续扩容和排障里非常重要。

可以先用下面这种轻量模板管理起来：

区域	环境	VPC	VPC CIDR	可用区	子网/交换机	子网 CIDR	用途	Pod CIDR / Pod vSwitch	Service CIDR	互联对象	预留说明
华东 1	生产	prod-vpc	10.32.0.0/16	A	prod-ack-a	10.32.8.0/22	ACK Node/Pod	Terway Pod vSwitch	172.20.0.0/16	shared-vpc、CEN	预留 30% 发布和扩容空间
华东 1	生产	prod-vpc	10.32.0.0/16	A/B/C	prod-db	10.32.30.0/24	数据库	不适用	不适用	ACK、堡垒机	不与 ACK Pod 地址池混用
华东 1	共享	shared-vpc	10.35.0.0/16	A	shared-ops	10.35.10.0/24	堡垒机/运维平台	不适用	不适用	prod-vpc、test-vpc	管理入口统一收敛

第三步：把网络边界和安全边界一起设计¶

不要先规划网段，后面再补安全。

更合理的顺序是同时考虑：

哪些系统应该互通
哪些系统不该互通
谁可以访问管理面
谁可以访问数据层

第四步：优先考虑未来互联¶

如果你的平台未来有这些可能：

多云
混合云
多地域
IDC 上云

那么一开始的网段规划就必须把这些考虑进去。

八、最后总结¶

从云原生专家视角看，VPC 网络规划从来不是“给几台主机分配地址”，而是平台架构设计的一部分。

如果要把这篇文章压缩成几个最重要的结论，我会总结成下面 5 条：

VPC 规划的目标不是先通，而是长期可扩展、可隔离、可治理
生产、测试、共享服务最好按环境或角色拆分 VPC 与子网
Kubernetes 的 Node、Pod、Service 网段必须和 VPC 规划一起设计
出口、管理面、业务面、数据面应该有明确边界
一开始多花一点时间做规划，远比后面网络重构便宜

真正成熟的云原生平台，网络从来不是最后补的，而是一开始就要设计清楚的底座。