Can't to talk with other pods using Kubernetes Service

10/24/2019

How I understand that I could be able to talk with other pods from a specific pod by sending from within the pod an HTTP request with the fully qualified domain name of the service (FQDN). The system runs locally with minikube.

The service's YML -

apiVersion: v1
kind: Service
metadata:
  name: kubia
spec:
  sessionAffinity: ClientIP 
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: kubia 

The describe of the service -

Name:              kubia
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=kubia
Type:              ClusterIP
IP:                10.111.178.111
Port:              <unset>  80/TCP
TargetPort:        8080/TCP
Endpoints:         172.17.0.7:8080,172.17.0.8:8080,172.17.0.9:8080
Session Affinity:  ClientIP
Events:            <none>

I'm trying to do that with -

 kubectl exec -it kubia-gqd5l bash

where kubia-gqd5l is the pod. In the bash I tried to sent a request by -

curl http://kubia

Where kubia is the name of the service. and I got error -

curl: (6) Could not resolve host: kubia.

It is important to note that I manage to communicate with the service by -

 kubectl exec kubia-gqd5l -- curl -s http://10.111.178.111

any idea?

-- nirkov
kubernetes
kubernetes-service

2 Answers

10/24/2019

Have a look at this answer 2 Kubernetes pod communicating without knowing the exposed address, to target a service it's better to add the namespace with the service.

-- night-gold
Source: StackOverflow

10/24/2019

Kubernetes clusters usually have DNS deployed. That allows pod to pod communications within the cluster (among other things) by using the name of the corresponding Kubernetes services. See https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

Does your Kubernetes cluster/minikube have DNS running?

Something else to check is the selector in the Service definition - make sure the pod/deployment has the app: kubia label as specified in the selector.

Otherwise, and per the doc at the link above, because the lookup of the service is from a pod in the same namespace, it shouldn't be needed to use the namespace along with the service name: (quote) "...Assume a Service named foo in the Kubernetes namespace bar. A Pod running in namespace bar can look up this service by simply doing a DNS query for foo. A Pod running in namespace quux can look up this service by doing a DNS query for foo.bar".

-- apisim
Source: StackOverflow