Proxy should accept non-fully qualified domain names #9
Assignees
Labels
Comments
briansmith
added a commit
that referenced
this issue
Dec 16, 2017
Previously we required the service to fully qualify all service names for outbound traffic. Many services are written assuming that Kubernetes will complete names using its DNS search path, and those services weren't working with Conduit. Now add an option, used by default, to fully-qualify the domain names. Currently only Kubernetes-like name completion for services is supported, but the configuration syntax is open-ended to allow for alternatives in the future. Also, the auto-completion can be disabled for applications that prefer to ensure they're always using unambiguous names. Once routing is implemented then it is likely that (default) routing rules will replace these hard-coded rules. Unit tests for the name completion logic are included. Part of the solution for #9. The changes to `conduit inject` to actually use this facility will be in another PR.
briansmith
added a commit
that referenced
this issue
Dec 18, 2017
Previously `conduit inject` did not enable automatic name completion in the proxy. As a result services couldn't connect to services outside the "default" namespace without qualifying the service name with (at least) the namespace. This is arguably safer but it isn't compatible with the way things work in Kubernetes when the proxy isn't used. Enable name auto-completion in the proxy so that the proxy will add the current pod's namespace to any unqualified service name. This depends on the feature being added to the proxy (PR #59). Due to some issues with how zones are dealt with in the project, the zone component isn't provided; it turns out that it doesn't matter whether we provide the zone in the current implementation. Dealing with the zone better will be added later. Validated by deploying the emojivoto service with its configuration updated to use unqualified names (`sed "s/\\.emojivoto//g"`). Before this change this modified configuration would fail; now it succeeds. Fixes #9.
briansmith
added a commit
that referenced
this issue
Dec 18, 2017
Previously `conduit inject` did not enable automatic name completion in the proxy. As a result services couldn't connect to services outside the "default" namespace without qualifying the service name with (at least) the namespace. This is arguably safer but it isn't compatible with the way things work in Kubernetes when the proxy isn't used. Enable name auto-completion in the proxy so that the proxy will add the current pod's namespace to any unqualified service name. This depends on the feature being added to the proxy (PR #59). Due to some issues with how zones are dealt with in the project, the zone component isn't provided; it turns out that it doesn't matter whether we provide the zone in the current implementation. Dealing with the zone better will be added later. Validated by deploying the emojivoto service with its configuration updated to use unqualified names (`sed "s/\\.emojivoto//g"`). Before this change this modified configuration would fail; now it succeeds. Fixes #9.
briansmith
added a commit
that referenced
this issue
Dec 19, 2017
* Proxy: Map unqualified/partially-qualified names to FQDN Previously we required the service to fully qualify all service names for outbound traffic. Many services are written assuming that Kubernetes will complete names using its DNS search path, and those services weren't working with Conduit. Now add an option, used by default, to fully-qualify the domain names. Currently only Kubernetes-like name completion for services is supported, but the configuration syntax is open-ended to allow for alternatives in the future. Also, the auto-completion can be disabled for applications that prefer to ensure they're always using unambiguous names. Once routing is implemented then it is likely that (default) routing rules will replace these hard-coded rules. Unit tests for the name completion logic are included. Part of the solution for #9. The changes to `conduit inject` to actually use this facility will be in another PR.
briansmith
added a commit
that referenced
this issue
Dec 19, 2017
Previously `conduit inject` did not enable automatic name completion in the proxy. As a result services couldn't connect to services outside the "default" namespace without qualifying the service name with (at least) the namespace. This is arguably safer but it isn't compatible with the way things work in Kubernetes when the proxy isn't used. Enable name auto-completion in the proxy so that the proxy will add the current pod's namespace to any unqualified service name. This depends on the feature being added to the proxy (PR #59). Due to some issues with how zones are dealt with in the project, the zone component isn't provided; it turns out that it doesn't matter whether we provide the zone in the current implementation. Dealing with the zone better will be added later. Validated by deploying the emojivoto service with its configuration updated to use unqualified names (`sed "s/\\.emojivoto//g"`). Before this change this modified configuration would fail; now it succeeds. Fixes #9.
khappucino
pushed a commit
to Nordstrom/linkerd2
that referenced
this issue
Mar 5, 2019
* Proxy: Map unqualified/partially-qualified names to FQDN Previously we required the service to fully qualify all service names for outbound traffic. Many services are written assuming that Kubernetes will complete names using its DNS search path, and those services weren't working with Conduit. Now add an option, used by default, to fully-qualify the domain names. Currently only Kubernetes-like name completion for services is supported, but the configuration syntax is open-ended to allow for alternatives in the future. Also, the auto-completion can be disabled for applications that prefer to ensure they're always using unambiguous names. Once routing is implemented then it is likely that (default) routing rules will replace these hard-coded rules. Unit tests for the name completion logic are included. Part of the solution for linkerd#9. The changes to `conduit inject` to actually use this facility will be in another PR.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
All of the following authorities should resolve to
foo.ns.svc.cluster.local:foofoo.nsfoo.ns.svcfoo.ns.svc.cluster.localThe text was updated successfully, but these errors were encountered: