背景
我正在使用Docker对一组服务进行容器化，并在AWS上部署。无论选择哪种部署方案（例如原始的EC2 / ECS / Elastic Beanstalk / Fargate），我们都将面临“服务发现”的问题。
以下是我考虑过的一些服务发现选项：
- AWS Route 53服务注册表
- Kubernetes
- Hashicorp Consul
- Spring Cloud Netflix Eureka
我的堆栈规范
我正在使用Java Spring Boot应用程序和Spring Cloud进行开发，目标部署环境是AWS。
鉴于我的堆栈基于Spring，我在本地开发时选择了Spring Cloud Eureka。它很容易设置单个节点，与所选的堆栈和生态系统集成得很好，并且需要非常少的设置。
在本地，我们使用docker compose（而不是swarm）来部署服务 - 部署的容器之一是单个节点的Eureka服务发现服务器。
但是，当我们进入到预发布或生产环境时，我们会考虑像Kubernetes这样的选项。
我的利弊评估
AWS Route 53服务注册表
需要我们将代码特别耦合到AWS服务。这本身不是问题，因为我们在堆栈的其他部分（SNS / SQS）上已经相当耦合了。
使得在本地开发时运行堆栈稍微困难一些，因为它依赖于Route 53。我想我们可以为本地开发打开某个托管区域。
AWS本身就支持，无需管理服务注册表或额外的“移动部件”。
Spring Cloud 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已提供了这个功能，使用eureka来执行发现似乎不是最佳方案。我推断Kube可以做出一些影响可用性和稳定性的优化，这可能无法使用eureka实现。例如，当部署新服务时，Kube会知道，而eureka将不得不依赖心跳/健康检查，并根据配置（例如频率）可能导致过期记录，而我推断Kube在计划的服务关闭/重启方面可能不会遭受这种困扰。我想对于未经计划的故障，例如主机故障或网络分区，仍然会存在这种情况。
有人对此有什么建议吗？人们是否使用像Kubernetes这样的服务，但使用其他机制进行服务发现而不是Kube提供的那些？是否有充分的理由选择其中之一？
可能遇到的挑战
我们可以替换eureka，但依赖Kube执行发现意味着我们需要在本地运行kube来部署，而目前我们只有一个简单的小docker-compose文件。此外，我将不得不看一下如何轻松确保ribbon、zuul和feign与此兼容。
当前，我们已经配置了ribbon并具有eureka客户端，以便服务A可以像“service-b”一样提供给服务B，并通过eureka客户端解析出一个健康主机。我猜我们可以配置ribbon不使用eureka，而使用外部的Kube服务名称，该名称将在运行时由Kube DNS解析...
最后说明
感谢任何贡献或建议。我知道这可能会引起主要关注意见的回应。但我希望有人能够提供客观指导，说明何时一种解决方案可能比另一种更可取。