Getting Started and Beyond｜云原生应用负载均衡选型指南

作者

冉昕，腾讯云服务网格TCM产品经理，现负责云原生流量接入网关与应用通信可观测性等产品特性策划与设计工作。

刘旭，腾讯云高级工程师，专注容器云原生领域，有多年大规模 Kubernetes 集群管理及微服务治理经验，现负责腾讯云服务网格 TCM 数据面产品架构设计和研发工作。

引言

应用的入口流量管理一直是开发运维关注的焦点之一，随业务部署的计算资源、网络环境、应用架构的发展变更，接入层流量管理方案的发展可大致分为传统架构、云原生容器化两个阶段。为满足应用交付的效率和诉求，各阶段都涌现了不同的接入层解决方案，从最初的简单负载均衡，到后来的 HAProxy、Nginx 等反向代理，再到如今的容器化环境下的各类 Kubernetes Ingress Controller。每个发展阶段有哪些特点？面临什么挑战？都有什么解决方案？

阶段	应用部署资源粒度	应用架构	应用访问寻址
传统架构	物理/虚拟机（资源利用率低）	单体或简单拆分模块	基于较固定的 IP 地址管理
云原生容器化	容器（资源利用率高）	服务化	容器 IP 动态变化，通过动态服务注册更新

传统架构阶段，业务为单体应用，三层架构；部署于物理机/虚拟机；网络环境基于 IP 地址管理，相对固定，基本不会变化；业务更新迭代的速度较慢，接入层的主要需求是具备 4 层和 7 层的负载均衡能力，用传统负载均衡器支持即可。随着应用架构演进（应用做了一定模块拆分）和迭代效率的提升，出现了一些更复杂的接入层诉求：按流量内容特征路由、灰度发布、限流、鉴权等，一般通过在负载均衡器后增加一层网络代理（e.g. Nginx）支持，网络代理 Nginx 具备更多的 7 层流量处理的能力，可通过 OpenResty 社区的 Lua 扩展上述内容路由、灰度发布、鉴权限流等高级功能。

云原生容器化阶段的理想状态是业务开发者只需专注实现业务逻辑，无需关心资源调度和运维管理，可真正做到按需使用，按量计费。虚拟机/物理机资源粒度粗糙，利用效率较低，需提前规划计算、存储、网络资源，与理想状态有较大差距。云原生阶段，容器资源的粒度更细，利用率高，启动/销毁速度达到秒级，可灵活弹性伸缩（Kubernetes 已成为容器编排调度的业界标准，以下容器环境均代指 Kubernetes 集群）；网络管理环境也发生了变更，出现 Service 的概念，一个微服务往往是由一组弹性伸缩、动态调度的容器（Pod）承载，Pod 的 IP 地址动态变化，这一组 Pod 一般以 Service 对外提供访问，流量管理是以 Service 为单位。服务化拆分业务模块构建应用更容易，加上容器环境良好的弹性伸缩能力，DevOps 理念得以很好的实施，微服务的迭代步伐加快，经常需要滚动更新。此时的入口流量管理面临如下新挑战：

1. 需要与 Kubernetes 集成，支持转发流量到指定 Pod。
2. 更新迭代速度加快，对服务新版本灰度发布的诉求更加强烈。
3. 出现集群概念，集群之间的服务发现是隔离的，接入层需支持跨集群的服务发现（即接入层可选择 backend 为多个集群的 Pod ）；这区别于传统物理机/虚拟机阶段，没有集群隔离，只需保证网络联通性，即可配置接入层后端为任意对应服务的 IP 地址。
4. 传统阶段到云原生阶段的迁移过程中，出现 VM、容器环境混布的情况。

基于上述挑战，出现了以下容器环境的接入层流量管理解决方案：

1. Kubernetes 官方定义的 Ingress API：老牌网络代理（e.g. Nginx，HAProxy）或云厂商的负载均衡产品（e.g. AWS Elastic Load Balancer，腾讯云 CLB）都实现了各自的 Ingress Controller，作为单个集群的入口流量管理解决方案。灰度发布、鉴权限流等能力，视 Ingress Controller 的能力，可通过 Annotation 扩展，部分 Ingress Controller 还设计了自己的流量管理模型和语法。
2. Service Mesh Ingress：服务网格的服务发现和管理界限大于集群纬度，以 Istio Ingress Gateway 为例，基于 Istio 跨集群的服务发现能力，backend 可以来自不同集群的服务，同时还支持注册在网格内运行在虚拟机上的服务。Istio 也设计了自己的管理模型和语法，声明式支持配置一致的南北 + 东西向流量管理。
3. 沿用原有 VM 上部署的网络代理，转发流量至 VM 服务或 Kubernetes 集群的服务。

下面本文将从云原生容器化环境入口流量管理使用场景切入，带您了解云原生接入层流量管理的各类解决方案及优劣对比。

云原生接入层流量管理场景与解决方案

场景一：基础流量管理

入口流量管理的首个使用场景是需要将服务暴露给外部，供客户端调用。常见的方式是将服务按 URL 暴露，例如一个电商网站，需要将 /login 的请求路由到登陆服务，将 /product 的请求路由到商品服务等，该场景要求接入层具备基于流量内容路由的能力。

方案：Load Balancer + NodePort

在容器化的早期阶段，应用同时部署在虚拟机和 Kubernetes 集群上，很多用户会使用原有负载均衡（e.g. Nginx, 腾讯云 CLB）将请求分别转发到虚拟机和容器，同时受限于容器网络方案，原有负载均衡不能直接访问 Pod IP，因此需要通过 NodePort 暴露集群内的服务。

但是该方案存在以下问题：

1. NodePort 端口数量有限（默认 30000-32767）
2. 随着集群规模的扩大，Nginx 配置文件越来越复杂，不易管理
3. 用户将应用发布到 Kubernetes 集群后，需要再单独修改 Nginx 配置，体验不够云原生

方案：Kubernetes Ingress

Kubernetes 提供了 Ingress API [1] 用于暴露集群内的 HTTP 服务，Ingress 支持基于 Host 和 Path 将请求路由到不同 Service。为了让 Ingress 工作，集群必须有一个正在运行的 Ingress 控制器（e.g. Nginx Ingress Controller）。原生 Ingress 语法提供简单的基于 Host，Path 路由，以及配置 TLS 的能力。

1. 基于 Host 路由