前言

某企业自2018 年生产实际上线以来，先采用三层Overlay 网络遇到跨集群服务注册调用问题后，改用二层Underlay 容器网络模式，又带来了占用众多网络IP、跨域访问管理复杂化和扩大了安全暴露面等问题。随着信创替换的推进和应用系统云原生化的改造，云原生PaaS 平台集群数量不断增长，并要符合网络安全合规等要求，因此，云原生容器集群网络的选择是一个不得不重视和重新审视的问题。

二层Underlay和三层Overlay网络比较

二层Underlay网络是物理网络，由多种网络物理设备如交换机、网卡等构成。Underlay网络的配置往往需要网络团队和虚拟化团队等的支持，比如说需要提前规划和分配网络IP段、VLAN ID 等。Underlay网络无需虚拟化转发，因此性能好。三层Overlay网络是虚拟化网络，是在 现有 容器节点 网络上叠加一个软件定义的 虚拟化 逻辑网络， 在不影响原有网络的情况下，解决容器集群中Pod 中服务访问的问题。实施Overlay技术后，会在Underlay网络基础上形成一张逻辑网。Overlay网络隐藏了底层物理网络细节，降低了网络组网的复杂性，无需多网卡，通过软件定义网络，无需网络团队的接入。Overlay网络以其虚拟化能力为云原生应用和动态环境提供了灵活性和扩展性 。但Overlay 网络需要转发，性能差，特别在万兆及以上网络贷款下，Pod网络性能下降明显。某厂商测试显示，Overlay 网络模式下，Pod网络带宽性能比在宿主机网络带宽下性能下降28% 左右，在40G或100G网络带宽下更加明显。

Underlay 网络被人最推崇的一点就是可通过Pod IP直接访问Pod中的服务。这也是很多传统企业在整个PaaS体系建设不完整的情况下的便捷方式。Overlay网络Pod IP不可直接访问，特别是在使用Spring cloud等微服务框架的情况下，往往服务使用Pod IP注册到集群外部注册中心如Eureka ，另外一个集群的服务用发现的Pod IP是在跨集群调用时不可达。这是Overlay网络模式备受诟病的一个问题，也是很多单位改用 Underlay 网络的重要原因。当然可以通过Node Port 、Ingress等其他方式实现访问，但Kubernetes提供的容器服务访问方式和SpringCloud框架提供的方式是不一样的。大部分云原生环境都是外置注册发现中心和Kubernetes提供的服务暴露方式混用，这就导致了三层Overlay网络默认无法实现跨集群调用问题。当前有厂商打通了集群之间Overlay网络通信，额外增加了一层封装并且需要对集群网络IP段进行提前规划和配置。但额外增加了链路和延迟，增大了复杂度。

Underlay网络在有大量业务服务的情况下会占用大量的IP地址，如同增加了众多的虚拟机，而且一个很大的问题是，容器是动态变化的，从而导致传统的网络管理方式难以适应云原生容器化部署方式，为网络团队额外带来了管理压力。可以想象下，多管理几倍的变化机器是个什么境况。大量的可见容器，也极大的增加了风险暴露面，特别开源软件漏洞众多，容器安全措施不足的情况下，会带来极大的风险。众多云原生组件默认密码、默认端口以及镜像数十甚至数百已知的安全漏洞等会导致企业安全千疮百孔。Overlay网络则无需额外IP资源，对网络团队也不可见，因此会替网络团队减少很多的工作量。Pod IP 不可见也尽可能地减少了风险暴露面，有助于风险管理和安全管控。

Underlay 网络很重要的一个能力是可以通过固定IP方式在防火墙上配置 Pod IP，把容器当作虚拟机管理。但众多的容器也对防火墙规则的管理带来挑战，过多的配置规则也使防火墙处理性能下降。另外固定IP等方式也限制了容器服务的弹性伸缩能力，难以有效利用容器的特性。这和容器的理念是相悖的。Overlay网络通过容器服务暴露的方式对外提供服务，而在防火墙上的配置取决于服务暴露方式，比如Node Port ，load balancer 等，防火墙设备通常不支持域名配置而往往不能用ingress 方式。Overlay 网络通常跨域访问不需要在防火墙设备配置太多规则，可以充分利用容器弹性伸缩等特性。服务的调用我一直倾向于避免跨集群调用，尽可能将相关的服务部署在一个集群内，通过东西流量实现链路执行。多集群则实现集群之间的隔离、高可用、灾备等需求。如果避免不了则走南北流量，可以通过API网关进行管控。我一直认为API 网关在云原生环境是一个非常关键的角色（尽管它的出现是为了解决ESB 服务API集成管理等问题），它可以协助调控南北的流量，承担负载均衡、流量分发、访问控制、服务编排、统计分析等职责，Kubernetes和API网关需要协同完成服务访问控制需求等。

Underlay网络访问便利，但更多是以IP资源管理为中心，通过IP关联应用。IP动态变化则会使安全团队难以跟踪管理，遇到安全漏洞等风险定位需要容器或 PaaS 平台管理人员的协助，势必会增加协同难度。Overlay 网络则对传统网络安全人员透明，由容器或PaaS平台管理人员负责容器安全等问题，可以实现“以应用为中心”而不关注网络IP等。

