如何解决Kubernetes Ingress是否应该与Spring Cloud Gateway一起生活?
小型建筑/设计问题:
Kubernetes Ingress应该和Spring Cloud Gateway一起生活吗?如果不是,应该选择哪一个?
首先,通过一个Spring Webflux / Spring Cloud Gateway项目,我设法进行了基于路由的转发。意思是,我所有的客户只需要知道这个唯一的Spring Cloud Gateway端点,如果URL包含serviceA,Spring Cloud Gateway将直接转发给serviceA,如果serviceB等,则转发给serviceB,等等。
我添加了更多“软件级功能”,例如动态配置(在运行时更改路由),断路器,速率限制,舱壁和其他一些功能,非常酷,但实际上,我最终使用了路由转发是主要功能。
几周后,我花了一些时间研究Kubernetes,更确切地说是Kubernetes Ingress。 我设法学习到Kubernetes Ingress是一件非常酷而强大的事情。我设法至少执行了基于路由的转发。 意思是,客户端只需要知道这个唯一的Ingress端点,Ingress就会转发到Kubernetes集群中的基础服务。从现在开始,它将所有内容转发到Spring Cloud Gateway,后者将转发到其他所有内容。我尝试过,它可能首先可以转发到真实的业务服务。
这是我怀疑的时刻。
我只是重复工作了吗? (我的意思是从功能上讲,我在学习这两个方面都很有趣。)
我应该考虑一个架构,其中Spring Cloud Gateway(仅他)确实在做门控吗?
我是否应该考虑在Ingress和Software Gateway都具有高度重要性的架构中同时配置两者的功能? (接受重复的作品吗?)
我应该完全删除Spring Cloud Gateway吗?
谢谢
解决方法
我认为,Kubernetes必须与Spring Cloud Gateway一起生活。
反向代理具有诸如中央日志记录,安全性,缓存,路由,流量管理功能等功能,但是还有一些他们无法做到的事情。此时,API网关开始发挥作用。它们具有反向代理的所有功能,此外还具有其他功能,它们是无法做到的。因此,API网关称为增强型反向代理。
因此Kubernetes入口就像反向代理一样,而Spring Cloud Gateway是API网关模式的实现。正如我在上面的定义中提到的,我只能说几句Kubernetes无法做到的事情。
- 您可以实现API组合吗?否
- 您可以通过Kubernetes实现JWT身份验证吗?如果是这样,您能否通过Kubernetes将超过8 KB的JWT承载到下游服务?否
- 您可以结合Kubernetes的所有Swagger / Open API文档吗?否
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。