Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Domain or existing Zone #11060

Closed
mhabegger opened this Issue Jul 2, 2018 — with docs.microsoft.com · 15 comments

Comments

Projects
None yet
8 participants
Copy link

mhabegger commented Jul 2, 2018 — with docs.microsoft.com

Is there a way to set this feature to use a custom domain name or use a pre-existing Zone or to redirect custom domains to the aksapp.io domain ? What is the best practice or what are the plans on this features?


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@MicahMcKittrick-MSFT

This comment has been minimized.

Copy link
Contributor

MicahMcKittrick-MSFT commented Jul 2, 2018

Thanks for the question! We are investigating and will update you shortly.

@MicahMcKittrick-MSFT

This comment has been minimized.

Copy link
Contributor

MicahMcKittrick-MSFT commented Jul 2, 2018

@lachie83, @neilpeterson, @iainfoulds would any of you know if this is possible to achieve? If so, we might consider adding that info to the doc. Else, stating that it is not possible.

@michaelmsm89

This comment has been minimized.

Copy link

michaelmsm89 commented Jul 5, 2018

I'd really like to know the answer to this too. I want to use Dev Spaces but to do so I need to enable HTTP Routing, which I only want to do if I can use my existing Azure DNS zone with custom domain.

@MicahMcKittrick-MSFT

This comment has been minimized.

Copy link
Contributor

MicahMcKittrick-MSFT commented Jul 5, 2018

We are still looking into this but if this is more just for creating an additional DNS record that points to the AKS records there should be no issue in doing this. An Azure DNS zone and records are created for the cluster that provides the required resolution for cluster operations, but the DNS entry for actual production applications would typically be more user-friendly and use the TLD of a company that forwards traffic to the Azure DNS entry.

I am still working on an official answer though and will provide more as soon as I can.

@lachie83

This comment has been minimized.

Copy link
Contributor

lachie83 commented Jul 5, 2018

@mhabegger Thanks for asking. See my responses below

Is there a way to set this feature to use a custom domain name or use a pre-existing Zone or to redirect custom domains to the aksapp.io domain ? What is the best practice or what are the plans on this features?

No there is not. You could create a CNAME from your custom domain and point it at this A record as a possible solution. We currently have no plans to add customer domains or redirections to this feature. The good news is that you can do this completely using open source components and have that functionality. See https://youtu.be/9HQ2XgL9YVI

@mhabegger

This comment has been minimized.

Copy link
Author

mhabegger commented Jul 6, 2018

Thanks @lachie83
I am well aware that I can deploy my own pods that handle reverse proxy and TLS etc. But you realize that, for a fully managed Kubernetes and in for most usecases, the entire functionality “HTTP Application Routing” is rendered useless because as a customer I want to be able to deploy pods that would answer to URLs such as api.mydomain.com or portal.mydomain.com etc. If HTTP Application routing can only be deployed using Microsoft’s forced domain myservice..region.aksapp.io how can I even use this in non testing usecases?
The only part missing is that when enabling HTTP Application Routing I should be able to define a preexisting Zone.

@MicahMcKittrick-MSFT

This comment has been minimized.

Copy link
Contributor

MicahMcKittrick-MSFT commented Jul 6, 2018

Thanks @lachie83 for clarifying this for us!

@mhabegger if you feel this feature is something you would like to see implemented into the product we suggest leaving that feedback on UserVoice:

https://feedback.azure.com/forums/602224-azure-container-instances

This is where we have customer provide feature suggestions. Other users can upvote the feature and then depending on the number of asks the product teams and consider adding it into the product.

Please feel free to open that feature suggestion and share it on this issue for reference.

I will close this for now as there is no additional action required on this specific doc.

@mhabegger

This comment has been minimized.

Copy link
Author

mhabegger commented Jul 6, 2018

@lachie83

This comment has been minimized.

Copy link
Contributor

lachie83 commented Jul 6, 2018

@mhabegger Thank you very much for the feedback and valuable insight.

@sryabkov

This comment has been minimized.

Copy link
Contributor

sryabkov commented Jul 17, 2018

@lachie83

You could create a CNAME from your custom domain and point it at this A record as a possible solution.

This suggestion doesn't work for me, I get

default backend - 404

