Annotation values may not be an integer, they must be handled as a
string. The current example tested on k8s 1.20.13 generates this error
message:
json: cannot unmarshal number into Go struct field ObjectMeta.metadata.annotations of type string
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.
The k8s external-dns project now uses the official Kubernetes projects
container registry at k8s.gcr.io. Update all references to use the new
registry.
Using EC2 Instance Roles to provide Route 53 permissions is overly
permissive and dangerous. Emphasize using alternatives such
as EKS IAM Roles for Service Accounts, kiam, or kube2iam that
limit access to the ExternalDNS pod.
The extensions/v1beta1 API is deprecated for Deployment and with 1.16 is
not served by default anymore. This breaks the examples on k8s 1.16.
See this blog post for details on the deprecations:
https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/
Amazon EKS supports IAM Roles for Service Accounts. It mounts tokens
files to `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`.
Unfortunately, external-dns runs as 'nobody' so it cannot access this
file. External DNS is then unable to make any AWS API calls to work:
```
time="2019-09-11T07:31:53Z" level=error msg="WebIdentityErr: unable to read file at /var/run/secrets/eks.amazonaws.com/serviceaccount/token\ncaused by: open /var/run/secrets/eks.amazonaws.com/serviceaccount/token: permission denied"
```
See: https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html
Below are the file permissions mounted on External DNS pod:
```
~ $ ls -al /var/run/secrets/eks.amazonaws.com/serviceaccount/
total 0
drwxrwxrwt 3 root root 100 Sep 11 06:40 .
drwxr-xr-x 3 root root 28 Sep 11 06:40 ..
drwxr-xr-x 2 root root 60 Sep 11 06:40 ..2019_09_11_06_40_49.865776187
lrwxrwxrwx 1 root root 31 Sep 11 06:40 ..data -> ..2019_09_11_06_40_49.865776187
lrwxrwxrwx 1 root root 12 Sep 11 06:40 token -> ..data/token
~ $ ls -al /var/run/secrets/eks.amazonaws.com/serviceaccount/..data/token
-rw------- 1 root root 1028 Sep 11 06:40 /var/run/secrets/eks.amazonaws.com/serviceaccount/..data/token
```
This commit fixes this problem by specifying securityContext to make
mounted volumes with 65534 (nobody) group ownership.
Tutorial specifies version >0.4 which also removed the requirement for a trailing period. New users could misunderstand the trailing dot as a significant syntax. Removing the dot simplifies the configuration of the annotation.
Introducing support for NodePort services might break cluster which
using RBAC
* allow external-dns to list nodes
Signed-off-by: Nick Jüttner <nick@zalando.de>
