Closed github-amine-kherbouche closed 1 week 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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
We got the same issue, External-DNS is very very slow in terms of updating a headless Service object
Also experiencing the same issue. Currently external-dns takes about ~5 min to update records.
Hey! We have this issue as well.
this would be a great feature, lowering update interval really isn't good enough
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen
@github-amine-kherbouche: Reopened this issue.
any update for this issue? I forget to mention but any updates to the Endpoint resource don't trigger External-DNS updates
Hey! we are also experiencing the same issue
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen
@github-brice-messeca: You can't reopen an issue/PR unless you authored it or you are a collaborator.
/reopen
@github-amine-kherbouche: Reopened this issue.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
What would you like to be added:
A watch mechanism for Headless services' Endpoint updates, ensuring automatic reconciliation of DNS records when scaling operations occur. This enhancement intends to maintain synchronization between the service's DNS entries and the underlying endpoints when scaling the Headless service.
Why is this needed:
Currently, External-DNS generates DNS records upon the creation of a headless Service. However, when scaling deployment/statefulset, updates to the Endpoint resource containing new list of IP addresses don't trigger External-DNS updates. This omission occurs due to the lack of Endpoint event monitoring.
The existing workarounds involve either:
Manually triggering the Service resource update with an annotation. Utilizing a small --interval in External-DNS to enforce recurrent updates. However, this approach has drawbacks:
Consequently, implementing Endpoint event monitoring would streamline the synchronization between scaling operations and DNS updates for Headless services, mitigating the need for manual interventions and/or lowering the update interval