API Gateway
网关, 就是指一个流量的集中式出入口. 而 API Gateway, 顾名思义, 就是在 Gateway 上再添加了一些 API 相关的功能后得到的东西.
具体而言, API Gateway 就是比普通的网关多干了一些以前我们在应用内部实现的事: 身份认证, 权限控制, 流量控制, 日志服务等. 好处有:
API Gateway 把这些功能都从微服务层抽离到了网关层, 降低了应用层的复杂度.
API Gateway 可以将后端微服务的 API 进一步封装成粗粒度 API, 降低客户端的请求次数.
API Gateway 可以将后端 API 封装成更通用的格式, 保证后端 API 变动不会影响客户端.
以 Kong 为例, 在 Kubernetes 中, 官方的 Ingress 定义只能进行简单的七层转发配置, 功能很弱, 以致于很多社区的 Ingerss 实现都得另辟蹊径来添加额外特性.(所以 Istio 自己也弄了一套 IngressGateway)
而作为一个 API Gateway,Kong 要比官方的 Ingress Controller 强大很多很多, 它首先兼容了 K8s 的 Ingress 定义, 然后又通过 CRD 添加了一些额外的功能 / 特性.
所有参数都以 K8s YAML 的形式保存与配置.
使用 JWT 时, 身份认证只需要 JWK 公钥 (登录时才需要私钥生成 JWT), 在 API Gateway 里设置好公钥, 就能统一进行身份认证.(缺点是无法撤销授权)
而使用 OAuth2 时, 需要单独的 OAuth2 认证服务器.
选择 API 网关
首先看一下 API Gateway - CNCF LandScape
API 网关的可选项还是挺多的, 老牌的 Kong, 以及国内才开源半年多的 APISIX, 还有其他的实现如 tyk/gloo.
眼花缭乱, 正在研究, 以后补充.
API Gateway 与 Service Mesh(服务网格)
Gateway 是控制集群流量的出入, 被称作南北向流量管理.
而 Service Mesh 是集群内部微服务之间的流量管控, 被称作东西向流量的管理.
这两个东西并不是非常的泾渭分明, 比如 Istio 作为一个服务网格, 也搞了一套自己的 IngressGateway 和 EgressGateway, 只是这两个 Gateway 并没有添加 API 相关的功能.
现在问题就来了: Istio 弄了一套自己的路由规则, Kong 又是以 k8s Ingress 为基础实现的 k8s 集成. 那如果我们要同时用这两个东西呢? 该怎么办? 我的配置到底是用 Istio IngressGateway 还是 Ingress?Kong 和 Istio 要如何交互?
Kong-Ingress-Controller 在去年 9 月发布的 0.6 版本中, 给出的解决方案是:
入口网关的规则使用 Kong Ingress 配置, 也就是抛弃掉 Istio 的 IngressGateway
Kong-Ingress-Controller 通过 Envoy SideCar 将流量导入到 Istio 服务网格中.
官方给的示意图如下, 可和 Istio 部署示意图 对比查看:
如何为服务网格选择入口网关? 里详细说明了上述集成方案的由来, 他给出的图比 Kong 官方的更清楚些:
Kong 使用 k8s Ingerss 和自己的 CRDs 替换掉了 Istio 官方的 Gateway,Istio 服务网格层的 VirtualService 等不变.
参考
谈谈微服务中的 API 网关 (API Gateway)
Kubernetes 中使用 API Gateway 替代 Ingress https://blog.joway.io/posts/kubernetes-gateway/
谈谈 API 网关 https://www.jianshu.com/p/b52a2773e75f
如何为服务网格选择入口网关?
API Gateway vs Service Mesh
基于 Apache APISIX 的下一代微服务架构 https://zhuanlan.zhihu.com/p/99693055
Kong Ingress Controller 0.6 Released with Support for Admission Controller, Istio, and Kuma
来源: http://www.bubuko.com/infodetail-3446912.html