Kubernetes客户子域动态绑定 [英] Kubernetes customer subdomain dynamic binding

问题描述

我有以下用例:

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

1. Our customers frequently release new services on their K8s clusters. These new services are reachable from the outside world through a load balancing and Ingress to dynamically configure this load balancing once a service is deployed. This makes it really easy for the development teams of our customers because they don’t have to wait until somebody configures a load balancing manually. They can just create their own Ingress resource next to their service deployment and the service will be reachable.

一个客户询问我们是否也可以启用其每个服务可以自动拥有自己的子域的功能.因此，一旦部署了新应用程序，它就应该可以作为群集域的子域使用(例如

A customer asked if we can also enable that each of its services can have its own subdomain automatically. So once a new application is deployed it, it should be available as a subdomain of the cluster domain (e.g. https://helloworld.cyvh5.k8s.ginger.aws.gigantic.io) as well as at their own subdomain (e.g.. helloworld.awesome-customer.com).

我已经找到此资源作为起点.

我的问题是:

1. 我可以通过其他(更好)方式实现客户子域动态绑定吗?

建议的解决方案可能有哪些局限性/陷阱?

What are the possible limitations / pitfalls for the suggested solution?

谢谢！

推荐答案

是的，1次进入听起来不错.

Yeah for 1 ingress sounds great.

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

For 2 it sounds to me like you just need wildcard DNS pointing at the ingress controller. The wildcard DNS entry should say that *.domain.com should point to the ingress controller's external IP. Then host-based Ingress rules/resources can be deployed and traffic can be routed to the appropropriate Service based on the host specified in the request. So it doesn't matter what is in the wildcard part of the DNS of a request insofar as 'a.b.domain.com' will go to the ingress controller and it will then depend on what rules are in the Ingress resources as to where it ends up.

就客户要在两台主机上公开该服务的情况而言，客户将必须部署一两个Ingress规则，这将不是自动"的.但是，如果客户对部署Ingress资源感到满意，那么他们也应该对此感到满意.

This won't be 'automatic' in the sense that the customer will have to deploy an Ingress rule or two if they want the service exposed on two hosts. But if the customer is happy with deploying Ingress resources then they should be happy with this too.

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

I don't think you need anything more dynamic because in 'helloworld.awesome-customer.com' it seems 'helloworld' is the service so that fills out your host so there's no need for a wildcard in the Ingress rule itself. What would be more dynamic and more like the example you point to is if they were asking for 'v1.helloworld.awesome-customer.com' and 'v2.helloworld.awesome-customer.com' and for both to be covered by one Ingress entry containing a wildcard (rather than two entries, one per version). But it seems they are not asking for that.

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

This is how I see the customer domain part anyway. I am not exactly sure what you mean about the cluster domain part - for that I'd need to better understand how that is accessed. Presumably it is again wildcard DNS pointing at something doing routing but I'm not as sure about what is doing the routing there. If the point is that you want to achieve this then it could just be that it's another wildcard DNS entry pointed at the same ingress controller with additional Ingress resources deployed.

这篇关于Kubernetes客户子域动态绑定的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！