Kubernetes 我应该使用API网关还是服务网格？

假设您正在对Docker容器和Kubernetes使用微服务

---

如果您在微服务前面使用API网关（例如Azure API网关）来处理复合UI和身份验证，您是否仍然需要服务网格来处理服务发现和断路器？Azure API网关中是否有任何功能可以应对此类挑战？怎么做

API网关只处理Kubernetes群集的入口点，例如，它向前端微服务发送请求。但是，在请求进入集群后，它将无能为力。微服务之间可能仍有多个调用。您仍然希望验证这些请求的身份验证，您仍然希望确保服务之间存在断路器等。理论上，您可以确保所有微服务通过API网关相互调用，但我认为这不是您想要的

---

简而言之：不，因为API网关只是一个入口点，使用服务网格可以更好地处理任何服务到服务的通信。

您可以使用API网关来处理服务发现和断路器-但这将使其成为部署的中心点，即所有外部和内部调用都必须通过网关路由

服务网格在每个服务旁边部署一个额外的边缘组件（“侧车”），使整体行为分布（但也更复杂）

---

根据您的特殊要求，您可以使用一个或另一个，在OSI模型的第7层上应用两个或无API网关，或者您可以说管理来自外部网络的流量（有时也称为北/南流量），然而，服务网格应用于OSI模型的第4层或管理器服务间通信（有时也称为东/西通信）。API网关功能的一些示例包括反向代理、负载平衡、身份验证和授权、IP列表、速率限制等

另一方面，服务网格的工作方式类似于代理或侧车模式，它将服务的通信责任解耦，并处理断路器、超时、重试、服务发现等其他问题

---

如果您碰巧使用了Kubernetes和微服务，那么您可能希望探索其他解决方案，例如或作为网关和服务网格的解决方案。

上面fatcook很好地解释了这一点。。看

---

因为这正试图在Azure上执行与Kong相同的操作。API网关+处理控制平面级功能

谢谢你Blokje5，在我接受你的回答之前，我需要确定，为什么API网关供应商说你甚至可以使用API网关进行服务发现和断路器等？谢谢，fatcook。我们将使用Azure API管理作为API网关，并使用Istio的AKS来处理断路器和服务发现。