How to access the service deployed on one pod via another pod in Kubernetes?

Question

Can anybody let me know how can we access the service deployed on one pod via another pod in a kubernetes cluster?

Example:

There is a nginx service which is deployed on Node1 (having pod name as nginx-12345) and another service which is deployed on Node2 (having pod name as service-23456). Now if 'service' wants to communicate with 'nginx' for some reason, then how can we access 'nginx' inside the 'service-23456' pod?

Answer 1

There are various ways to access the service in kubernetes, you can expose your services through NodePort or LoadBalancer and access it outside the cluster.

See the official documentation of how to access the services.

Kubernetes official document states that:

Some clusters may allow you to ssh to a node in the cluster. From there you may be able to access cluster services. This is a non-standard method, and will work on some clusters but not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.

So access a service directly from other node is dependent on which type of Kubernetes cluster you're using.

EDIT:

Once the service is deployed in your cluster you should be able to contact the service using its name, and Kube-DNS will answer with the correct ClusterIP to speak to your final pods. ClusterIPs are governed by IPTables rules created by kube-proxy on Workers that NAT your request to the final container’s IP.

The Kube-DNS naming convention is service.namespace.svc.cluster-domain.tld and the default cluster domain is cluster.local.

For example, if you want to contact a service called mysql in the db namespace from any namespace, you can simply speak to mysql.db.svc.cluster.local.

If this is not working then there might be some issue with kube-dns in your cluster. Hope this helps.

EDIT2 : There are some known issue with dns resolution in ubuntu, Kubernetes official document states that

Some Linux distributions (e.g. Ubuntu), use a local DNS resolver by default (systemd-resolved). Systemd-resolved moves and replaces /etc/resolv.conf with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers. This can be fixed manually by using kubelet’s --resolv-conf flag to point to the correct resolv.conf (With systemd-resolved, this is /run/systemd/resolve/resolv.conf). kubeadm 1.11 automatically detects systemd-resolved, and adjusts the kubelet flags accordingly.

Answer 2

Did you expose your deployment as a service? If so, simply access it by it's dns name, like http://nginx-1234 - or if it's in a different namespace: http://nginx-1234.default.svc (change "default" to the namespace the service lives in) or http://nginx-1234.default.svc.cluster.local

Now if you did NOT expose a service, then you probably should. You don't need to expose it to the outside world, simply don't define a service type and it will only be available inside your cluster.

If for some reason you don't want to expose a service (can't think of any reason), you can query the api server for the pod IP. You will need to provide a token for authentication, but these are available inside the pod:

get the token:

TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)

call the api server:

curl https://kubernetes.default.svc/api/v1/namespaces/default/pods--silent \
     --header "Authorization: Bearer $TOKEN" --insecure

you can refine your query by adding ?fieldSelector=spec.nodeName%3Dtargetnodename or similar (simply use a json path). the output can be parsed with https://stedolan.github.io/jq/ or any other JSON utility.