kubernetes - 使用 eureka 与 kubernetes 进行服务发现的缺点

Question

上下文

我正在将一组使用 Docker 容器化的服务部署到 AWS 中。无论选择哪种部署解决方案(例如原始 EC2/ECS/Elastic Beanstalk/Fargate)，我们都会面临“服务发现”的问题。

仅举几个我考虑过的服务发现选项:

AWS Route 53 服务注册

Kubernetes

Hashicorp 领事

Spring Cloud Netflix Eureka

我的堆栈的细节

我正在使用 Spring Cloud 开发 Java Spring Boot 应用程序，目标部署环境为 AWS。

鉴于我的堆栈是基于 Spring 的，spring cloud eureka 在本地开发时对我来说很有意义。设置单个节点很容易，与选择的堆栈和生态系统很好地集成，并且只需要很少的设置。

在本地，我们使用 docker compose(不是 swarm)来部署服务——部署的容器之一是单节点 Eureka 服务发现服务器。

然而，当我们在本地开发之外进入临时或生产环境时，我们正在考虑像 Kubernetes 这样的选项。

我自己的利弊评估

AWS Route 53 服务注册表

要求我们专门将代码耦合到 AWS 服务。本身不是问题，无论如何我们在堆栈的其他部分(SNS/SQS)上都非常紧密。

由于它依赖于 Route 53，使得在本地运行堆栈稍微困难一些，我想我们可以为本地开发开放某个托管区域。

AWS 原生，无需管理服务注册表或额外的“移动部件”。

春云 Eureka

缺点是因此需要我们部署和管理高可用性服务注册表集群并需要更多资源。另一个要管理的“事件部分”。

优点是它非常适合我们的堆栈(spring 生态系统、spring boot、spring cloud、feign 和 zuul 与此配合良好)。也可以在本地运行。

我想我们需要配置网络和注册表区域以确保客户端发布他们的主机地址而不是 docker 容器内部 IP 地址。例如如果服务 A 在主机 A 上并且想要与主机 B 上的服务 B 通信，则服务 B 需要通告其 EC2 地址而不是某些内部 docker IP。

问题

如果我们使用 Kubernetes 进行编排，那么使用 Spring Cloud Eureka 之类的东西而不是这里描述的内置服务发现选项有什么缺点 https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services

鉴于 Kube 提供了这一点，然后使用使用 kube 部署的 eureka 来执行发现似乎不是最佳选择。我认为 kube 可以进行一些影响可用性和稳定性的优化，而使用 eureka 可能是不可能的。例如，kube 在部署新服务时会知道 - eureka 将不得不依赖心跳/健康检查，并且取决于它的配置方式(例如频率)，这可能会导致陈旧的记录，而我认为 kube 可能不会因计划的服务关闭而受到影响/重新启动。我猜它仍然适用于计划外的故障，例如主机故障或网络分区。

有没有人对此有任何建议，人们是否使用像 Kubernetes 这样的服务，但使用其他机制进行服务发现，而不是 kube 提供的机制。是否有充分的理由去做其中之一？

我预期的可能挑战

我们可以替换 eureka，但依赖 Kube 执行发现意味着我们需要在本地运行 kube 进行部署，而目前我们有一个简单的小型 docker-compose 文件。此外，我还必须看看确保 Ribbon、zuul 和 feign 很好地与此配合使用有多容易。

目前，我们已经为 Ribbon 配置了一个 eureka 客户端，这样服务 A 就可以像“service-b”一样为服务 B 服务，并让 Ribbon 通过 eureka 客户端解析一个健康的主机。我想我们可以将功能区配置为不使用 eureka 并使用外部 Kube 服务名称，该名称将在运行时由 Kube DNS 解析......

最后说明

在此先感谢您的任何贡献或建议。我知道这可能会引起主要以意见为中心的回应。但我希望有人能够就一种解决方案何时可能优于另一种解决方案提供客观指导。

Answer 1

服务发现是您在 Kubernetes 中开箱即用的东西。因此，在您的平台中拥有另一个外部服务将是另一个需要维护、部署的应用程序，并且可能成为故障点。所以我会坚持使用 Kubernetes 提供的服务发现。