External-DNS is unable to compute VirtualService's endpoint

[pramodsetlur]

What happened:

"No endpoints could be generated from VirtualService app-ns/app-virtual-service"

What you expected to happen:

External-dns is able to figure out the VirtualService's endpoint (tied to Kubernetes svc, Kubernetes Ingress and Istio Gateway -- design described below) and create a DNS entry for it.

How to reproduce it (as minimally and precisely as possible):

Create an Ingress setup for a GKE cluster with Google Managed Anthos Service Mesh (based on Istio), as described here: https://cloud.google.com/architecture/exposing-service-mesh-apps-through-gke-ingress

Specifically, the installed objects to handle ingress into the cluster are:

• the namespace asm-ingress
• the asm-ingressgateway deployment, HPA, RBAC, SA
• the asm-ingressgateway svc (with the 2 annotations

    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'

• the gke-ingress with kubernetes.io/ingress.class: "gce" annotation which provisions an L7 loadbalancer.
• the asm-ingressgateway gateway object (with hosts: *)
• and finally the frontend-ingress VirtualService that attaches to the above Gateway and works with Kube svc (clusterIP) and Kube Ingress (GCP L7 Looadbalancer) and filters the requests for the specified hosts.

Anything else we need to know?:

The recommended and the implemented Ingress setup for the Google Managed ASM GKE clusters is slightly different compared to the standard Gateway, VirtualService and an L4 loadbalancer. The L7 loadbalancer in the above documentation hooks up with the Ingress pods using negs (https://cloud.google.com/load-balancing/docs/negs)

Current workaround we have is to hardcode the loadbalancer's IP:

kind: VirtualService
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/target: 34.x.x.x #Can also be a DNS entry pointing to the LB's IP.

Environment:

• External-DNS version (use external-dns --version): I believe 0.10.2. bitnami/external-dns:0.10.2-debian-10-r56 from the chart v6.1.5
• DNS provider: CloudDNS

[agustingarciaflores]

We are also facing the same issue with the following setup:

• external-dns version 1.11.0
• Istio 1.13.7
• EKS (k8s 1.20)
• namespace istio-ingress
• svc and deployment istio-gateway-public.

Logs:

external-dns {"level":"debug","msg":"No endpoints could be generated from VirtualService <REDACTED>",

We can confirm that the workaround above works.

[baryal2022]

Same issue!

[ReyanshKharga]

Is there a solution yet? I'm facing the same issue.

I don't even see any error. It just says "All records are already up to date".

[k8s-triage-robot]

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

This bot triages un-triaged 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:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[legal90]

/remove-lifecycle stale

[visortelle]

Same here

[DP19]

We're currently looking into this solution as the reliability of the L4 GCP LB is subpar.

Since we're running two clusters using the same TLD we use external-dns to manage some of our dns entries and not having support for this type of use case is pretty much a deal breaker. It looks like we can make this work with the workaround described in the issue; but having native support would be better.

I can take a stab at a fix here. Possibly add some extra logic to look at the annotations on the ClusterIP service and then grab the Ingress resources if we add another provider specific annotation like external-dns.alpha.kubernetes.io/istio-ingress: $ingressName