云原生环境网络隔离局限

很多人对云原生网络隔离的信心，来自一个很具体的动作：给命名空间贴上 NetworkPolicy，默认拒绝，再一条条放行。做完这一步，感觉集群内部就“关起来”了。但只要把视线挪到控制平面，就会发现这套逻辑有个不小的缺口。

问题出在 etcd 身上。用 kubeadm 建起来的集群里，etcd 通常以静态 Pod 的形式跑在控制平面节点上，并且启用了 hostNetwork。这意味着它直接使用宿主机的网络栈，流量根本不经过 CNI。而 NetworkPolicy 作用在 Pod 网络上，对那些直接占用主机端口的进程，基本管不着。结果就是，命名空间里的策略写得再严，etcd 的 2379 和 2380 端口该监听还是监听；谁能连上来，取决于节点防火墙、云安全组或者网络 ACL，而不是那一堆看起来很整齐的 YAML。

这两个端口的分工也不一样。2379 是客户端连接，kube-apiserver 靠它读写整个集群状态；2380 是成员之间的 peer 连接，用来做日志复制和选主。真正容易出问题的，往往不是 apiserver 这一条，而是 peer 端口被放宽到了不必要的网段，或者 etcd 干脆监听在 0.0.0.0 上，让公网、办公网、普通工作负载网段都有机会来握一次手。

还有一个更普遍的误解：以为隔离做到位就安全了。其实网络隔离只回答“能不能到达”，不回答“到达之后能不能通过认证”。这两件事得同时存在。只开了 HTTPS、没有强制客户端出示证书，监听器照样会被大量半截握手的连接消耗资源；反过来，双向 TLS 配得再完整，端口对着公网敞着，也等于把锁装在了没有墙的地方。

托管集群是另一套处境。云厂商管着 etcd，用户看不到静态 Pod 清单，改不了监听地址，也不该跑到节点上拿防火墙去“修正”别人托管的东西。能做的只是检查 API server 端点是不是私有的、授权网段配了没有、审计日志能不能用，然后把这些列进基线。

所以对普通团队来说，网络隔离不是一次配置就完事的开关，更像一份要跟着集群生命周期走的清单：谁该连、从哪个网段连、用什么证书连、出问题怎么退回去。节点扩容、控制平面升级、证书轮换，任何一次变更都可能把之前收窄的口子重新撑开。