-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
middleware/kubernetes: Preemptive search path lookups #747
Comments
Would there be a way to pull the proposed hackery into its own middleware?
…On 21 Jun 2017 4:30 pm, "chrisohaver" ***@***.***> wrote:
*Problem*:
A known issue with kube-dns and how K8s works is the long DNS search path
and high ”ndots” in /etc/resolv.conf. kubernetes/kubernetes#33554
<kubernetes/kubernetes#33554>
For example, search path in a pod as dictated by the pod's dns policy is:
namespace.svc.cluster.local
svc.cluster.local
cluster.localmydomain.com
If you try to lookup ”google.com” you will end up with queries:
google.com.namespace.svc.cluster.local.
google.com.svc.cluster.local.
google.com.cluster.local.google.com.mydomain.com.google.com.
This means that for every query of a host outside the cluster, the client
has to make 5 queries.
*Proposed Solution*:
For queries from pods in the cluster, iterate on the search path in
coredns, returning the first successful lookup back to the client. This
allows the client to get the answer in one query, instead of five.
The condition for doing the preemptive lookups on an incoming question
would have to meet all of the following...
- the incoming question would otherwise result in an NXDOMAIN (e.g. it
doesn't match a service)
- the source is a pod in the kubernetes cluster
- the question ends with namespace.svc.cluster.local. where namespace
is the namespace of the pod, and cluster.local is the zone
If these conditions are met, then the kubernetes middleware would strip
the search path from the question, and try the remaining search paths until
an answer is found.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#747>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAVkW3G3OOEv3wKRhNePFLiPO-eTFeMjks5sGTcggaJpZM4OBI1H>
.
|
It needs the pod watch that we put in for |
Or are you saying so that it can be used in non-k8s cases? |
Reuse maybe. More from code complicity standpoint.
…On 21 Jun 2017 8:50 pm, "John Belamaric" ***@***.***> wrote:
Or are you saying so that it can be used in non-k8s cases?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#747 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAVkW1SQCR7m2VIGDUXfcRA-g2pGT6yJks5sGXQIgaJpZM4OBI1H>
.
|
Should we call it autopath (like the name, but it is a bit non descriptive) or maybe serverpath? serversearch, autosearch? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem:
A known issue with kube-dns and how K8s works is the long DNS search path and high ”ndots” in /etc/resolv.conf. kubernetes/kubernetes#33554
For example, search path in a pod as dictated by the pod's dns policy is:
If you try to lookup ”google.com” you will end up with queries:
This means that for every query of a host outside the cluster, the client has to make 5 queries.
Proposed Solution:
For queries from pods in the cluster, iterate on the search path in coredns, returning the first successful lookup back to the client. This allows the client to get the answer in one query, instead of five.
The condition for doing the preemptive lookups on an incoming question would have to meet all of the following...
namespace.svc.cluster.local.
wherenamespace
is the namespace of the pod, andcluster.local
is the zoneIf these conditions are met, then the kubernetes middleware would strip the search path from the question, and try the remaining search paths until an answer is found.
The text was updated successfully, but these errors were encountered: