Skip to content
This repository has been archived by the owner on Apr 25, 2023. It is now read-only.

IngressDNSRecord not receiving FederatedIngress IP addresses #963

Closed
guanzo opened this issue Jun 3, 2019 · 4 comments · Fixed by #968
Closed

IngressDNSRecord not receiving FederatedIngress IP addresses #963

guanzo opened this issue Jun 3, 2019 · 4 comments · Fixed by #968
Labels
kind/support Categorizes issue or PR as a support question.

Comments

@guanzo
Copy link

guanzo commented Jun 3, 2019

Following this guide: https://github.com/kubernetes-sigs/kubefed/blob/master/docs/ingressdns-with-externaldns.md

This step is failing:

The Ingress DNS Controller watches for IngressDNSRecord resources and updates the status of the resource with the IP address of matching target Ingress resource(s).

I expect the IngressDNSRecord to have ip addresses in status.dns[].loadBalancer, instead it shows loadBalancer: {}

There's a repeated error in kubefed-controller-manager but I'm not sure its related, it's been throwing all day.

sigs.k8s.io/kubefed/pkg/controller/util/federated_informer.go:432: watch of <nil> ended with: too old resource version: 60737 (62023)

I ran this command to create the IngressDNSRecord

$ cat <<EOF | kubectl create -f -
apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: IngressDNSRecord
metadata:
  name: test-ingress-dns-record
spec:
  hosts:
  - test.arc.io
  recordTTL: 300
EOF

The resulting IngressDNSRecord

apiVersion: multiclusterdns.kubefed.k8s.io/v1alpha1
kind: IngressDNSRecord
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"multiclusterdns.kubefed.k8s.io/v1alpha1","kind":"IngressDNSRecord","metadata":{"annotations":{},"name":"test-ingress-dns-record","namespace":"default"},"spec":{"hosts":["test.arc.io"],"recordTTL":300}}
  creationTimestamp: "2019-06-03T22:49:57Z"
  generation: 1
  name: test-ingress-dns-record
  namespace: default
  resourceVersion: "58319"
  selfLink: /apis/multiclusterdns.kubefed.k8s.io/v1alpha1/namespaces/default/ingressdnsrecords/test-ingress-dns-record
  uid: e910749e-8651-11e9-b225-42010a8a0123
spec:
  hosts:
  - test.arc.io
  recordTTL: 300
status:
  dns:
  - cluster: arc-us-east4
    loadBalancer: {}
  - cluster: arc-us-west1
    loadBalancer: {}

FederatedIngress

apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedIngress
metadata:
  creationTimestamp: "2019-06-03T22:48:59Z"
  finalizers:
  - kubefed.k8s.io/sync-controller
  generation: 1
  name: ingress-nginx
  namespace: default
  resourceVersion: "58301"
  selfLink: /apis/types.kubefed.k8s.io/v1beta1/namespaces/default/federatedingresses/ingress-nginx
  uid: c69f2c3a-8651-11e9-bcd7-42010a8a0124
spec:
  placement:
    clusterSelector:
      matchLabels: {}
  template:
    metadata:
      annotations:
        kubernetes.io/ingress.class: nginx
        nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    spec:
      rules:
      - host: test.arc.io
        http:
          paths:
          - backend:
              serviceName: hello-kubernetes
              servicePort: 80
      tls:
      - hosts:
        - test.arc.io
        secretName: letsencrypt-secret
status:
  clusters:
  - name: arc-us-west1
  - name: arc-us-east4
  conditions:
  - lastProbeTime: "2019-06-03T22:49:55Z"
    lastTransitionTime: "2019-06-03T22:48:59Z"
    status: "True"
    type: Propagation

Ingress 1 ip

$ kubectl get ing --context arc-us-west1

NAME            HOSTS         ADDRESS         PORTS     AGE
ingress-nginx   test.arc.io   35.203.174.54   80, 443   19m

Ingress 2 ip

$ kubectl get ing --context arc-us-east4

NAME            HOSTS         ADDRESS         PORTS     AGE
ingress-nginx   test.arc.io   35.221.11.173   80, 443   11m

Let me know if you need more info.

/triage support

@k8s-ci-robot k8s-ci-robot added the kind/support Categorizes issue or PR as a support question. label Jun 3, 2019
@guanzo guanzo changed the title IngressDNSRecord not receiving Ingress IP addresses IngressDNSRecord not receiving FederatedIngress IP addresses Jun 3, 2019
@shashidharatd
Copy link
Contributor

I have re-run the examples and found they are working as expected. From your issue report i could point that the issue is related to the error in the log

sigs.k8s.io/kubefed/pkg/controller/util/federated_informer.go:432: watch of <nil> ended with: too old resource version: 60737 (62023)

which basically means that the watch on the resource in member cluster is not working.

Please give us additional information about.

  1. what is your kubefed codebase? (release)
  2. what is the k8s version of member cluster. Particularly, what is the GVK of ingress resource in member cluster. The informer we are using is using the type as in here

@guanzo
Copy link
Author

guanzo commented Jun 4, 2019

  1. I used helm to install the chart version kubefed-0.1.0-rc2. helm list only displays the chart version, not the app version. I did a clean install yesterday and that error appeared for seemingly no reason. I'll try another clean install and see what happens.
  2. The k8s version of the member cluster is 1.13.6-gke.0

For the GVK, is that the apiVersion + kind? If so, the GVK of the ingress resource is extensions/v1beta1/Ingress

EDIT: I can confirm that the examples worked for me, so I must be doing something wrong.

EDIT: Okay i got it working. Seems like the metadata.name of the IngressDNSRecord has to be the same metadata.name of the Ingress resource. Is that correct? I didn't see that relationship explicity stated in the docs. Though there is this line:

The Ingress DNS Controller watches for IngressDNSRecord resources and updates the status of the resource with the IP address of matching target Ingress resource(s).

Does "of matching target Ingress resource(s)" imply that the names have to be the same?

@shashidharatd
Copy link
Contributor

Does "of matching target Ingress resource(s)" imply that the names have to be the same?

Yes, that's correct and sorry for the confusion created by the doc. Shall update the user guide to clear this.

@guanzo
Copy link
Author

guanzo commented Jun 5, 2019

Thanks for the clarification. 😄

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/support Categorizes issue or PR as a support question.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants