Add support (might just be docs) for external DNS

[richarddli]

https://github.com/kubernetes-incubator/external-dns

See #1053 (comment) for some context

[jwhitlark]

This is a big problem for us, too. I can't tell from the docs if it's possible, easy, or impossible.

On aws, we usually just add the annotation (to a service)
external-dns.alpha.kubernetes.io/hostname: foo.example.com.

[seslattery]

I don't believe this issue should be closed. There is no reference in the docs that I can find to reference if you support external-dns https://github.com/kubernetes-incubator/external-dns. Would be useful to know if ambassador supports this. Basically need to know if amabassador updates Ingress Status. As an example, traefik added support for this here: traefik/traefik#3324

[jwhitlark]

I agree with Sean.

…

On Fri, Jun 21, 2019, 4:09 PM Sean Slattery ***@***.***> wrote: I don't believe this issue should be closed. There is no reference in the docs that I can find to reference if you support external-dns https://github.com/kubernetes-incubator/external-dns. Would be useful to know if ambassador supports this. Basically need to know if amabassador updates Ingress Status. As an example, traefik added support for this here: traefik/traefik#3324 <traefik/traefik#3324> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1057>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAORPA2BUCQWSWDJFSK4HLP3VNTZANCNFSM4GLTKGEA> .

[richarddli]

Yes, I think this was inadvertently closed. PRs for this are welcome!

[stefansedich]

+1 on this, would be great to be able to handle this in a simple way like you can for Ingress resources, my current workaround is to annotate my Ambassador service with all the domains I want to point to it and use host based mappings:

---
apiVersion: v1
kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ...
    external-dns.alpha.kubernetes.io/hostname: >-
      foo.com,
      bah.com

While this works it just adds some duplication, and it would be nice to be able to define the DNS entries along with my individual services helm charts.

I came across this https://github.com/kubernetes-incubator/external-dns/blob/master/docs/contributing/crd-source.md but it looks like the DNSEndpoint targets are simply IPs and cannot map to a specific service.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jmeickle]

