* feat(controller): add more metrics for all supported endpoint types
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* feat(controller): add cardinality and labels for records metrics
Co-authored-by: Michel Loiseleur <97035654+mloiseleur@users.noreply.github.com>
* feat(controller): add cardinality and labels for records metrics
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
* fix rebase
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
---------
Signed-off-by: ivan katliarchuk <ivan.katliarchuk@gmail.com>
Co-authored-by: Michel Loiseleur <97035654+mloiseleur@users.noreply.github.com>
**Description**
In the command line arguments, we see `min-event-sync-interval` as
"The minimum interval between two consecutive synchronizations triggered from kubernetes events"
In the code, it actually acts a different way.
It imposes a certain dealy between syncs.
While this is compliant with the "minimum delay between 2 consecutive
synchronizations", it has side-effects in case of large delays.
In particular, when trying to fine-tune external-dns to match the
provider rate-limits.
In this case, it may be interesting to restrict the rate of reconciling
actions happening by having a high `min-event-sync-interval`, while
keeping a low latency for initial events.
This would allow to maximise the bulk effect of high change rate while
keeping fast enough reaction for isolated changes.
**Checklist**
- [X] Unit tests updated
- [X] End user documentation updated
> End user documentation matches the updated behaviour with more
> accuracy
Change-Id: Ibcea707974a095a2d5861a3974b4c79e5a15b00e
the entire logic of missing endpoints was removed from the controller
taking leverage on the planner
Signed-off-by: Matias Charriere <matias@giantswarm.io>
Changes to add A records of source and registry as metrics. The existing metrics -
external_dns_registry_endpoints_total & external_dns_source_endpoints_total gives a cumulative count of records all records (A, SRV, CNAME, TXT).
We have a metric - external_dns_controller_verified_records which gives the intersection of A records between source & regsitry. However, in order to determined how many records are yet to be synced to registry, we need count of total A records in registry & source.
Currently, planning instructs to create all records even
those which does not match any zone.
Later, those records will be checked towards the existing
records and filtered whether they match or not a hosted zone.
This causes a problem, at least in the specific case of the Route53
implementation as it always calls the ApplyChanges method, which in its
turn always retrieves all records in all zones.
This causes high pressure on Route53 APIs, for non-necessary actions.
By being able to filter all unmanaged records from the plan, we can
prevent from calling ApplyChanges when nothing has to be done and hence
prevent an unnecessary listing of records.
By doing so, the rate of API calls to AWS Route53 is expected to be
reduced by 2
Currently, the minimum delay between 2 kubernetes events handling is
hard-coded to 5s.
This may cause higher synchronization rates and higher DNS provider API
calls when handling an important number of kubernetes events at once.
Give the opportunity to configure this delay so service owners can
define the acceptable thresholds on their side
The controller will retrieve all the endpoints at the beginning of its
loop. When changes need to be applied, the provider may need to query
the endpoints again. Allow the provider to skip the queries if its data was
cached.
* Endpoint.Target is now Endpoint.Targets. This is its own type representing mutliple targets for a single DNS name while adding some convenience for sorting and comparing
* Made everything compile and tests run through with the new Endpoint.Targets
* The ingress source can now properly handle multiple target ips per host
* Added custom conflict resolver, to better understand how conflict resolution has to work for me
* My custom conflict resolver behaves a bit different than the PerResource resolver, therefore I needed to modify the expected test result
Removed unnecessary FIXME
* The ingress source now creates CNAME endpoints with multiple targets to let the DNS provider decide how to handle multiple CNAME targets. This could be interesting for weighted targets etc.
* Adopted the expected results to the new way we create endpoints for CNAMEs
* Removed Add method from Targets since manipulating the slice through here is unnecessary complicated and doesn't deliver enough convenience
* Reverted ConflictResolver to the original one. There is some discussing to do what the best way is to handle conflicts
* Added missing documenting comment to IsLess of Targets
* Added documenting comments to Targets,Targets.Same and NewTargets to clarify their intention and usage
* Service source now also generates endpoints with multiple targets
* Service and Ingress source now sort all Targets for every Endpoint to make order of Targets predictable
* Endpoints generated by the Google Cloud DNS provider now also have sorted Targets to make order of Targets predictable
* Modified provider dyn to be able to compile with multi target changes
* Fixed small nitpicks, so my code is acceptable
* Fixed merge method after updating to new Targets. Replacing '!=' with .Same of course needs a boolean negation
* Tests for dyn provider now also use the new Targets instead of Target
* Simplified extractServiceIps as implied by linki to make it more readable
* ref: change service ClusterIP retrieval again
* Added entry to CHANGELOG.md describing the new features contained in this PR
* ref(source): use testify with mocks in test code
* fix: re-introduce NewMockSource for convenience
* fix: avoid circular dependency
* ref: increase usage of testify
* chore: vendor testify as a dependency
* fix(*): cleanup testify expectations
* feat(plan): allow plans to be parameterized via policies
* fix(controller): set a policy in the controller tests
* chore: allow go tip to fail
* chore: update changelog to include policies
* fix(plan): store a pointer to changes
* fix(controller): don't get address of a pointer
* feat(google): add ability to apply changes generated from a plan
* feat(controller): first implementation of controller
* feat: allow to configure in-cluster and kubeconfig
* fix(controller): call RunOnce at the right time and in a loop
* feat(google): add dryRun attribute to Google DNS provider
* fix: use hosted zone id instead of DNS name
* fix(google): stupidly filter by A records for now
* feat: allow specifying the google project and zone
* feat: provide a dry-run flag which defaults to false
* chore: vendor new dependencies
* fix(config): fix failing tests for config object
* ref(controller): return plain value of ApplyChanges
* ref: simplify how to get a valid kubernetes client
