当你使用 Kubernetes 时，你真的需要另一个服务发现或 Kubernetes 内部的 API 网关解决方案吗？答案

【问题标题】：When you use Kubernetes, do you really need another Service Discovery or an API Gateway Solution inside kubernetes?当你使用 Kubernetes 时，你真的需要另一个服务发现或 Kubernetes 内部的 API 网关解决方案吗？
【发布时间】：2019-11-18 09:01:58
【问题描述】：

我们最近开始使用 Kubernetes。我们正在两个主 HA 集群和大约 8 个从节点上积极地从 Docker Swarm 集群迁移到 Kubernetes。 4个每个给一个主人。我们为我们的服务使用 Spring Boot，Spring 建议我们使用 Spring Cloud Gateway。
尽管kubernetes 网站说他们提供服务发现和负载平衡机制，但为什么有很多产品可以在 Kubernetes 上使用。
他们提供比 kubernetes 更好的产品吗？或者，如果我们使用其他提供商，我们是否会在 kubernetes 提供的基础上引入任何延迟？当我们使用其他提供商时，是否会发生向下钻取路线？我的意思是其他提供者进行发现，而 kubernetes 再次在其集群中进行另一轮发现？

【问题讨论】：

标签： docker kubernetes kubernetes-pod

【解决方案1】：

简短而令人不满意的答案：不要出汗。

尽可能使用原版 Kubernetes。任何偏差都会引入您需要管理的额外复杂性。如果这对您来说是值得的，请继续；）

这是什么意思？好吧，尽管您已经拥有一个集群，但您似乎或多或少处于旅程的开始阶段。因此，请关注手头的直接问题，例如迁移到 Kubernetes，而不是在遥远的将来可能会有所帮助。

例如，一旦您的架构成熟并且您需要，例如，API 网关将在未来变得有益。支持您的 API 的多个版本。但这并不意味着您需要从一开始就引入 API 网关。

【讨论】：

同意你。但是现在用 Kubernetes 的方式移动，以后我们会不会觉得很难从 Kubernetes 中割断绳索，转向另一种做事方式？我们很乐意使用原生 kube 函数并感到满意，但我们也不能最终重新发明轮子！
好点 - 如果可能的话，避免重新发明轮子会很好。例如根据您在问题中提供的信息，我假设您已经拥有一个 docker swarm 集群。您是否将它与 docker-compose 文件结合使用以进行应用程序部署？如果是，您应该能够使用 kompose 轻松迁移到 Kubernetes。您可以在此处找到教程：digitalocean.com/community/tutorials/…。 Kubernetes 的伟大之处在于您可以根据您接下来需要的内容对其进行扩展，例如API网关
是的。伟大的。将继续发布我们的迁移步骤。