+1 on this. We have a cluster that will have independent internal and internet-facing load balancers. We'd prefer not to have to run different DNS wildcards, different SSL certs, and so on. The in-progress Ingress support is a good start, but I'd like to see the same support for load balancer `statuss field updates on Services; and ideally, a roadmap to supporting external DNS for Mapping CRDs.

Also, documentation on all three approaches would be great. The references to DNS on the Ambassador homepage are about intra-cluster DNS.

[seh]

I came across this https://github.com/kubernetes-incubator/external-dns/blob/master/docs/contributing/crd-source.md but it looks like the DNSEndpoint targets are simply IPs and cannot map to a specific service.

The DNSEndpoint.Targets field holds strings, and those strings can be DNS names, so long as the record type is CNAME or SRV. Does that help with the mapping you're trying to arrange?

[stefansedich]

This has now been resolved with the addition of Ingress support and should cover my needs when 0.84.0 drops!

…

On Wed, Oct 16, 2019, 7:14 PM Steven E. Harris ***@***.***> wrote: I came across this https://github.com/kubernetes-incubator/external-dns/blob/master/docs/contributing/crd-source.md but it looks like the DNSEndpoint targets are simply IPs and cannot map to a specific service. The DNSEndpoint.Targets field holds strings, and those strings can be DNS names, so long as the record type is CNAME ***@***.***/-/blob/source/crd_test.go#L257-L261> or SRV ***@***.***/-/blob/source/service_test.go#L1316>. Does that help with the mapping you're trying to arrange? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1057>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABCUVETRIPNB2H4ENVTPKTQO7C7ZANCNFSM4GLTKGEA> .

[seh]

Oh, Ambassador is going to read Ingress objects? How will that interact with the Mapping objects?

[Time passes]

I now see #1717, and several that follow on from there.

[thejmazz]

From Ambassador User Guide - Ingress Controller:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: ambassador
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /foo/
        backend:
          serviceName: service1
          servicePort: 80
---
apiVersion: getambassador.io/v1
kind: Mapping
metadata:
  name: my-mapping
spec:
  prefix: /foo/
  service: service2

“ will set up Ambassador to do canary routing where 50% of the traffic will go to service1 and 50% will go to service2.”

So, I have the following concern:

• I want to use Ingress just so that status.loadBalancer.ingress[{ ip }] is set for external-dns
• I want to add extra config to the Mapping which are items not configurable via Ingress

So, I can use Ingress and Mapping CRDs in concert, but will it be finicky to configure the same mapping via both an Ingress and Mapping? E.g. the docs above seem to suggest that canary routing will be set up (is this cause the second one’s name is different - but won’t same name cause errors, and also service is different). In which case, would I end up with one Mapping for my external DNS to work at 50%, and one Mapping for my extra non-ingress compatible params at 50%?

Perhaps when adding annotations to the Ingress, it will be merged into the resulting created Mapping? Is this the case currently?

I took a quick look at external-dns code and I think that they are “hardcoding” against Ingress and Service resources. However, perhaps if that code can be changed to use unstructured, and just assume, then it will be possible for status.loadBalancer.ingress[{ ip }] to be set on the Mapping resource, allowing us to have best of both worlds - get external DNS mapping and still solely use the Mapping CRD.

[seh]

Note, though, that External DNS would still need to be taught to watch your Mapping objects. Note that for Contour, they had to add a new "source" to External DNS; they couldn't piggyback on the existing Ingress source.

The Traefik project has waffled—in traefik/traefik#4655—on which way to go here too.

[thejmazz]

Note, though, that External DNS would still need to be taught to watch your Mapping objects

Yeah, I was hypothesizing that perhaps external-dns could instead use unstructured and then have a config something like

watch:
- apiGroup: “getammbassador.io/v1”
  resources: “Mapping”

And then code within external-dns just grabs status.loadBalancer.ingress without knowing the resource kinds. Then external-dns would be able to use out-of-tree resources without requiring PRs. But anyways that’s just me taking a guess, it could very well not be possible that way. Thanks for linking the Traefik discussion. Seems external-dns approach to supporting out-of-tree is it’s DNSEndpoint CRD which I can see in the linked discussions has its own cons.

Personally, I think having to manage a new DNSEndpoint CRD and associated RBAC etc is worth it (I don’t consider it a great burden) and would be welcome to see Ambassador support this feature on Mappings by having the Mapping controller manage DNSEndpoint resources. See gardener/external-dns-management - Why not using the community external-dns solution? for some arguments supporting managing DNS records via a CRD.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[concaf]

not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[phyllisstein]

I was facing similar uncertainties about integrating ExternalDNS and Ambassador. I wanted to take advantage of Ambassador's weighted mapping capabilities without losing the Ingress resource, which ExternalDNS can read out of the box. I found that defining an Ingress with multiple backends alongside Ambassador Mappings with its fuller feature set worked as expected.

Here's a test manifest that I tried in Minikube. When I curled it with the appropriate Host header, it routed to nginx most of the time but hit the echo resource some of the time. Definitely wasn't 50/50, in my testing.

---
kind: Namespace
apiVersion: v1
metadata:
  name: echo-nginx

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: echo
  namespace: echo-nginx
  labels:
    app.kubernetes.io/name: echo
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: echo
  template:
    metadata:
      labels:
        app.kubernetes.io/name: echo
    spec:
      containers:
        - name: echo
          image: electroma/ingress-demo-echosvc-amd64:0.1
          ports:
            - containerPort: 8080
              name: http
          resources:
            limits:
              cpu: 10m
              memory: 20Mi
            requests:
              cpu: 10m
              memory: 20Mi

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: echo-nginx
  labels:
    app.kubernetes.io/name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: nginx
    spec:
      containers:
        - name: echo
          image: nginx:1.17.9
          ports:
            - containerPort: 80
              name: http
          resources:
            limits:
              cpu: 10m
              memory: 20Mi
            requests:
              cpu: 10m
              memory: 20Mi

---
kind: Service
apiVersion: v1
metadata:
  name: nginx
  namespace: echo-nginx
  labels:
    app.kubernetes.io/name: nginx
spec:
  selector:
    app.kubernetes.io/name: nginx
  ports:
    - name: http
      port: 8080
      targetPort: http

---
kind: Service
apiVersion: v1
metadata:
  name: echo
  namespace: echo-nginx
  labels:
    app.kubernetes.io/name: echo
spec:
  selector:
    app.kubernetes.io/name: echo
  ports:
    - name: http
      port: 8080
      targetPort: http

---
kind: Ingress
apiVersion: networking.k8s.io/v1beta1
metadata:
  name: echo-nginx
  namespace: echo-nginx
  annotations:
    kubernetes.io/ingress.class: ambassador
  labels:
    app.kubernetes.io/name: echo-nginx
spec:
  rules:
    - host: dashboard.danielsh.here
      http:
        paths:
          - backend:
              serviceName: echo
              servicePort: http
          - backend:
              serviceName: nginx
              servicePort: http

---
kind: Mapping
apiVersion: getambassador.io/v2
metadata:
  name: echo
  namespace: echo-nginx
spec:
  prefix: /
  host: dashboard.danielsh.here
  service: echo:8080
  weight: 10

---
kind: Mapping
apiVersion: getambassador.io/v2
metadata:
  name: nginx
  namespace: echo-nginx
spec:
  prefix: /
  host: dashboard.danielsh.here
  service: nginx:8080
  weight: 90

[richarddli]

See kubernetes-sigs/external-dns#1642

[khussey]

Support for ExternalDNS is documented at https://www.getambassador.io/docs/emissary/latest/howtos/external-dns/.