Owners have discussed this multiple times, but I am not finding an issue for this. I did find the issue in the external-dns project https://github.com/kubernetes-incubator/external-dns/issues/221.
The thought is that we would like to rely on external dns, so that our dns is far more flexible. Add a cloud provider and we could have dns support for it before we even have the provider, for instance. You want you dns in GCE and you cluster in aws, we can do that theoretically.
Background
We have two components that manage dns for our system.
- Protokube manages etcd dns so that we can have ha
- dns-controller manages control plane API dns for us, and people also use it for services and ingress as well.
Todo
- What gaps of support do we have with external dns with protokube? Can we vendor external dns and approach it that way?
- What gaps do we have with external dns and API? We have dns records for round robin master dns, we have records for loadbalancer, API and bastions.
- Do we have used cases that dns-controller provides that are not met by external-dns
- How do we do upgrades and rollbacks?
- How do we test?
- What API changes should we make in kops to support dns in aws, but a cluster in GCE? Very real world use case.
chrislovecnm
All 25 comments
@gambol99 @blakebarnett @sethpollack @geojaz @robinpercy @justinsb et al
What am I missing here?
chrislovecnm
on 1 Oct 2017
Seems like it would make sense to just replace dns-controller with it first, then separately add support to protokube to use it? Have all the feature gaps between this and dns-controller been filled?
blakebarnett
on 2 Oct 2017
@blakebarnett someone needs to build a feature list for both and compare them ;) I do not know which features if any we are missing
chrislovecnm
on 2 Oct 2017
The issue you linked in here does a pretty good job :)
blakebarnett
on 2 Oct 2017
And https://github.com/kubernetes-incubator/external-dns/blob/master/docs/legacy/kops-dns-controller.md
chrislovecnm
on 2 Oct 2017
chrislovecnm
on 2 Oct 2017
And https://github.com/kubernetes/kops/blob/master/protokube/README.md has a section about dns and protokube
chrislovecnm
on 2 Oct 2017
There are still a couple of comments on the linked issue that need to be resolved / documented.
support kops' internal/external annotations, find out what they do first
chrislovecnm
on 2 Oct 2017
- multiple targets
- internal alias records (for nodes)
- node source
- pod source
- internal/external annotations
- dns-contoller backwards compatibility for service, ingress, node, pod sources.
- record caching so we don't get rate-limited
sethpollack
on 2 Oct 2017
I have an open PR for multiple targets https://github.com/kubernetes-incubator/external-dns/pull/326
And I already have the code for alias records, node source, pod source, and dns-contoller backwards compatibility, they just depend on each other so I need to open the PR's one at a time.
sethpollack
on 2 Oct 2017
As for internal/external annotations @justinsb do we need that support? Or can that be limited to the backwards compatibility?
sethpollack
on 2 Oct 2017
Also caching would be nice, but not sure if thats a blocker.
sethpollack
on 2 Oct 2017
@sethpollack Kops compatibility is the main part of our next milestone. Sorry for the delay in reviewing the PR. We will look at at whenever there's time.
linki
on 12 Oct 2017
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
fejta-bot
on 10 Jan 2018
/remove-lifecycle stale
kenden
on 10 Jan 2018
So does this mean this won't get done?
hoshsadiq
on 15 Mar 2018
The bot stuff?
chrislovecnm
on 17 Mar 2018
If Kops moves to external-dns for internal stuff too (I think that would be great) but in my opinion there would need to be a way to support split horizon. Currently this is done by running two instances of external-dns on a cluster. Using --annotation-filter (I think?) you can have the public external-dns only add public records for a service that should be public and a catch-all external-dns that is limited to private zones.
I think this could be implemented by external-dns that comes with Kops in the future following the dns: private directive (where private could be private, public and maybe auto (equivalent to no --aws-zone-type flag in external-dns)
Then a further external-dns instance can be started manually outside of Kops for public / other zones.
Most of this is thinking out loud but may be worth adding to the to do. Just putting external-dns on a Kops cluster that picks up ALL hostnames by default and puts them in an auto-detected zone will break a lot of peoples setups.
rlees85
on 23 Apr 2018
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 22 Jul 2018
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 21 Aug 2018
/remove-lifecycle rotten
linki
on 21 Aug 2018
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 19 Nov 2018
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 19 Dec 2018
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
fejta-bot
on 18 Jan 2019
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
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.
k8s-ci-robot
on 18 Jan 2019
Related issues
drewfisher314
路
4Comments
endejoli
路
4Comments
chrislovecnm
路
3Comments
olalonde
路
4Comments
minasys
路
3Comments
Most helpful comment