Kubernetes 集群可以构建在虚拟化或IaaS 平台之上，以实现资源的弹性。不过需要考虑虚拟化或IaaS平台对Underlay网络的支持。目前似乎除VMware 之外，大多厂商的IaaS平台都不支持容器平台自带的Underlay网络插件。而采用Overlay 网络则无需考虑这些问题。

总的来说Underlay网络和Overlay网络各有优缺点，不同的人的立场和偏好也不一样，因此在详细了解区别之后可以根据实际情况选择。

二层Underlay和三层Overlay网络适用场景分析

由于 Underlay网络 和Overlay 网络的特点不一样，所以其适用场景会有区别。Underlay以其高性能和稳定性， 适合在统一的云平台环境或高性能、固定IP、统一的注册发现中心访问等场景；Overlay网络则 以其灵活性和隔离性在 传统多网络安全域、单集群内调用等场景 。Underla y网络模式更兼容传统的网络管理方式，但一旦大量的容器部署，则会导致整个管理极度复杂化，因此可能更适合容器Pod量不是特别多的情况下，或拿容器当虚拟机使用（这种方式我特别不建议），这样可以为Pod 分配固定的IP，不会导致IP变化使在防火墙设备上配置规则失效。从Underlay管理和使用的角度，其是从传统运维的角度关注资源，这也是很多公司没有转变运维的理念或大量存量的系统交互所决定的。Overlay 网络实现了集群隔离（也有厂商在一个集群既支持Overlay 也支持Underlay），封装了网络层细节，将容器网络等都交给平台自动管理，使用户可以更关注应用，可以充分利用云原生环境一致性、容器弹性伸缩等特性，因此Overlay网络更能体现云原生的一些特性。但当前很多公司由于监管合规、网络安全分域等要求，使整个Kubernetes 集群的部署复杂化，跨防火墙域访问对Overlay 网络并不友好。另外，Overlay 网络的性能也是个问题，虽然大多数场景可能关系不大，但对于一些延迟敏感的业务，Overlay可能并非理想选择。

容器网络方案相关思考总结

三层 Overlay 模式和二层 Underlay 网络模式各有明显优缺点，通常也不建议一个集群既有underlay 网络又有overlay网络。现实情况又不得不考虑微服务的注册发现问题、跨集群访问问题、固定IP防火墙设置问题等。

微服务注册发现问题

首先微服务并不是等同于SpringCloud服务。这是很多人的错误认知导致整个容器服务的管理复杂化。SpringCloud是微服务开发框架，有自己的一套工具体系，和Kubernetes 提供的容器服务管理功能是有重叠的。比如说Spring Cloud 使用Eureka 作为注册发现中心，而Kubernetes 的容器服务可以直接注册到Kubernetes，提供了Service 对象来标识服务。可以通过ClusterIP 、Node Port 、load balancer 、Ingress 等方式暴露服务。集群内可以直接通过“<服务名 > . < 命名空间 >.svc.cluster.local ”访问服务。

在多个集群部署同一个服务并注册到统一的注册中心时，SpringCloud服务在查询可用服务时面临着Overlay Pod IP 跨集群不可达问题。各家厂商也提供了多种解决方案，不过我觉得，从减层、简化复杂度角度，可以抛弃SpringCloud注册中心，直接用Kubernetes服务注册管理，把容器服务暴露为微服务。不过大部分人习惯了SpringCloud框架，改变起来难度不小。

跨集群访问问题

我一直的建议是尽可能避免跨集群调用，要尽可能把跨集群的调用转变为南北流量，实现多集群的高可用部署或灾备部署等。这需要从源头切换流量，这也是我一直强调的API网关的价值。

每个服务都访问源头，也就是整个业务链路的起点，通常这个源头是在Kubernetes 集群外的终端工具，也就是用户触点。这样的话我们就可以劫持请求进行转发，根据容器内服务链路调用情况反馈给API网关或等价工具在异常或故障情况下自动实现流量切换。避免调不通集群1服务的情况下从集群1调用集群2的服务，也避免服务从集群一出一进带来的延时和额外的其他问题。

固定IP问题（防火墙配置问题）

Kubernetes Loadbalancer 服务暴露方式可以为每个服务对外提供一个IP。这种方式下既可以在集群内部实现多实例弹性伸缩，也不用关注需要多少IP 等问题。不过这种方式需要额外Loadbalancer 工具的支持，目前有开源MetalLB 等工具可以使用。为需要暴露为IP服务的业务服务配置IP资源池并分配IP。这种方式不关注Pod IP，可以减少大量的防火墙配置规则，也可以利用容器弹性伸缩的特性，个人觉得比较适合Overlay网络模式下的防火墙规则管理需求。

网络安全分域部署问题

结语

容器Underlay和Overlay网络模式选择可以说直接关系着整个容器和云原生PaaS平台的使用方式选择，但两种模式目前均各有明显的优点与缺点，企业需要审视其应用场景并谨慎选择。但随着企业应用实践和相关从业人员对容器网络认知的不断深入，相信能够促进厂商对技术的不断探索和完善提升，期待未来会有两全其美的方案。

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发、点赞或点击在看，让更多同行看到