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
* adds flag to opt in for NS records management
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* go fmt
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* goimports
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* fix more tests
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* go fmt again
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* fix test
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* more tests
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* make ordering of managed records consistent
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* fix flag
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
refactor: remove dns api logic and use dns api library
enhancement: add additional args for auth credential retieval
cleanup: simplify, organize processing logic
test: update automation and validate
When it syncs AWS DNS with k8s cluster content (at `--interval`), external-dns submits two distinct Route53 API calls:
* to fetch available zones (eg. for tag based zones discovery, or when zones are created after exernal-dns started),
* to fetch relevant zones' resource records.
Each call taxes the Route53 APIs calls budget (5 API calls per second per AWS account/region hard limit), increasing the probability of being throttled.
Changing synchronization interval would mitigate those calls' impact, but at the cost of keeping stale records for a longer time.
For most practical uses cases, zones list aren't expected to change frequently.
Even less so when external-dns is provided an explicit, static zones set (`--zone-id-filter` rather than `--aws-zone-tags`).
Using a zones list cache halves the number of Route53 read API calls.
Oracle Cloud Infrastructure (OCI) supports "instance princpal" authentication.
From
<https://docs.cloud.oracle.com/en-us/iaas/Content/Identity/Tasks/callingservicesfrominstances.htm>:
> After you set up the required resources and policies, an application running
> on an instance can call Oracle Cloud Infrastructure public services, removing
> the need to configure user credentials or a configuration file.
This change adds support to the OCI provider for instance principal
authentication when external-dns is run on an OCI instance (e.g. in OCI OKE).
Existing support for key/fingerprint-based authentication is unchanged.
