Hide Forgot
Description of problem: This is concern from customer. They found that from WebConsole, The service hostname shows a info and says: This address is only resolvable from within the cluster. However when they $nslookup the hostname such as: <svc>.<project>.svc from node. The DNS will return : <svc>.<project>.svc.cluster.local instead of the one without .cluster.local. The question is, which is correct that our internal DNS service (skyDNS) can do. From my test, the resolve can not be directly success and sent to upstream DNS Server. If the upstream return no match then it will auto add the search domain "cluster.local" and then get the correct answer from local DNS. The customer concern about the info from WebConsole which tells them that "<svc>.<project>.svc" can be resolved inside the cluster and the result doesn't match that. Actual results: - The result doesn't match the info provided from webconsole. Expected results: - 1. Need to know which kind of name could be resolved. Must contains "cluster.local"? - 2. Is there any details info about skyDNS ? how to config it ? - 3. If sky DNS can only resolve the name contains cluster.local, the info from WebConsole may caused some misunderstanding for customer. This question can be repo in all of OCP version begin from 3.6 Thanks a lot.
`<service>.<namespace>.svc` should resolve from inside a pod as well, but we will update the hostname in the console to use the fully-qualified `.cluster.local`. https://github.com/openshift/origin-web-console/pull/3111
check service instance on web console, hostname will be <svc>.<ns>.svc.cluster.local with suffix 'cluster.local'. OpenShift Master: v3.11.82 Kubernetes Master: v1.11.0+d4cacc0 OpenShift Web Console: v3.11.83 verified this bug
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0326