如何在Kubernetes中选择API网关？

Question

我们在微服务场景中使用 Zuul 作为 API 网关已经有一段时间了，最​​近我们决定迁移到 Kubernetes 并选择一种更加云原生的方式。

经过一番调查和阅读 Istio 文档，我们对 Kubernetes 中的 API 网关选择有一些疑问：

• 在Kubernetes中选择API网关应该考虑哪些方面？
• 如果我们使用 Istio，我们还需要 Zuul 吗？

Answer 1

我认为Zuul提供了许多功能作为流量管理、路由和安全功能的边缘服务。它必须根据微服务架构模式设计将 API 网关声明为外部客户端访问微服务的主要点。但是，Zuul 需要以某种方式发现底层微服务，对于 Kubernetes，您可能需要调整 Kubernetes 发现客户端，它定义了 API 网关如何检测路由并将网络流量传输到嵌套服务的规则。

按照设计，Istio 代表服务网格架构，并成为面向 Kubernetes 的解决方案，并且集成顺畅。这里的主要概念是通过将 sidecar 注入 Kubernetes Pod来使用高级版本的Envoy代理，无需更改或重写现有部署或使用任何其他方法进行服务发现。Zuul API 网关可以完全被 Istio网关资源替代，作为入口或出口 HTTP(S)/TCP 连接的边缘负载均衡器。Istio 包含一组可以包含在常规配置中的流量管理功能。

您可能对功能性 Istio 设施的其他基本概念感兴趣，例如：

• 授权模式；

• 认证政策；

• Istio遥测和 Mixer 策略。