在容器平台中为不同业务划出独立网络区的核心做法，是先按业务边界规划命名空间（Namespace）做逻辑隔离，再用网络策略（NetworkPolicy）做流量管控，最后在底层用CNI插件确保数据面隔离，三层配合，才能让各业务在网络层面互不干扰、合规可控。
不同业务共用一个容器平台，最头疼的往往是网络区划不清，开发环境调用生产接口、某业务线被扫端口、临时环境IP互相冲突，这些问题的根源都在于没把网络边界划明白，下面直接讲落地方案，从命名空间划分到CNI选型，再到多集群场景,按步骤拆开讲。
先把业务边界翻译成命名空间和网络策略
为什么命名空间只是起点而非终点
命名空间（Namespace）解决的是资源归属问题，不是隔离问题，不同业务放进不同命名空间，资源名字不会撞车，但Pod之间依然能互通，想要真正的网络独立，必须叠加两层：网络策略（NetworkPolicy）控制东西向流量，CNI插件提供底层封装。
具体操作路径：在Kubernetes中，先为每个业务创建独立命名空间，例如business-a、business-b，然后为每个命名空间打标签，例如env=prod、team=payment，标签是后续策略引用的关键锚点没有标签,策略就无从绑定。
用NetworkPolicy把”允许谁访问”写明白
网络策略的本质是白名单机制，默认拒绝所有流量，再按需放行，一个典型的场景：business-a的Web前端只允许被网关命名空间访问，后端API只允许被Web前端访问，在business-a命名空间下创建三个策略,用Pod选择器锁定来源和目标。
策略示例（用kubectl apply生效）：
- 入口规则：允许来自网关命名空间、端口80的TCP流量。
- 入口规则：允许来自本命名空间、标签为
app=frontend的Pod访问后端API端口8080。 - 出口规则：允许API Pod访问数据库命名空间内的实例,仅限3306端口。
这里有个容易忽视的细节：默认拒绝策略需要单独创建，如果只写了允许规则，而没有一条”拒绝全部”兜底，那么未匹配到的流量依然是放行的，行业共识认为，在创建业务命名空间时，第一件事就是丢一条默认拒绝策略进去,再逐条放开白名单。
容器平台网络隔离方案对比：从CNI插件选型看隔离深度
不同CNI插件对网络隔离的支持力度差异很大,选型直接决定隔离能力上限。
|
CNI插件 | 网络模型 | 隔离能力 | 性能损耗 | 适合场景 |
|---|---|---|---|---|
| Flannel | VXLAN/Overlay | 仅Namespace级，不支持网络策略 | 低 | 开发测试环境、无强隔离要求 |
| Calico | BGP/Routing | 原生支持网络策略，支持IP段限流 | 中 | 生产环境、多租户平台 |
| Cilium | eBPF/Overlay | 网络策略+七层可观测，支持DNS规则 | 低（eBPF加速） | 大规模集群、安全要求较高的金融场景 |
| Weave Net | 自研Overlay | 支持基础网络策略 | 中 | 小规模集群、快速部署 |
从上表能看出，Flannel适合当”省心方案”，但做不了精细隔离，Calico是生产环境常见选择，策略能力直接对标Kubernetes标准，且支持IP池划分这是为业务划独立网段的关键，Cilium则适合对性能和安全都有要求的场景,eBPF技术让它在七层可观测上优势明显。
动态IP池：把网段和业务绑死
有明确合规要求的企业，例如政务云、金融私有云，通常要求不同业务使用不同IP段，这种需求下，Calico的IP池（IPPool）功能可以直接支持,操作路径：
- 安装Calico后，按业务创建多个IPPool，例如
20.0.0/16划给支付业务，30.0.0/16划给风控业务。 - 在命名空间上添加注解
cni.projectcalico.org/ipPool,指向对应IP池。 - 该命名空间下所有Pod会自动从指定IP池分配地址,IP和业务绑定。
这么做的实际价值在于：防火墙策略、审计日志、网络监控都能直接按IP段区分业务，不用再通过标签反查Pod归属，对运维排障来说，看到IP就知道是谁家的流量,效率提高不少。
多集群场景下的网络隔离怎么实现
单集群内用命名空间和网络策略能解决大部分场景，但业务规模上来后，一个集群塞太多业务，规格限制、故障爆炸半径、版本升级互相影响都会成为问题，这时就得考虑多集群方案，配合底层VPC能力做硬隔离，多数情况下，多集群网络隔离的优先级是：先在VPC层面划分CIDR和子网，再用专有网络对等连接或云企业网打通必要的通路。
如果集群部署在自建机房，没有云厂商VPC概念，那就用Underlay网络直接分配物理网段给不同集群，或者用Cilium的ClusterMesh功能，让不同集群的Pod地址段天然不同，再通过全局服务名互相访问,网络策略在各集群内独立生效。
写网络策略时常见的坑和排查思路
策略太多记不住，直接互斥怎么办
实际环境里策略规则一多，很容易出现A策略放行、B策略又拒绝的情况，最终抓包发现流量还是不通，排查顺序建议：先查CNI插件的策略命中计数（Calico的calicoctl工具、Cilium的cilium monitor都能实时看到策略丢弃记录），再逐个调整规则，别靠猜，另一个常见坑是忘记放行DNS流量Pod解析Service名称需要访问kube-system里的CoreDNS，出口策略如果只放行业务端口而忽略UDP 53，业务会发现域名解析不了,这是相当一部分生产事故的诱因。
网络策略限制不了节点端口，怎么补
NetworkPolicy只管控Pod与Pod之间的流量，对节点端口（NodePort）和负载均衡器直接转发过来的流量不起作用，所有走NodePort的流量都能绕过网络策略,补充方案有两种：
- 在云厂商安全组或自建防火墙层面限制来源IP,只允许经过网关的入口流量。
- 改用负载均衡器直通Pod而非NodePort，流量路径更可控,策略也能生效。
命名空间删了重建，策略全丢怎么办
命名空间被误删后，其中所有网络策略会一并消失，运维常干的补救是把策略写成GitOps管理的YAML仓库，用ArgoCD或Flux定时同步，这样就算命名空间重建，策略也能在秒级恢复，业内专家指出，将网络策略纳入版本管理是规模化平台的基本操作,不依赖某个工程师的人工记忆。
容器平台里划分网络区的实操步骤清单
按以下顺序操作,一步不到位后面可能返工：
- 梳理业务清单，确认哪些业务必须物理隔离（例如生产与开发、不同客户租户）,哪些仅需逻辑隔离。
- 为每个隔离组创建命名空间，打上清晰标签（
team、env、tier至少要有两个维度）。 - 安装或确认CNI插件支持网络策略，Calico为默认推荐，如果集群已用Flannel，直接换掉成本更高,可评估Ingress层做入口管控。
- 创建默认拒绝策略,去掉所有隐式放行的流量。
- 按业务依赖关系逐条打开白名单，先放行DNS（kube-system）,再放行业务端口。
- 验证策略是否生效：起一个临时Pod，用
kubectl exec -it进入后用curl或nc测试端口连通性。 - 把策略、命名空间、标签全部写进Git仓库,由流水线自动部署。
观察几天流量日志，确认没有非白名单流量被误杀，再把策略从宽松模式切到拒绝模式，一次别把所有业务都收紧,分批次灰度更稳妥。
Kubernetes网络策略和容器平台网络隔离什么关系
常见误解是把两者混为一谈，Kubernetes网络策略是API层面的标准抽象，描述”哪些Pod能访问哪些Pod”的规则，容器平台网络隔离是个更大的工程概念，还包括命名空间配额、服务网格的mTLS加密、底层IP地址规划、甚至机房级别的灾备隔离，网络策略负责的是防火墙规则这一层的执行，平台层面的隔离则依赖CNI插件、网络硬件、VPC规划共同完成。
举个具体例子：一个集群跑了支付、客服、运营三个系统，Kubernetes网络策略能控制支付系统Pod只允许被客服系统特定服务调用，但如果支付系统底层Pod不幸被调度到和运营系统同一台宿主机，两者共享内核、共享网络命名空间容器逃逸风险始终存在，平台级别的强隔离如果需要兜底，就得为支付业务分配独立节点池，配合污点和容忍度把Pod调度到物理隔离的机器上，Kubernetes网络策略管不到这层,池子和机器的隔离靠调度策略和资源配额实现。
常见问题
一个集群最多能划分多少个独立网络区
没有硬性限制，但扩展瓶颈主要出在CNI插件和宿主机规格上，Calico每条网络策略都会下发到节点上的iptables规则，策略数量破千后，规则更新延迟会上升，有Planet的实测数据显示，单集群网络策略数建议控制在五百条以内，超出后考虑拆分多集群，命名空间数量不受网络策略限制,但每个命名空间的Pod数量会受制于节点Pod密度上限。
节点端口绕过了网络策略，有没有一劳永逸的解法
最稳妥的办法是不用NodePort暴露生产服务，统一用Ingress Controller或Service Mesh入口，Ingress本身在集群内以Pod形式运行，流量经过它转发时已经进入了Pod网络，网络策略可以正常管控后端目标，如果历史服务已经依赖NodePort，可以通过安全组锁定来源IP，然后把NodePort逐步下线,切换时间窗口与业务方提前对齐。
同一命名空间里的不同业务可以通过网络策略隔离吗
可以，但这属于反模式，命名空间本身就是隔离边界，把多个业务塞进同一命名空间再靠网络策略拆开，策略会成倍增加，管理成本和出错概率都上去了，更合理的做法是拆命名空间，每个业务独立一套策略，如果某个新业务很小，临时放在现有命名空间里，那就用标签区分，例如team=risk与team=marketing，并在策略里按标签精确到工作负载级别,但持久化运行还是建议尽快拆出。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/639362.html