It makes sense that it doesn't work, because the Ingress definition includes the DNS zone name:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: party-clippy
  annotations:
    kubernetes.io/ingress.class: addon-http-application-routing
spec:
  rules:
  - host: party-clippy.<CLUSTER_SPECIFIC_DNS_ZONE>
    http:
      paths:
      - backend:
          serviceName: party-clippy
          servicePort: 80
        path: /

If I create a party-clippy CNAME record in <MY-DNS-ZONE> pointing to party-clippy.<CLUSTER_SPECIFIC_DNS_ZONE>, when I curl party-clippy.<MY-DNS-ZONE>, addon-http-application-routing-nginx-ingress-controller never gets this request (which can be seen by running kubectl logs -f deploy/addon-http-application-routing-nginx-ingress-controller -n kube-system). If I curl party-clippy.<CLUSTER_SPECIFIC_DNS_ZONE>, everything works and I can see an entry in the addon-http-application-routing-nginx-ingress-controller log.

Creating the CNAME record works only if the Ingress definition is changed from

  - host: party-clippy.<CLUSTER_SPECIFIC_DNS_ZONE>

to

  - host: party-clippy. <MY-DNS-ZONE>

However, if I do that, addon-http-application-routing-external-dns will remove the party-clippy A and TXT records from <CLUSTER_SPECIFIC_DNS_ZONE>, which will eventually invalidate the party-clippy.<MY-DNS-ZONE> CNAME record

So, the only thing that works for me is

  • create an A record in <MY-DNS-ZONE> pointing to the public IP address of the load balancer
  • Use - host: party-clippy. <MY-DNS-ZONE> in the Ingress definition

However, I completely agree with @mhabegger, implementing this workaround kind of defeats the purpose of external-dns

As far as I can tell, https://github.com/kubernetes-incubator/external-dns supports custom domains.

QUESTION
Because of how external-dns is implemented in AKS, we can't use it. But it is bundled into http-application-routing add-on, and we need the other parts of it. What is the proper way to unbundle or disable external-dns from the http-application-routing add-on? Or can we simply ignore it and implement the OSS version of external-dns on top of the http-application-routing addon?

@sryabkov

This comment has been minimized.

Copy link
Contributor

sryabkov commented Jul 17, 2018

@MicahMcKittrick-MSFT Are AKS feature request supposed to be logged on UserVoice (feedback.azure.com) or here, in this repo? There is no category for AKS on feedback.azure.com

@mhabegger logged his request (https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/34764004-custom-domain-names-or-zones-with-http-application) under ACI, which seems to be the wrong category.

It looks like some AKS-related feature requests were moved from UserVoice to GitHub. See https://feedback.azure.com/forums/602224-azure-container-instances/suggestions/32855575-implement-rbac-authorization-for-kubernetes-in-aks for an example.

@MicahMcKittrick-MSFT

This comment has been minimized.

Copy link
Contributor

MicahMcKittrick-MSFT commented Jul 17, 2018

Thanks @sryabkov. Looks like the AKS team has moved their feedback to GitHub for easier tracking and assignment.

@toutougabi

This comment has been minimized.

Copy link

toutougabi commented Nov 21, 2018

We deployed a custom version of the teapot external-dns and simply added it as a cluster service. So we have a resource group with all our DNS in and when we define a new ingress is goes to update the dns for us.

@A141864

This comment has been minimized.

Copy link

A141864 commented Jan 18, 2019

@sryabkov
There is another option that works... create two ingress controllers on the same IP:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: clippy-custom-dns
  annotations:
    kubernetes.io/ingress.class: addon-http-application-routing
spec:
  rules:
  - host: clippy.sprockets.com
    http:
      paths:
      - backend:
          serviceName: clippy
          servicePort: 80
        path: /
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: clippy-azure-dns
  annotations:
    kubernetes.io/ingress.class: addon-http-application-routing
spec:
  rules:
  - host: clippy.d22a51eb658fksfjsdf4dc.region.aksapp.io
    http:
      paths:
      - backend:
          serviceName: clippy
          servicePort: 80
        path: /
@sryabkov

This comment has been minimized.

Copy link
Contributor

sryabkov commented Jan 18, 2019

@A141864 👍 thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.