Hello :)
So, the problem seems to be in node :(
I tested in pod with dns-utils on board I was not able to resolved svc
name.
I've performed the same tests directly on node where affected pod is
running, and just like I thought , I'm not able to resolved the svc names
either - connection time
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
Ok, let's see:
I've checked the /etc/resolv.conf in pod:
[image: 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:
[image: Obraz w treści 3]
The origin
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
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
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 :
> I had that
I had that happen quite a bit within containers based on alpine linux
Cam
On Thu, 19 Oct 2017 at 23:49 Łukasz Strzelec
wrote:
> Dear all :)
>
> I have following problem:
>
> [image: Obraz w treści 1]
>
>
> Frequently I have to restart origin-node to solve this issue,
Dear all :)
I have following problem:
[image: 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 -