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).
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.
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).
Pod2 refuses to connect to Pod1 in the aforementioned configuration.
If I let Pod1 create a socket with as IP address the service name I get the "Cannot assign requested address" on socket creation.
So I think I'm just choosing the IP address wrongly.
Thanks in advance
If Pod1 and Pod2 are supposed to be different apps that talk to each other then you should create a different service for each one of them. After you create the services you can easily use Kubernetes Service Discovery to get the IPs and ports of your services inside a pod.
A Service 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 inside of the same Service but to provide a common name that directs the caller to any 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.
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.
Deploy each of your Pod providing hostname
and subdomain
fields to provide a proper in-cluster DNS entry like so:
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
Now, if you imagine running your container with the command-line argument "alice"
, as the first Pod does, you can easily connect to
bob.talks.default.svc.cluster.local
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.
A few notes:
image
and args
to your actual container setupdefault
part in the FQDN is your Namespace; it will be different if you do not deploy to the default Namespacehostname
and subdomain
fields are optional and there are defaults (see source link), but better explicit than implicitKubernetes docs on DNS for Pods: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods