Skip to content
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

Use miekg/dns for SRV lookup #1206

Closed
wants to merge 3 commits into from
Closed

Conversation

codesome
Copy link
Contributor

@codesome codesome commented Jan 26, 2019

Fixes #1200

EDIT (by @gouthamve): This uses miekg/dns library to do the SRV lookups. We are using this in the grpc codebase as there is a A record fallback when SRV lookups fail.

@tomwilkie
Copy link
Contributor

Looks good so far; lint needs fixing, and there was some mention of gRPC also using LookupSRV for querier -> frontend comms.

@codesome
Copy link
Contributor Author

codesome commented Feb 5, 2019

Yes, it was this comment by @bboreham. Need to fix that too. Will do when I get free from academic stuff.

@tomwilkie
Copy link
Contributor

I opened grpc/grpc-go#2634 to help with the gRPC side.

@codesome
Copy link
Contributor Author

codesome commented Feb 9, 2019

Thanks @tomwilkie!

pkg/util/dns.go Outdated Show resolved Hide resolved
@bboreham
Copy link
Contributor

bboreham commented Mar 5, 2019

Note the gRPC PR was rejected

@gouthamve
Copy link
Contributor

Hmm, as far as I see, the grpc resolver uses grpclb port name to resolve the services, https://github.com/grpc/grpc-go/blob/master/naming/dns_resolver.go#L216-L220

If that fails, it falls back to simple A record lookup: https://github.com/grpc/grpc-go/blob/master/naming/dns_resolver.go#L261-L267

I found that in the clusters we run, we don't expose a port-named grpclb and the resolver falls back to A records. Given that it works nevertheless, I wonder if it's worth the pain to copy the dns_resolver.go file from grpc-go. Note that this doesn't exist in the latest kubernetes versions and only is a problem when running cortex with go 1.11 with an old kubernetes version. Even then nothing will break.

@bboreham
Copy link
Contributor

bboreham commented Mar 6, 2019

I'm happy with A record lookup.
Can someone update #1200 with exactly what works and doesn't work?
(e.g. what's "an old kubernetes version")

@gouthamve gouthamve mentioned this pull request Mar 7, 2019
Copy link
Contributor

@bboreham bboreham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A. Do we really have to do this? This says the underlying issue can be addressed by upgrading kube-dns.
B. One of the seven commits claims to move from udp to tcp; the PR description says nothing about this. I'd like that addressed; also I'd like to know about performance impact before approving.
C. The description of the problem at #1200 remains imprecise.

@gouthamve
Copy link
Contributor

A: We don't need to do it if we're okay asking people to upgrade kube-dns
B: The TCP-UDP change has been reverted in the last commit by me. The current state of the PR could be described as:

Use miekg/dns instead of native DNS library to be compatible with kube-dns <1.14.11 and golang >=1.11. This is what Prometheus does for DNS-SD

C: The problem is that go1.11's net library cannot read SRV records sent by kube-dns <1.14.11

codesome and others added 3 commits March 11, 2019 17:45
Signed-off-by: Ganesh Vernekar <cs15btech11018@iith.ac.in>
Also use TCP for the DNS lookup

Signed-off-by: Ganesh Vernekar <cs15btech11018@iith.ac.in>
Also make sure that we check for search domains

Revert the TCP lookup change and fallback to UDP

Signed-off-by: Goutham Veeramachaneni <gouthamve@gmail.com>
Copy link
Contributor

@tomwilkie tomwilkie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback @bboreham. I'm LGTM on this, keen to unblock the move to go modules and go 1.12.

@bboreham
Copy link
Contributor

Still feels like a bad idea to me.
Note I have two questions outstanding on the go modules PR #1232 for 25 days.

@tomwilkie
Copy link
Contributor

Still feels like a bad idea to me.

What feels bad about it? Can I infer from your comments you'd prefer to upgrade go without this, effectively making Cortex not work on kube-dns <1.14.11?

Note I have two questions outstanding on the go modules PR #1232 for 25 days.

Thats a different PR; lets address that there, it shouldn't block this.

@bboreham
Copy link
Contributor

What feels bad about it?

It's adding 70 lines of code in a client to work around an issue in a server which was fixed months ago.

Are there reports from people who use or would like to use Cortex and cannot upgrade kube-dns?

Also I think there should be comments in the code

  • why we are doing this
  • why do it in some places and not others
  • why you shouldn't call this code very often
  • why it's ok to have a relatively inefficient implementation

@gouthamve
Copy link
Contributor

Hmm, I'm going to hold off on this PR until someone actually raises an issue and proceed with Go 1.12 upgrade. We might just be optimising for something that has been fixed already as you point out.

@tomwilkie
Copy link
Contributor

@khaines on the call yesterday we decided we probably didn't need this, but we just want to check you've got an update kubedns?

@tomwilkie
Copy link
Contributor

No word from @khaines. I'll close, we can reopen if needs be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants