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 等不变。