BKPR without custom domain

[janbols]

Hi,

can I use BKPR without a custom domain registration. I like the out-of-the-box experience of BKPR but I don't want to register a custom domain. Would there be a solution for this?

[falfaro]

I believe you can leave out the custom domain. On which platform is this? AKS? GKE?

Also, how do you plan then on reaching the Ingress resources like Grafana, Prometheus or Kibana? The custom domain is used by BKPR to automatically configure things behind an Ingress to be reachable from outside the Kubernetes cluster.

[anguslees]

@janbols As falfaro points out, we need a domain name so that users can use it to access the various consoles. We need it to be a "real" domain name so that we can get a valid TLS certificate (via letsencrypt/ACME). You can give it a fake name (eg --dns-zone not.a.real.domain), and BKPR should install but the web consoles will be inaccessible.

We understand the DNS requirement is the biggest hurdle to "casual" experiments with BKPR. We have some crazy ideas that would improve this, but they're still theoretical at this point. Proposals/patches welcome.

[janbols]

Hi, I did not express myself correctly. Sorry for that.

In AKS, whenever you create a k8s service with an external IP address, a public IP azure resource (Microsoft.Network/publicIPAddresses) is created in the k8s-resource group. You can configure that azure resource to add an A-record to the azure-provided dns servers. The name will then be something like my-app-name.eastus.cloudapp.azure.com. It would be cool to be able to reuse this dns-name. The problem here is that you can't register something like grafana.my-app-name.eastus.cloudapp.azure.com or kibana.my-app-name.eastus.cloudapp.azure.com. Instead, those endpoints should point to something like my-app-name.eastus.cloudapp.azure.com/grafana etc.

Please take a look at https://docs.microsoft.com/en-us/azure/aks/ingress-tls#configure-a-dns-name for more information about registering a DNS name on the public IP.

Does this make sense?

Best regards

[anguslees]

Does this make sense?

@janbols: yes, and thanks for the followup.

We initially avoided moving to URL paths (behind a single hostname) because that placed more demands on the application (internal links have to also support the new path prefix, etc), can allow cookies to leak between sites, and still requires the cloud to give you a DNS entry for the ingress LB. I agree that it's an attractive "just works" compromise however.

There are lots of other variations here as well - we could create multiple LBs, and use this to get multiple LB hostnames as a side-effect (for example).

Several of the clouds offer a DNS registrar service already too, so we could also just create a new DNS domain as part of kubeprod install (unless an existing DNS domain was specified). In the scheme of things, paying for a new DNS domain is small compared to the cost of the k8s cluster VMs and other resources that you're presumably also running.

[akin-ozer]

I recently came up with use case for this. When we install a cluster for each of our clients(not main cluster but for streaming software stack), we need naming handled by public IPs because unified naming could cause some security issues(like guessing dns adress or other clients). We are using AKS and if it handled within 1 public ip for ingress and apps(grafana, prometheus, our web based app etc.), it would be very feasible for us.