Kubernetes Ingress 应该与 Spring Cloud Gateway 一起使用吗？

Question

请提出一些小的架构和设计问题。

\n

问题：\nKubernetes Ingress 应该与 Spring Cloud Gateway 一起使用吗？如果不是，应该优先选择哪一个？

\n

首先，通过 Spring Webflux / Spring Cloud Gateway 项目，我成功实现了基于路由的转发。这意味着，我的所有客户端只需要知道这个并且只有一个 Spring Cloud Gateway 端点，如果 URL 包含 serviceA，Spring Cloud Gateway 将转发到 serviceA，如果 URL 包含 serviceB，则 Spring Cloud Gateway 将转发到 serviceB，等等，简单明了。

\n

我添加了更多 \xe2\x80\x9c 软件级别功能 \xe2\x80\x9d 例如动态配置（在运行时更改路由）、断路器、速率限制、舱壁和其他一些功能，非常酷，但实际上，我最终使用路由转发作为主要功能。

\n

然后几周前，我花了一些时间研究 Kubernetes，更准确地说是 Kubernetes Ingress。\n我设法了解到 Kubernetes Ingress 是一个非常酷且强大的东西。我设法至少执行基于路由的转发。\n这意味着，客户端只需要知道这一个且唯一的 Ingress 端点，Ingress 将转发到 Kubernetes 集群内的底层服务。截至目前，它将所有内容转发到 Spring Cloud Gateway，Spring Cloud Gateway 将转发其他所有内容。我尝试过，它本来可以转发到真正的业务服务）。

\n

这就是我产生怀疑的时刻。

\n

我只是重复工作吗？（我的意思是就功能而言，我学习两者都很有趣）。

\n

我是否应该考虑一种由 Spring Cloud Gateway（只有他）真正负责控制的架构？

\n

我是否应该考虑一种入口和软件网关都具有完全重要性的架构，并在两者中配置功能？（接受重复的工作吗？）

\n

我应该完全删除 Spring Cloud Gateway 吗？

\n

谢谢

\n

Answer 1

在我看来，Kubernetes 必须与 Spring Cloud Gateway 共存。

反向代理具有中央日志记录、安全性、缓存、路由、流量管理功能等功能，但也有一些它们不能做的事情。API网关此时就发挥了作用。它们具有反向代理的所有功能，此外还具有它们所没有的额外功能。因此，API 网关被称为增强型反向代理。

因此，Kubernetes ingress 的作用类似于反向代理，而 Spring Cloud Gateway 是 API Gateway 模式的实现。正如我在上面的定义中提到的，我可以说一些 Kubernetes 无法做到的事情。

• 你能实现API组合吗？不
• 可以通过 Kubernetes 实现 JWT 身份验证吗？如果是这样，可以通过 Kubernetes 将超过 8 KB 的 JWT 承载到下游服务吗？不
• 您可以合并 Kubernetes 的所有 Swagger/Open API 文档吗？不