0

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
  • 697
  • 10
  • 25
  • what type of service is `kubia`? It needs to be NodePort or LoadBalancer for it to be accessed from the outside of your Minikube cluster. Run `kubectl get svc/kubia` – sulabh chaturvedi Oct 24 '19 at 13:51
  • But I'm trying access to the service from within the cluster, from a pod that is a part of the cluster. I added to the post the YML file of the service. @sulabhchaturvedi – nirkov Oct 24 '19 at 14:12
  • No, you're not. As, your cluster is Minikube which is deployed with a VM (vm-driver) and you are running commands on your machine. Update your service type to `NodePort` and run, `minikube services kubia --url` and run the ouput url in your browser. – sulabh chaturvedi Oct 24 '19 at 14:31
  • I will try this. But, why actually the below command works for me? what is the difference? - `kubectl exec kubia-gqd5l -- curl -s http://10.111.178.111` – nirkov Oct 24 '19 at 14:37
  • because with that command, you are executing a shell command (curl) in your pod directly – sulabh chaturvedi Oct 24 '19 at 15:17
  • Sorry, I don't understand. How trying to send a request to the service from within a pod which leaves inside minikube is considering as from outside of the cluster? – nirkov Oct 24 '19 at 18:37

2 Answers2

1

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
  • 4,036
  • 1
  • 10
  • 16
  • I added the service's YML file to my post. It seems to me that I'm doing what the docs suggest so I don't understand what is the problem. – nirkov Oct 24 '19 at 18:05
  • Seeing 3 endpoints "behind" the service means that the selector in the Service definition is correct. Could you check if DNS pods are actually running and healthy? For example: `kubectl -n kube-system get pods`, look at the READY column of pods with "dns" in the name like "coredns". – apisim Oct 24 '19 at 20:39
  • You right :| I see that the dns pods crashed. `coredns-5c98db65d4-hsnwx 0/1 CrashLoopBackOff 768 43d coredns-5c98db65d4-w7jrk 0/1 CrashLoopBackOff 767 43d ` How can I fix that? – nirkov Oct 25 '19 at 13:51
  • Aside from the "usual" trobleshooting of CrashLoopBackOff error (get the events, logs...), there are some related SO questions that may help you: https://stackoverflow.com/search?q=+CrashLoopBackOff+coredns – apisim Oct 25 '19 at 14:35
0

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
  • 2,202
  • 2
  • 20
  • 31