search

kubernetes-sigs / external-dns

Configure external DNS servers (AWS Route53, Google CloudDNS and others) for Kubernetes Ingresses and Services
Apache License 2.0
7.72k stars 2.57k forks source link

Support for external-dns.alpha.kubernetes.io/ingress-hostname-source in Istio VirtualService #3572

Closed uanid closed 7 months ago

uanid commented 1 year ago

What would you like to be added: It would be great if Istio VirtualService could support the external-dns.alpha.kubernetes.io/ingress-hostname-source annotation. The ingress-hostname-source can have values such as "annotation-only" or "defined-hosts-only" to determine where to get the ingress' hostname from.

Why is this needed: I would like to restrict the usage of the VirtualService hostname while using nested LoadBalancers. For example:

CloudFront(myapp.example.com) -> ALB() -> Istio IngressGateway() -> Istio VirtualService(myapp.example.com)
ALB() -> Istio IngressGateway() -> Istio VirtualService(myapp-direct.example.com)

In this case, I would like to limit the records created by External-DNS for the VirtualService hostname to myapp-direct.example.com. Since v1.networking.k8s.io/Ingress source already provides such an option, it would be helpful to extend the same functionality to VirtualService.

johngmyers commented 1 year ago

Wouldn't it be simpler to use a domain filter or domain exclusion and put the load balancers you don't want published outside the filter?

k8s-triage-robot commented 9 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

phyzical commented 9 months ago

i have this requirement but for the traefik-proxy.

My usecase is app.example.com -> Cloudfront -> app.lb.example.com

on normal ingress objects it looks like this

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    external-dns.alpha.kubernetes.io/hostname: app.lb.example.com
    external-dns.alpha.kubernetes.io/ingress-hostname-source: annotation-only
spec:
  tls:
    - secretName: 'app-certificate'
  ingressClassName: default
  rules:
    - host: app.example.com

This works and only manages app.lb.example.com

But for a non generic ingress that doesnt support the ingress-hostname-source annotation it then tries to create records for both app.lb.example.com and app.example.com

domain filters would work i.e --domain-filter=.lb.example.com but only if we never wanted any .example.com domains managed which isnt the case, so then we would end up excluding the app.example.com domains which would work. but the problem with this is it ends up being managed at the helm/configuration side instead of app side kinda defeating the purpose of the magic of version controlled crds i.e testing via branch pinning

k8s-triage-robot commented 8 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

k8s-triage-robot commented 7 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented 7 months ago

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to [this](https://github.com/kubernetes-sigs/external-dns/issues/3572#issuecomment-2016753864): >The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. > >This bot triages issues according to the following rules: >- After 90d of inactivity, `lifecycle/stale` is applied >- After 30d of inactivity since `lifecycle/stale` was applied, `lifecycle/rotten` is applied >- After 30d of inactivity since `lifecycle/rotten` was applied, the issue is closed > >You can: >- Reopen this issue with `/reopen` >- Mark this issue as fresh with `/remove-lifecycle rotten` >- Offer to help out with [Issue Triage][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.