Everything looks fine (except for the double nameserver entry, but that
shouldn't cause any problems).
Try running the following:
oc run dnstest -it --restart Never --rm --image tutum/dnsutils bash
And then try looking up your service through the container's default
nameserver:
dig kibanasg +short +search
and through the DNS running on the master:
dig kibanasg +short +search @kubernetes.default
or, if that doesn't work, use the master's IP:
dig kibanasg +short +search @ip_of_openshift_master
You can also try looking up the kubernetes service:
dig kubernetes.default +short +search @ip_of_openshift_master
This should give you an idea of where the problem is. If you get the
service IP when querying the master directly, then the problem is
obviously in the node's dnsmasq.
M.
On 23. 10. 2017 08:16, Łukasz Strzelec wrote:
Ok, let's see:
I've checked the /etc/resolv.conf in pod:
Obraz w treści 2
the 10.111.208.195 is the node ip -on which the dnsmasq was started.
What is strange the pod is obtaining duplicated entries.
On node, the /etc/resolv.conf has entries:
Obraz w treści 3
The origin node config file has got exactly the same ip address which
is the IP of node.
Best regards
2017-10-20 15:11 GMT+02:00 Łukasz Strzelec <lukasz.strze...@gmail.com
<mailto:lukasz.strze...@gmail.com>>:
Ok, let's see:
I've checked the /etc/resolv.conf in pod:
Obraz w treści 2
the 10.111.208.195 is the node ip -on which the dnsmasq was started.
What is strange the pod is obtaining duplicated entries.
On node, the /etc/resolv.conf has entries:
Obraz w treści 3
The origin node config file has got exactly the same ip address
which is the IP of node.
Best regards
2017-10-20 14:27 GMT+02:00 Marko Lukša <marko.lu...@gmail.com
<mailto:marko.lu...@gmail.com>>:
OK, then you're most likely not using the correct DNS server
(or you're using the correct one, but it's not properly
updating its entries; but I doubt that's the case).
Check the contents of /etc/resolv.conf. Usually, the
"nameserver" line should point to the IP of the node the pod
is running on. The node runs dnsmasq, which is what your pods
should use as the DNS server. This is configured in the node's
/etc/origin/node/node-config.yaml file (look for the dnsIP
entry). If you configured it to bypass the local dnsmasq, you
won't be able to resolve internal addresses.
M.
On 20. 10. 2017 13:28, Łukasz Strzelec wrote:
Hi Marko
1. yes
2. I did and the result is the same - name or service not
known :(
Have no clue what is wrong - pods on other nodes are working
fine
Best regards :)
2017-10-20 11:19 GMT+02:00 Marko Lukša <marko.lu...@gmail.com
<mailto:marko.lu...@gmail.com>>:
1. is the service in the same namespace as the pod you're
testing in?
2. connect through the FQDN of the service
(kibanasg.fullnamespace.svc.cl
<http://kibanasg.fullnamespace.svc.cl>uster.local)
On 20. 10. 2017 11:14, Łukasz Strzelec wrote:
Thx guys ;)Nope, this is not this case.
I've notice that I can reach SVC via IP addresses. But
when I want do the same with name of svc, I'm recieving
"name or service not known". Where to start debugging ?
Best regards
2017-10-19 15:27 GMT+02:00 Mateus Caruccio
<mateus.caruc...@getupcloud.com
<mailto:mateus.caruc...@getupcloud.com>>:
Alpine's musl libc only supports "search" starting
from version 1.1.13.
Check if this is your case.
--
Mateus Caruccio / Master of Puppets
GetupCloud.com
We make the infrastructure invisible
Gartner Cool Vendor 2017
2017-10-19 10:58 GMT-02:00 Cameron Braid
<came...@braid.com.au <mailto:came...@braid.com.au>>:
I had that happen quite a bit within containers
based on alpine linux
Cam
On Thu, 19 Oct 2017 at 23:49 Łukasz Strzelec
<lukasz.strze...@gmail.com
<mailto:lukasz.strze...@gmail.com>> wrote:
Dear all :)
I have following problem:
Obraz w treści 1
Frequently I have to restart origin-node to
solve this issue, but I can't find the root
cause of it.
Does anybody has got any idea ? Where to
start looking ?
In addition , this problem is affecting
different cluster nodes - randomly diffrent
pods have got this issues.
Best regards
--
Ł.S.
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
<mailto:users@lists.openshift.redhat.com>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
<mailto:users@lists.openshift.redhat.com>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
--
Ł.S.
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
<mailto:users@lists.openshift.redhat.com>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
<mailto:users@lists.openshift.redhat.com>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
<http://lists.openshift.redhat.com/openshiftmm/listinfo/users>
--
Ł.S.
--
Ł.S.
--
Ł.S.
_______________________________________________
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
