According to the Kubernetes documentation, each container gets a set of environment variables that lets it access other services
For example, if a Service named foo exists, all containers will get the following variables in their initial environment:
FOO_SERVICE_HOST=<the host the Service is running on> FOO_SERVICE_PORT=<the port the Service is running on>
However, it seems that in my cluster I'm not getting the expected values in those variables:
tlycken@local: k exec -ti <my-pod> ash
/app # echo $SEARCH_HOST
/app # echo $SEARCH_PORT
tcp://10.0.110.126:80I would rather have expected to see something like
tlycken@local: k exec -ti <my-pod> ash
/app # echo $SEARCH_HOST
10.0.110.126
/app # echo $SEARCH_PORT
80I know that the docs also say
If you are writing code that talks to a Service, don’t use these environment variables; use the DNS name of the Service instead.
but that only gives me the host name, not the port, of the service. Therefore, I wanted to set SEARCH_HOST to search in my deployment template and rely on SEARCH_PORT to get the port, but when I put the service url together from the existing environment variables, it becomes http://search:tcp://10.0.110.126:80 which obviously does not work.
If I can't rely on the FOO_SERVICE_PORT variable to give me the port number, what should I do instead?
According to a part from kubernetes documentation posted in the question:
For example, if a Service named foo exists, all containers will get the following variables in their initial environment:
FOO_SERVICE_HOST=<the host the Service is running on> FOO_SERVICE_PORT=<the port the Service is running on>
The variable name is <your_service_name>_SERVICE_PORT, so if your server has name SEARCH, you are able to find it host and port values using SEARCH_SERVICE_HOST and SEARCH_SERVICE_PORT environment variables:
echo $SEARCH_SERVICE_HOST
echo $SEARCH_SERVICE_PORTIf I can't rely on the FOO_SERVICE_PORT variable to give me the port number, what should I do instead?
I think the best way is to use SRV records for resolving information about service because a DNS of the cluster is providing that Service Discovery feature.
Here is an official documentation about it, but in few words, the record looks like that:
<my-port-name>.<my-port-protocol>.<my-svc>.<my-namespace>.svc.cluster.local
So, for your service it will be like:
foo-port.tcp.foo.my-namespace.svc.cluster.local, where my-namespace is a namespace of foo service.
Address of your service can be obtained from foo.my-namespace.svc.cluster.local record.