关于云原生集群网络流量那些零散但重要的观察和思考

关于云原生集群网络流量那些零散但重要的观察和思考

东西向流量成为主角，但管理思维还停留在南北向

在传统的网络观念里,我们最关心的是“南北向流量”，也就是外部用户访问我们内部服务的流量，比如通过负载均衡器进来的请求，我们会为这些入口设置防火墙、WAF（Web应用防火墙）、限流等重重关卡。

但一旦进入云原生集群内部,比如一个微服务A要调用微服务B，这个“东西向流量”往往处于一种“默认信任”的状态。（来源：多位云原生领域工程师的博客分享，如“阳明”的K8s网络文章） 这种流量在虚拟网络里直接穿梭，缺乏有效的审计和安全控制，攻击者一旦攻破其中一个不那么重要的Pod（容器组），就可能利用这种内部信任关系，横向移动，攻击更核心的服务，这就像大楼门口安检严格，但楼内所有房间的门都不上锁一样危险。

服务发现很美好，但故障排查像捉迷藏

Kubernetes的服务发现机制（Service）让应用无需关心后端Pod的具体IP地址，这是一个巨大的进步，当网络出现问题时，这种抽象就变成了噩梦。（来源：CNCF社区关于K8s网络故障排查的讨论）

一个服务调用偶尔超时,你可能会检查：是Service的标签选择器对吗？Endpoints（端点）列表里有健康的Pod吗？Pod本身是否健康？还是节点网络出了问题？又或者是CNI（容器网络接口）插件自身的Bug？问题可能出现在从应用代码到内核协议栈的漫长路径上的任何一个点，传统的ping和traceroute工具在Overlay（叠加）网络下常常失效，因为虚拟IP和物理IP的映射关系不直观，排查这类问题，需要一套全新的工具链和思维方式，比如直接进入Pod的Network Namespace（网络命名空间）里执行命令。

网络策略：不是可有可无的装饰品，而是必备的防火墙

很多人刚接触Kubernetes NetworkPolicy（网络策略）时，会觉得它复杂且非必需，认为集群本身就有网络隔离，但实际上，在大多数默认安装的CNI插件中，Pod之间是网络可达的。（来源：Kubernetes官方文档及安全最佳实践指南）

NetworkPolicy是你在集群内部实现“微隔离”的关键，它允许你定义诸如“只有来自命名空间A中带特定标签的Pod，才能访问命名空间B中数据库服务的3306端口”这样的规则，这相当于在集群内部为每个服务安装了精细的防火墙，忽视网络策略，就等于让所有服务在内部“裸奔”，它的配置和管理本身也是一个挑战，需要像管理代码一样去管理这些策略。

性能开销：看不见，但摸得着

云原生网络方案,尤其是Overlay网络（如Flannel的VXLAN模式、Calico的IPIP模式），会带来一定的性能开销。（来源：各类CNI插件性能基准测试报告，如“腾讯云专家”发布的对比文章） 这些技术为了在底层物理网络上创建一个虚拟网络，需要对数据包进行额外的封装和解封装，这会消耗CPU资源，并增加少量的网络延迟。

对于大部分Web应用来说,这点开销可能无伤大雅，但对于延迟极其敏感的应用（如高频交易）或大数据量的内部传输（如日志收集、镜像分发），这个开销就必须被重视，在选择CNI插件时，需要根据业务场景权衡功能、复杂性和性能，有时，采用Underlay网络（如MACVLAN、SR-IOV）或eBPF技术优化的方案，可能是追求极致性能的选择。

可观测性：从“黑盒”到“白盒”的挑战

在传统架构中,我们可能只需要监控网络设备的端口流量、丢包率，但在云原生环境下，这远远不够。（来源：Observability Engineering领域相关论述，如《可观测性实践》等资料的观点） 服务的动态调度、频繁的扩缩容、以及复杂的调用链，使得网络流量变得极其动态和碎片化。

你需要知道：

• 服务级别：每个服务的QPS（每秒查询率）、延迟、错误率。
• 拓扑级别：服务之间的依赖关系是怎样的？哪个下游服务是当前的瓶颈？
• 网络级别：在TCP重传、连接数、丢包层面有没有异常？

这就要求引入服务网格（如Istio、Linkerd）来提供更细粒度的流量管理和遥测数据，或者使用专有的网络可观测性工具（如Cilium的Hubble），才能将集群内部的网络流量真正变成“白盒”，从而快速定位问题。

DNS：小配置，大问题

Kubernetes集群内部有自己的一套DNS系统（通常是CoreDNS），Pod默认会使用这个DNS来解析ServiceName.Namespace.svc.cluster.local这样的内部域名。（来源：运维人员分享的常见K8s网络故障案例）

一些看似不起眼的配置可能会引发大问题,Pod内部的/etc/resolv.conf文件中的ndots设置，它决定了域名在什么情况下会被视为绝对域名而直接查询，什么情况下会先尝试拼接搜索域，如果设置不当，可能会导致大量的无效DNS查询，从而拖慢应用启动速度或增加DNS服务器压力，如果应用镜像的基础镜像配置了特定的DNS服务器或搜索域，可能会与集群的DNS策略冲突，导致服务发现失效。

云原生集群的网络不再仅仅是连通性问题,它深度融合了应用发布、安全、性能和可观测性，理解这些零散但至关重要的点，意味着我们需要摆脱传统网络的思维定式，从一个更全局、更贴近应用生命周期的视角来审视和治理流量，这要求开发、运维和安全团队具备更广泛的知识栈，共同应对这些新的挑战。