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

是的，第一次进入听起来不错。

对于2来说，这听起来像您只需要指向入口控制器的通配符DNS。通配符DNS条目应说明* .domain.com应指向入口控制器的外部IP。然后，可以部署基于主机的Ingress规则/资源，并可以根据请求中指定的主机将流量路由到适当的服务。因此，只要“ abdomain.com”将转到入口控制器，请求的DNS的通配符部分中的内容就无关紧要，然后它将取决于入口资源中的什么规则以及结束位置起来

从客户将要在两台主机上公开该服务的情况下，他们将不得不部署一两个Ingress规则的意义上来说，这不是“自动”的。但是，如果客户对部署Ingress资源感到满意，那么他们也应该对此感到满意。

我认为您不需要任何更动态的内容，因为在“ helloworld.awesome-customer.com”中，似乎“ helloworld”是该服务，因此可以填充您的主机，因此Ingress规则本身无需通配符。如果他们要求的是“ v1.helloworld.awesome-customer.com”和“ v2.helloworld.awesome-customer.com”，并且两者都包含在其中，那么这将是更加动态且更像您指向的示例包含通配符的入口条目（而不是两个条目，每个版本一个）。但是似乎他们并没有要求。

这还是我如何看待客户领域的一部分。我不确定您对集群域部分的含义-为此，我需要更好地了解其访问方式。大概还是通配符DNS指向进行路由的内容，但是我不确定在那里进行路由的方式。如果要实现此目标，则可能是另一个通配符DNS条目指向相同的入口控制器，并部署了其他入口资源。