Ingress无疑是一个可能的解决方案。
您需要在集群中部署一个Ingress controller（例如https://github.com/kubernetes/ingress-nginx），而不是像前面那样使用LoadBalancer类型的Service公开它。
在route53中，您需要将任何希望由ingress控制器提供服务的域名指向ELB的名称，就像您之前所做的那样。
您需要做的最后一件事是为您希望ingress控制器知道的每个域创建Ingress资源（更多信息请参见：https://kubernetes.io/docs/concepts/services-networking/ingress/）。
也就是说，如果你计划在你的集群中只有2个公共URL，我会使用2个ELB。Ingress控制器是集群中需要维护/监控的另一个组件，因此在评估权衡时要考虑到这一点。

这是一个伟大的问题！我不得不说，@whites11的答案在2018年是完美的，而且仍然非常正确。但是五年后，我们有了更多的选择，所以让我们谈谈这个！
首先，最简单的做法可能是用自己的LoadBalancer服务公开每个URL（production.somesite.com和staging.somesite.com）。然后，对于每个服务，检索其EXTERNAL-IP（在AWS上，实际上是一个名称，而不是IP地址），并设置一个CNAME记录。production.somesite.com指向相应的ELB。
优点：简单，因为你不需要安装任何东西。您还可以解耦所有DNS操作（您的域名可以托管在Route 53或其他任何东西上）。
缺点：价格，因为你为每个以这种方式暴露的服务支付一个ELB。对于几个URL，这并不重要;但如果你有几十个甚至几百个这样的人，那就成了一个问题。此外，每个服务都需要额外的手动步骤来设置相应的DNS记录。
下一个选项是使用Ingress控制器。Ingress控制器本质上是一个负载均衡器，它“说”HTTP（从技术上讲，它解析HTTP请求），因此，它能够进行 * 基于内容的路由 。这是一种奇特的方式，可以说Ingress控制器可以查看请求的内容，并且根据主机头（production.somesite.com或staging.somesite.com）甚至URI（/hello.html或/static/theme.css或/api/v1/users/42），它可以将该请求发送到不同的Kubernetes Service。
如果我们决定走这条路（没有双关语），它变得棘手，因为我们有 * 这么多的选择！
粗略地说，我们有像Ingress NGINX或Traefik这样的Ingress控制器，它们可以部署在几乎任何类型的Kubernetes集群上-云、内部部署、家庭实验室，甚至像KinD或Minikube这样的本地集群。
然后我们有特定于云的Ingress控制器，如AWS Load Balancer Controller（以前称为“ALB Ingress”）或GKE Ingress。
特定于云的Ingress控制器的优点是它们可以为我们的流量提供更短的路径，因为它会做这样的事情：
HTTP客户端→ Ingress LB → HTTP服务器Pod
当使用例如Nginx或Traefik在云中通常会做这样的事情：
HTTP client → Cloud LB → Ingress Pod → HTTP server Pod
乍一看，节省一跳似乎是一件大事;但并不总是这样这是内部流量，这意味着它 * 通常 * 非常快（比如，1 ms）并且非常便宜（外部流量成本的一小部分）。如果将HTTP响应时间缩短1毫秒对您很重要，或者如果您有大量的内部HTTP流量（即，不是来自外部HTTP客户端），然后尽一切可能检查您的云特定Ingress控制器。另一方面，设置AWS负载均衡器控制器可能要复杂得多，涉及额外的IAM和网络配置，并且需要使用AWS VPC CNI（换句话说：不是Calico或越来越受欢迎的Cilium）。同时，“通用”Ingress控制器可以使用一行命令安装，该命令将“正常工作”，并与您可能使用的几乎任何Kubernetes集群和CNI插件兼容。
请注意，我们之前说过“在云中”。如果你在本地，很有可能（也很常见）使用例如。一个DaemonSet和hostPort，然后返回到如下的流量路径：
HTTP客户端→ Ingress Pod → HTTP服务器Pod
对于一个只有两个URL的简单场景，我们可以在这里结束。但是很多部署Kubernetes的人正在利用它来运行更多的应用程序，并且可能会定期添加新的应用程序。这是另一个项目可能值得一提的地方：ExternalDNS。
ExternalDNS会自动管理DNS记录，因此当您创建production.somesite.com的Ingress资源，它创建指向其Ingress控制器的IP地址的相应DNS记录。这消除了我们原始过程中的手动步骤，当您拥有的不仅仅是几个URL，而是几十个URL时，和/或如果您不断添加，删除甚至将这些URL从一个集群移动到另一个集群时，这特别方便：ExternalDNS将确保它们始终指向正确的位置。ExternalDNS支持Route 53以及30多个其他DNS提供商（SAAS和自托管服务器）。
你可以做的另一件事是利用DNS记录。例如，您可以将*.wild.somesite.comMap到Ingress控制器LoadBalancer地址。然后，每当您为<anything>.wild.somesite.com创建Ingress时，您都不需要添加新的DNS记录，因为它已经被DNS记录所覆盖。这意味着您将不需要ExternalDNS，* 并且 * 它可以减少网站可访问的时间（因为某些DNS提供商可能需要一分钟或几分钟才能在线记录）。

此外，如果你想通过HTTPS公开你的应用和网站，你可以将cert-manager与Let's Encrypt或ZeroSSL等服务结合使用，自动生成密钥对，并为每个应用获取有效的TLS证书。
最后一件事！由于最初的问题要求staging具有受限的访问权限-虽然这不是可以通过Kubernetes Ingress资源以标准方式完成的事情，但大多数Ingress控制器都支持特定于供应商的方式来添加自定义配置。您可以查看NGINX Ingress documentation以获取该功能的示例，它允许（几乎）任何NGINX配置指令。好耶！