external-dns
external-dns copied to clipboard
kubernetes-sigs
service-type-filter and annotation-filter flags do not work along with events flag
First of all, sorry if this is an expected behavior, but I couldn't find anything related to it on the documentations.
What happened:
We're trying to reduce as much as possible the number of API calls to Route53, due to the increase of k8s clusters using external-dns which my team manages, and consequently the increase of ThrottlingException answered by Route53's APIs.
We are using ingress and service as sources and following the docs recommendations we increased the interval time to reduce the synchronization loop frequency but added the events flag to watch k8s object changes and avoid long synchronization times.
However, some of our clusters have a very specific behavior in which we create/delete services very frequently and this triggers the reconciliation loop multiple times due to the activation of the events flag, which causes two calls to the ListResourceRecordSets API (because we have more than ~500 Records on our Hosted Zone) every time the reconciliation loop is triggered.
When we saw this happening we tried to use the service-type-filter=LoadBalancer flag (possibly using annotation-filter flag in conjunction with service-type-filter to reduce even more the amount of resources) as most of the service creation/deletion I mentioned before are of ClusterIP type, and we do not care that much on watching them (as we do not create external Records for ClusterIP services).
However, after applying the new configuration including service-type-filter (and annotation-filter) we were able to see the ListResourceRecordSets API being called every time we created/deleted a service of type ClusterIP (triggered by the events reconciliation loop).
What you expected to happen:
Using events flag along with service-type-filter=LoadBalancer and annotation-filter=foo and source=service would not trigger ListResourceRecordSets API calls on the creation/deletion of ClusterIP services.
I was able to validate that using events flag along with namespace=bar and source=service do not trigger ListResourceRecordSets API calls when there is a service creation/deletion on a namespace different than bar. Although this could be a possible workaround for the unexpected behavior, we have multiple namespaces to be watched and this is not possible running a single instance of external-dns.
How to reproduce it (as minimally and precisely as possible):
Generates ListResourceRecordSets API calls every time a service (even of type ClusterIP) is created/deleted:
args:
- --source=service
- --source=ingress
- --provider=aws
- --domain-filter=MY_DOMAIN
- --service-type-filter=LoadBalancer
- --registry=txt
- --txt-owner-id=MY_K8S_CLUSTER
- --events
- --aws-zones-cache-duration=5h
Does not generate ListResourceRecordSets API calls every time a service is created/deleted, unless it is on the namespace bar:
args:
- --source=service
- --source=ingress
- --provider=aws
- --domain-filter=MY_DOMAIN
- --namespace=bar
- --registry=txt
- --txt-owner-id=MY_K8S_CLUSTER
- --events
- --aws-zones-cache-duration=5h
Environment:
- External-DNS version:
v0.9.0 - DNS provider: AWS Route53
- Others: I'm unable to upgrade
external-dnscurrently because the k8s clusters are running on version1.18.x
The Kubernetes project currently lacks enough 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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/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 stale
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
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/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
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.
