-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
4.18
-
None
-
Rejected
-
False
-
Description of problem:
While testing pod connectivity via a service we see that some pods are not able to connect using a service name.
We do see that they are able to connect using service ip, pointing us to DNS
Version-Release number of selected component (if applicable):
4.18.0-0.nightly-2024-11-10-133523
Steps to Reproduce:
1. Run udn-density-l3 workload with services
Actual results:
oc get pods NAME READY STATUS RESTARTS AGE client-1-6df5d79f46-g54sv 0/1 Running 0 17m client-1-6df5d79f46-zvk7w 0/1 Running 0 17m client-2-7b9f7c5cfc-4z78s 0/1 Running 0 17m client-2-7b9f7c5cfc-fshbq 1/1 Running 0 17m oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE udn-density-l3-1 ClusterIP 172.30.198.27 <none> 80/TCP 114m
oc rsh client-1-6df5d79f46-g54sv ~ $ curl -I 172.30.198.27 HTTP/1.1 200 OK # works ~ $ curl udn-density-l3-1 curl: (6) Could not resolve host: udn-density-l3-1 # does not work
Expected results:
whereas the other pod
oc rsh client-2-7b9f7c5cfc-fshbq curl -I udn-density-l3-1 HTTP/1.1 200 OK # works
Additional Info:
It was observed that when the pods are restarted they may or maynot be able to connect using service name
