[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: DNS resolving problem - in pod



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 strzelec 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 luksa 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 luksa 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.cluster.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 caruccio 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 <cameron 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 strzelec 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
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users





--
Ł.S.


_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users


_______________________________________________
users mailing list
users lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users




--
Ł.S.




--
Ł.S.



--
Ł.S.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]