-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
initial-design file #4
Conversation
|
||
External DNS should be compatible with annotations used by three above mentioned projects. The idea is that resources created and tagged with annotations for other projects should continue to be valid and now managed by External DNS. | ||
|
||
TODO:*Add complete list here* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
route53-kubernetes functions pretty simply and only works with properly annotated services. The README has more info: https://github.com/wearemolecule/route53-kubernetes
If I were to put it into the example table as given for Mate it would look like this:
Tag: domainName
Description: Hostname to be registered
Default: None (no DNS record would be created)
Example: foo.example.org
But, we would also need to include that it currently only functions on services (no support for ingress) and that a label dns: route53
must also be set on the service for which the user intends to create a DNS record.
All that being said, I could see how we may not want to support the above rules. It might be easier to support running route53-kubernetes
and this project simultaneously until a user can correctly port everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iterion I see your point and it feels right in route53-kubernetes case. in mate's case we do not tag resources which can/cannot be managed by mate. Hence running mate + external-dns at the same time might be problematic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, agree that backwards compatibility for mate makes sense. If we can safely run both route53-kubernetes and external-dns I think it would be a good idea not to support its annotations. It's just less surface area that we'd ultimately probably just deprecate later. I'll add a small section documenting this.
|
||
User runs `kubectl create -f ingress.yaml`, this will create an ingress as normal. | ||
Typically the user would then have to manually create a DNS record pointing the ingress endpoint | ||
If the external-dns controller is running on the cluster, it could automatically configure the DNS records instead, by observing the host attribute in the ingress object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we say we create records by observing the host attribute
. I assume that means the host field specified here: https://kubernetes.io/docs/api-reference/v1.5/#ingressrule-v1beta1. But, later we specify an annotation to do the same (external-dns.kubernetes.io/hostname
). Are both required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my point of view only ingress host is required. In this doc it is mentioned this annotation is only required for other types of resources (which is only loadbalancer service at the moment). But this is certainly open for discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see, to check my understanding. If you're using ingress resources ingress host is required. But, if you are using services then you must specify both of the annotations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the host is specified when ingress is created. For services both annotations are required per my understanding
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make this clear perhaps we should add a section under design, maybe something like:
### Configuration
DNS records will be automatically created in multiple situations:
1. Setting `spec.rules.host` on an ingress object.
2. Specifying two annotations (`external-dns.kubernetes.io/controller` and `external-dns.kubernetes.io/hostname`) on a `type=LoadBalancer` service object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iterion yup, seems good to me. You can push to this branch, this PR is for us to agree on same design basis :) we can fix it any time later. anyways as time goes we will probably need to create separate file(s) for configuration/how to run/use-cases/annotations etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, pushed.
docs/initial-design.md
Outdated
|
||
| Annotations | | | ||
|---|---| | ||
|Tag |external-dns.kubernetes.io/controller | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this the default (configurable)? I want users to have the least amount of annotations possible. There is no need for people to specify this annotation if only one controller is running in the cluster (which will be the case for 99% of the cases).
docs/initial-design.md
Outdated
|
||
DNS records will be automatically created in multiple situations: | ||
1. Setting `spec.rules.host` on an ingress object. | ||
2. Specifying two annotations (`external-dns.kubernetes.io/controller` and `external-dns.kubernetes.io/hostname`) on a `type=LoadBalancer` service object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here: why are two annotations needed? I would assume external-dns.kubernetes.io/controller
to be optional in 99% of the use cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessary, I just grabbed it annotations
section. It seems like external-dns.kubernetes.io/controller
is optional since it has a default value. I'll correct this.
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ to sign the CLA. Once you've signed, please reply here (e.g. "I signed it!") and we'll verify. Thanks.
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. I understand the commands that are listed here. |
docs/initial-design.md
Outdated
@@ -74,6 +74,10 @@ TODO:*Add complete list here* | |||
|Default | Empty(falls back to template based approach) | | |||
|Example|foo.example.org| | |||
|
|||
**route53-kubernetes* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo: missing star at the end of line
Fix formatting
I signed it! |
|
||
## Goals | ||
|
||
1. Support AWS Route53 and Google Cloud DNS providers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is Azure out of scope?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, it's listed below, pls ignore.
let's merge this for now and iterate on it later on. any objections ? |
👍 |
exoscale: fix boilerplate header
CIRE-152: Aws streamline
Incorporated review comments
Add .ci-operator.yaml with base_root_image
* chore: fix k8s-ci-robot license check on github * fix: More linter fixes * fix: linter issues * Merge from github external-dns into release (#4) * Allow multiple services to share same dns record * NS record support * Fix NS related provider test * update comment to explain edge case better * Add short tutorial on how to create NS record * bumps cloudbuild image Signed-off-by: GitHub <[email protected]> * pre-pulls images due to cloudbuilder bug * bump cloudbuild timeout for new release process Signed-off-by: GitHub <[email protected]> * aws-r53 adding Africa (Cape Town) ELB endpoints and hosted zone id's * cloudflare: readme update for RBAC config service account needs access to `watch` nodes. GKE and AWS R53, the two stable providers, have this permission * Update to Go 1.15 & update Azure dependencies * fix: linter issues (#3) * adds arm32v7 arch for images Signed-off-by: Raffaele Di Fazio <[email protected]> * Add namespace for httpbin-gateway Signed-off-by: 杨阳 10014842 <[email protected]> * adds GOARM for arm32v7 images Signed-off-by: GitHub <[email protected]> * adds faq for multiarch images Signed-off-by: GitHub <[email protected]> * Fix OVH tutorial to match new permissions External DNS now require permissions on endpoints resource. Adding it in the OVH tutorial manifest following this comment (kubernetes-sigs#961 (comment)) for making it continue to work out of the box. Co-authored-by: Pavel Tumik <[email protected]> Co-authored-by: Yury Tsarev <[email protected]> Co-authored-by: Kubernetes Prow Robot <[email protected]> Co-authored-by: Raffaele Di Fazio <[email protected]> Co-authored-by: Mic <[email protected]> Co-authored-by: R. Aidan Campbell <[email protected]> Co-authored-by: Jonas-Taha El Sesiy <[email protected]> Co-authored-by: 杨阳 10014842 <[email protected]> Co-authored-by: Victor Coutellier <[email protected]> * adding e2e test stage * fixing the yaml error * parameterize target branch * bump version * doc: Update Readme to add F5 DNS Load Balancer Cloud service Co-authored-by: Pavel Tumik <[email protected]> Co-authored-by: Yury Tsarev <[email protected]> Co-authored-by: Kubernetes Prow Robot <[email protected]> Co-authored-by: Raffaele Di Fazio <[email protected]> Co-authored-by: Mic <[email protected]> Co-authored-by: R. Aidan Campbell <[email protected]> Co-authored-by: Jonas-Taha El Sesiy <[email protected]> Co-authored-by: 杨阳 10014842 <[email protected]> Co-authored-by: Victor Coutellier <[email protected]> Co-authored-by: Rajeev Panda <[email protected]>
*** DO NOT MERGE ***
This is to start design documentation. The following contains the basic outline of what external-dns is and some goals/design decisions we should consider