fix potential resolver error in production

[sstoner]

What this PR does:
the specified resolver is a potential error

2021/05/31 07:08:50 [error] 20#20: *17204171 could not be resolved (110: Operation timed out), client: 192.168.2.24, server: , request: "GET /ruler/rules HTTP/1.1"

Which issue(s) this PR fixes:

#671 (comment)

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[stevesg]

Thanks for this suggestion, though I don't understand the problem enough to give feedback. My initial feeling is that changing this might work for some people, and break for others.

Could you elaborate on why this change is needed for your environment? (Just for my understanding, thanks!)

[sstoner]

Thanks for this suggestion, though I don't understand the problem enough to give feedback. My initial feeling is that changing this might work for some people, and break for others.

This will not break for others. After removed resolver, nginx's DNS requests will be forward to this instance's resolv.conf.

In contrast, when we set this resolver, it may be a misconfiguration for some users for the custom environment and as what this blog mentioned by tomwilkie, we also occur this problem in production.

[pracucci]

LGTM. We shouldn't force to a specific resolver but use the default one. If anyone needs a custom config, then they can override it.

[stevesg]

I liked this part:

resolving the resolver is well, bad form

[bboreham]

The whole k8s directory was removed by #4268 so I don't think we need this now.
Maybe there is comparable config in one of the helm charts?