原文作者:Owen Garrett of F5
原文链接: API 网关 vs. Ingress Controller vs. Service Mesh,该怎么选? - NGINX
转载来源:NGINX 官方网站
我们在 2021 年举办的 Ingress Controller 和 Service Mesh 网络研讨会中,几乎每场都会听到以下类似的问题:“这个工具与 API 网关有什么不同?”,或者,“我需要在 Kubernetes 中同时使用 API 网关和 Ingress Controller(或 Service Mesh)吗?”。
我们完全可以理解这些困惑,原因有二:
本文将探讨这些工具的不同之处,以及针对不同的 Kubernetes API 网关用例该选用哪种工具。有关详细内容(包括演示),请观看网络研讨会:“Kubernetes 的 API 网关用例”。
API 网关、Ingress Controller 和 Service Mesh 本质上都是一种代理,旨在管理您多种环境内的流量进入和流动。
API 网关将 API 请求从客户端路由到适当的服务,但人们却对这个简单定义存在很大的误解,认为 API 网关是一种独特的技术,实则不然。“API 网关”描述了一组可以通过不同类型的代理(ADC 或负载均衡器和反向代理最为常见,Ingress Controller 和 Service Mesh 日渐兴起)实现的用例。
对于一个工具必须具备哪些功能才能充当 API 网关,业界尚未达成共识。我们发现,客户通常需要以下能力(按用例分):
几乎上述所有用例在 Kubernetes 中都很常见。协议转换以及请求/响应标头和正文操作相对少见一些,因为它们通常与不太适合 Kubernetes 和微服务环境的传统 API 相关联。
如欲了解有关 API 网关用例的更多信息,请参阅我们的博文“将 NGINX 部署为 API 网关(第 1 部分)” 。
Ingress controller(也叫 Kubernetes Ingress Controller,简称 KIC)是一个专用的四层和七层代理,用于管理进出 Kubernetes 环境和服务的流量(称为出入向流量或南北向流量)。除了流量管理之外,Ingress Controller 还可提供可视化和故障排除、安全防护和身份验证,并且几乎可以实现最高级的 API 网关用例。
如欲了解关于 Ingress Controller 基本流量管理之外的功能,请参阅我们的博文“Ingress Controller 选购指南,第 1 部分:确定您的需求”。
Service Mesh负责处理 Kubernetes service 之间的流量(简称 service 到 service 流量或东西向流量),通常用于实现端到端加密 (E2EE)。随着越来越多的企业开启高级部署或产生 E2EE 需求,原本应用较少的 Service Mesh 正日益受到更多关注。Service Mesh 能够在非常靠近应用的地方用作分布式(轻量级)API 网关,这可以通过 Service Meshsidecar在数据平面上实现。
如欲了解有关 Service Mesh 以及使用场景的更多信息,或准备使用 Service Mesh 请参阅我们的博文“如何选择 Service Mesh”。
Mark Church 在 NGINX Sprint 2.0 主旨演讲“Kubernetes 和应用网络的未来”中说道,“未来,API 网关、负载均衡器和 Service Mesh 的特征和功能将会变得越来越相近”。我们完全同意这种说法,但我们的侧重点是如何根据工具的使用位置(或方式)选择合适的工具。毕竟合适的才是好用的。
那么如何确定哪种工具适合您呢?我们有个简单的办法:如果您需要在 Kubernetes 内使用 API 网关功能,通常来说最好选择可以使用 Kubernetes 原生配置工具(例如 YAML)进行配置的工具,也就是 Ingress Controller 或 Service Mesh。但有人疑惑:“我的 API 网关工具的功能比 Ingress Controller(或 Service Mesh)多很多,是我忽略了什么吗?”不是!功能越多不等于工具越好,尤其在 Kubernetes 中,工具太过复杂反而会成为一大致命因素。
注:“Kubernetes 原生”(不同于Knative)指专门为 Kubernetes 设计和构建的工具。通常,它们与 Kubernetes CLI 一起使用,可以使用 Helm 安装,并与 Kubernetes 功能集成。
大多数 Kubernetes 用户更喜欢以 Kubernetes 原生方式配置的工具,因为这样可以避免调整开发或 GitOps 体验。YAML 友好型工具有三大优势:
Ingress Controller 能够支持多种 API 网关用例。除了上文“定义”中所述的用例之外,我们发现企业最看重可以实现以下功能的 Ingress Controller:
若您想要实现方法级的匹配和路由,您需要使用 Ingress Controller 来拒绝 API 请求中的POST
方法。
一些攻击者会通过发送不符合 API 定义的请求类型来寻找 API 中的漏洞,例如向定义为只接收GET
请求的 API 发送POST
请求。Web 应用防火墙 (WAF) 无法检测到这些类型的攻击(它们只检查攻击的请求字符串和正文),因此最好在 Ingress 层中使用 API 网关,以阻止恶意请求。
举例来说,假设您的集群刚刚添加了新的 API/coffee/{coffee-store}/brand
。第一步是使用 NGINX Ingress Controller 暴露 API(只需将 API 添加到upstreams
字段)。
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80
要启用方法级匹配(method-level matching),您应在routes
字段中添加/coffee/{coffee-store}/brand
路径,并添加两个使用$request_method
变量的conditions
,以区分GET
和POST
请求。任何使用 HTTPGET
方法的流量都会自动传递到coffee
服务。使用POST
方法的流量将被定向到一个错误页面,并提示"You``are``rejected!"
这样,您就可以保护新 API 不受非法POST
流量的影响。
routes:
- path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "You are rejected!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea
有关如何使用方法级路由和匹配并弹出错误页面的更多信息,请参阅NGINX Ingress Controller 文档。有关使用 Ingress Controller 实现 API 网关功能的安全性相关的示例,请阅读我们博文“借助 Okta 和 NGINX Ingress Controller 实现 Kubernetes 的 OpenID Connect 身份验证”。
对于大多数 API 网关用例来说,Service Mesh 不是必需的,甚至一开始也不会提供任何帮助,因为您想做的大多数事情都可以在 Ingress 层完成,也理应在这里完成。但随着架构复杂性的增加,Service Mesh 的价值也将日益彰显。我们发现,E2EE 和流量分割用例(例如 A/B 测试、灰度部署和蓝绿部署)最能体现 Service Mesh 的价值。
您希望使用基于 HTTP/S 标准的条件路由在服务之间设置灰度部署。
这样做的好处是,您可以逐步实施 API 变更(例如新功能或新版本),而不会影响大部分的生产流量。
目前,您的 NGINX Ingress Controller 能够路由 NGINX Service Mesh 托管的两个服务(Coffee.frontdoor.svc
和Tea.frontdoor.svc
)之间的流量。这些服务接收来自 NGINX Ingress Controller 的流量,并将其路由到适当的应用功能,包括Tea.cream1.svc
。您决定重构Tea.cream1.svc
,并调用新版本Tea.cream2.svc
。您希望 Beta 测试人员提供有关新功能的反馈,因此您根据 Beta 测试人员的唯一会话 cookie 配置灰度流量分割,从而确保您的普通用户仅体验Tea.cream1.svc
。
要使用 NGINX Service Mesh,您首先需要在Tea.frontdoor.svc
(包括Tea.cream1.svc
和Tea.cream2.svc
)前端的所有服务之间创建一个流量分割。要启用条件路由,您需要创建一个HTTPRouteGroup
资源(名为tea-hrg
),并将其与流量分割相关联,确保只有来自 Beta 用户的请求(会话 cookie 设置为version=beta
的请求)可以从Tea.frontdoor.svc
路由到Tea.cream2.svc
。您的普通用户仍然只体验Tea.frontdoor.svc
后端的版本 1 服务。
apiVersion: split.smi-spec.io/v1alpha3
kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg
apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"
此示例的灰度部署使用 0-100 分割,这意味着您的所有 Beta 测试人员都将体验Tea.cream2.svc
,当然,您也可以根据您的 Beta 测试策略选择合适的比例。Beta 测试完成后,您可以使用一个简单的灰度部署(不包含 cookie 路由)来测试Tea.cream2.svc
的弹性。
有关 NGINX Service Mesh 流量分割的更多信息,请参阅我们的文档。上面的流量分割配置是自引用的,因为根服务也被列为后端服务。Service Mesh 接口规范(smi-spec) 目前不支持此配置,但是该规范目前处于 alpha 阶段,可能会进行修改。
虽然 Kubernetes 的大多数 API 网关用例可以(并且应该)用 Ingress Controller 或 Service Mesh 解决,但在一些特殊情况下 API 网关工具(例如 NGINX Plus)也适用。
虽然多个团队或项目可以使用同一套 Ingress Controller,也可以在不同的环境中使用不同的 Ingress Controller,但出于各种原因,您可能会选择在 Kubernetes 内部部署专用的 API 网关,而不是利用现有的 Ingress Controller。在 Kubernetes 中同时使用 Ingress Controller 和 API 网关可以为企业提供出色的灵活性以满足业务需求。部分场景包括:
在将现有 API 迁移到 Kubernetes 环境中时,您可以将这些 API 发布到部署在 Kubernetes 外部的 API 网关工具上。在这种情况下,API 流量通常通过外部负载均衡器(用于集群之间的负载均衡)进行路由,然后进入被配置为 API 网关的负载均衡器,最后进入 Kubernetes 集群中的 Ingress Controller。
虽然大多数现代 API 都是使用 REST 创建的(部分原因是 RESTful 或 gRPC 服务和 API 能够充分利用 Kubernetes 平台),但您可能仍有一些 SOAP API 没有进行重新架构。虽然我们不建议在 Kubernetes 中使用 SOAP API(因为它没有针对微服务进行优化),但是在还没有重新生成架构前您可能还是需要在 Kubernetes 中部署它的。API 有可能需要与基于 REST 的 API 客户端通信,在这种情况下,您需要一种在 SOAP 和 REST 协议之间进行转换的方法。虽然您可以使用 Ingress Controller 执行此功能,但我们不建议您这样做,因为这种做法非常耗费资源。我们建议您按 pod 或按服务将 API 网关工具部署为代理,以便在 SOAP 和 REST 之间进行转换。
我们还有一小部分客户比较关注 Kubernetes 内外的 API 流量管理。如果 API 管理策略的优先级高于选择 Kubernetes 原生工具,那么部署在 Kubernetes 中的“Kubernetes 友好型”API 网关(可以与 API 管理解决方案集成)可能是您正确的选择。
**注:**与 Kubernetes 原生工具不同,_Kubernetes 友好型_工具(有时也称为_Kubernetes 适应型_工具)不是专为 Kubernetes 设计的,不能使用 Kubernetes 配置来管理。但是,它们轻巧便捷,便于在 Kubernetes 中执行,既不会显著增加延迟,也无需进行大量的变通。
NGINX 为上述三种部署场景提供了选项。
Kubernetes 原生工具:
欢迎申请 NGINX Ingress Controller(带有 NGINX App Protect WAF 和 DoS)30 天免费试用版,并下载永久免费的 NGINX Service Mesh。
对于 Kubernetes 环境内外的 Kubernetes 友好型 API 网关:
更多资源
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源?
请前往 NGINX 开源社区:
|