Kubernetes客户子域动态绑定

Question

我有以下用例：

1. 我们的客户经常在其 K8s 集群上发布新服务。 这些新服务可通过负载平衡和 Ingress 从外部访问，以便在部署服务后动态配置此负载平衡。这让我们客户的开发团队变得非常容易，因为他们不必等到有人手动配置负载平衡。他们只需在服务部署旁边创建自己的 Ingress 资源，即可访问该服务。

2. 一位客户询问我们是否也可以启用它的每个服务都可以自动拥有自己的子域。因此，一旦部署了新的应用程序，它应该可以作为集群域的子域（例如 https://helloworld.cyvh5.k8s.ginger.aws.gigantic.io）以及它们自己的子域（例如 helloworld.awesome-customer.com）。

我已经找到this resource 作为起点。

我的问题是：

1. 我能否以其他（更好的）方式实现客户子域动态绑定？

2. 建议的解决方案可能存在哪些限制/缺陷？

谢谢！

Answer 1

是的，1 次入口听起来很棒。

在我看来，对于 2，您只需要指向入口控制器的通配符 DNS。通配符 DNS 条目应该说 *.domain.com 应该指向入口控制器的外部 IP。然后可以部署基于主机的入口规则/资源，并且可以根据请求中指定的主机将流量路由到适当的服务。因此，只要“abdomain.com”将进入入口控制器，请求的 DNS 通配符部分中的内容并不重要，然后它将取决于入口资源中的哪些规则来确定它的结束位置向上。

这不会是“自动的”，因为如果客户希望在两台主机上公开服务，他们必须部署一两个 Ingress 规则。但是，如果客户对部署 Ingress 资源感到满意，那么他们也应该对此感到满意。

我认为您不需要任何更动态的内容，因为在“helloworld.awesome-customer.com”中，“helloworld”似乎是一项服务，因此可以填写您的主机，因此 Ingress 规则本身不需要通配符.如果他们要求'v1.helloworld.awesome-customer.com'和'v2.helloworld.awesome-customer.com'并且两者都被一个覆盖包含通配符的入口条目（而不是两个条目，每个版本一个）。但似乎他们并没有要求这样做。

这就是我对客户域部分的看法。我不完全确定您对集群域部分的含义 - 因为我需要更好地了解它是如何访问的。大概它又是通配符 DNS 指向正在路由的东西，但我不确定那里的路由是什么。如果重点是您想要实现这一点，那么它可能只是另一个通配符 DNS 条目，指向同一个入口控制器，并部署了额外的入口资源。