<p>I'm new to kubernetes and I'm setting up some test environments to do some experiments with in minikube. So I have two pods running python, connected trough a service (I verified that they are selected trough the same service). </p>

<p>I want to open a socket connection between the two. The container ip is equal to the IP specified in the service. On Pod1 I create the socket and connect to localhost and the port belonging to the container. </p>

<p>I'm not sure whether I should actually connect to localhost or the name of the service. Then on the other pod (Pod2) I connect to the name of the service (if I understand correctly the service should exposes the IP with the name that corresponds to the service name). </p>

<p>Pod2 refuses to connect to Pod1 in the aforementioned configuration. </p>

<p>If I let Pod1 create a socket with as IP address the service name I get the "Cannot assign requested address" on socket creation.</p>

<p>So I think I'm just choosing the IP address wrongly.</p>

<p>Thanks in advance</p>

mememan
<p>A <strong>Service</strong> collects a set of Pods under a common name (also providing a DNS name for easy lookup from other deployments on the same cluster). The intended use of a Service is not to create a connection between Pods <em>inside</em> of the same Service but to provide a common name that directs the caller to <em>any</em> of the Pods that back the Service. Think of a web server that needs to scale when more requests are coming in, but you don't want to update the IP information everywhere all the time. Just lookup the DNS and pick one of the IPs that the DNS lookup resolves to for simple random load balancing.</p>

<p>It seems as if you try to just talk between two different Pods over the network. In that case, your Pods should just be standalone and you don't need a Service to resolve to their respective IPs for interconnection.</p>

<p>Deploy each of your Pod providing <code>hostname</code> and <code>subdomain</code> fields to provide a proper in-cluster DNS entry like so:</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: alice
spec:
  hostname: alice
  subdomain: talk
  containers:
  - image: your-image:version
    args: ["alice"]
    name: main
---
apiVersion: v1
kind: Pod
metadata:
  name: bob
spec:
  hostname: bob
  subdomain: talk
  containers:
  - image: your-image:version
    args: ["bob"]
    name: main
</code></pre>

<p>Now, if you imagine running your container with the command-line argument <code>"alice"</code>, as the first Pod does, you can easily connect to</p>

<pre><code>bob.talks.default.svc.cluster.local
</code></pre>

<p>which is the FQDN for the second Pod. Same holds vice versa. If you want to expose certain ports, do so in the Pod spec; read up on naming ports for portability and independence of the actual port number when looking it up inside the cluster.</p>

<p>A few notes:</p>

<ul>
<li>of course, you need to adapt the <code>image</code> and <code>args</code> to your actual container setup</li>
<li>the <code>default</code> part in the FQDN is your Namespace; it will be different if you do not deploy to the default Namespace</li>
<li>the <code>hostname</code> and <code>subdomain</code> fields are optional and there are defaults (see source link), but better explicit than implicit</li>
</ul>

<p>Kubernetes docs on DNS for Pods: <a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods</a></p>
