istio-virtualservice does not create entries in Infoblox

[razvan-ig]

What happened:
Started with a very basic setup of httpbin, as per https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/istio.md#using-a-virtualservice-as-a-source , added a VirtualService, tailing the logs in debug mode, on kubectl apply I see
external-dns-6f7d8c6cc9-dgphl external-dns time="2020-08-12T17:50:11Z" level=debug msg="service added"
and a few secs later (polling 1min)
external-dns-6f7d8c6cc9-dgphl external-dns time="2020-08-12T17:50:57Z" level=debug msg="No endpoints could be generated from VirtualService test/httpbin"
Other types of resources work, namely Service of type LoadBalancer creates A records fine

    spec:
      containers:
      - args:
        - --log-level=debug
        - --log-format=text
        - --domain-filter=k8s.local
        - --policy=sync
        - --provider=infoblox
        - --namespace=test
        - --registry=txt
        - --interval=1m
        - --source=service
        - --source=istio-virtualservice
        - --infoblox-grid-host=grid.local
        - --infoblox-wapi-version=2.3.1
        - --infoblox-view=internal

Service+Gateway:

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: test
spec:
  hosts:
  - "test.k8s.local"
  gateways:
  - httpbin-gateway
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: /delay
    route:
    - destination:
        port:
          number: 8000
        host: httpbin
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
  namespace: test
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - '*.k8s.local'

Any hints for further debugging are most welcome

Anything else we need to know?:
bitnami/charts#3216 recently merged passed, so I guess something related to the provider might be wrong?

Environment:

• External-DNS version (use external-dns --version): 0.7.3
• DNS provider: Infoblox
• Others: running in k8s 1.15, chart from Bitnami external-dns-3.2.6

[carpenike]

I'm seeing the same thing. Have you fixed this?

DNS Provider is pdns.

time="2020-08-31T14:43:21Z" level=debug msg="Endpoints generated from VirtualService: longhorn-system/longhorn: [longhorn.holthome.net 0 IN A  10.45.10.20 []]"
time="2020-08-31T14:43:21Z" level=debug msg="Endpoints generated from VirtualService: default/minio: [minio.holthome.net 0 IN A  10.45.10.20 []]"
time="2020-08-31T14:43:21Z" level=debug msg="Endpoints generated from VirtualService: kube-system/dex: [dex.holthome.net 0 IN A  10.45.10.20 []]"
time="2020-08-31T14:43:21Z" level=debug msg="No endpoints could be generated from VirtualService default/requests"

It works if I add in the external-dns.alpha.kubernetes.io/target: IP annotation, but is not discovering by itself.

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: requests
  namespace: default
  # annotations:
  #   external-dns.alpha.kubernetes.io/target: 10.45.10.20
spec:
  hosts:
    - 'requests.TLD'
  gateways:
    - istio-system/istio-system-ingress-gateway
  http:
    - match:
        - port: 443
      route:
        - destination:
            port:
              number: 3579
            host: ombi.default.svc.cluster.local

[jpugliesi]

We are also seeing a similar issue: The DNS provider is AWS Route53, source is an Istio VirtualService. We're expecting a record to be created for the following virtual service, but no dice.

time="2020-10-01T23:06:03Z" level=debug msg="No endpoints could be generated from VirtualService dev/commuter"

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: commuter
  namespace: dev
spec:
  gateways:
  - istio-system/clients-viaduct-ai
  hosts:
  - commuter.dev.clients.viaduct.ai
  http:
    ...

[marcbachmann]

It looks like at the moment the targets (ip addresses) are only extracted from loadbalancer declarations of the gateways. The code responsible for that is here:

external-dns/source/virtualservice.go

Lines 475 to 481 in 9d2aaf0

	for _, lb := range service.Status.LoadBalancer.Ingress {
	if lb.IP != "" {
	targets = append(targets, lb.IP)
	} else if lb.Hostname != "" {
	targets = append(targets, lb.Hostname)
	}
	}

Maybe we could change the code to also retrieve the ExternalIP or InternalIP of the host where the service is running.

[devstein]

@Raffo Any updates on this issue?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[cawilliamson]

/remove-lifecycle stale

Is there any update on this at all?

I'd really like to see this resolved as it's starting to cause us problems! :(

[k8s-triage-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[EKami]

Same issue here =/

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[foal]

For gateway the same situation - the current code only checks LoadBalancer case:

external-dns/source/istio_gateway.go

Lines 248 to 254 in f7e9e5c

	for _, lb := range service.Status.LoadBalancer.Ingress {
	if lb.IP != "" {
	targets = append(targets, lb.IP)
	} else if lb.Hostname != "" {
	targets = append(targets, lb.Hostname)
	}
	}

Please support the case with ClusterIP and externalIPs:

spec:
  type: ClusterIP
  externalIPs:
    - 192.168.5.205

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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

This bot triages issues and PRs 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 or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[devstein]

/reopen

[k8s-ci-robot]

@devstein: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[JethroMV]

/reopen

[k8s-ci-robot]

@JethroMV: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[random1st]

/reopen

[k8s-ci-robot]

@random1st: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[bacek]

Can we have some info on this?

[KarstenSiemer]

/reopen

[k8s-ci-robot]

@KarstenSiemer: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mloiseleur]

/reopen

[k8s-ci-robot]

@mloiseleur: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.