How to make use of Kubernetes port names?

Question

In a kubernetes deployment I specify a port like so:

 containers:
 - name: nginx
   image: nginx:latest
   ports:
    - name: nginx-port
      containerPort: 80
      protocol: TCP

Now in a service I can reference that port like so (allows me to only specify the external port in the service):

spec:
  type: ClusterIP
  ports:
  - name: nginx-port
    port: 80
    targetPort: nginx-port
    protocol: TCP

Now the question, can I reference service and port elsewhere using the following syntax nginx-service.default.svc.cluster.local:nginx-port? You know I can make reference to services using this special names, but I find myself hardcoding the port number like so nginx-service.default.svc.cluster.local:80.

Burson

ok so just after I posted this I realized I could make use of the environment variables that are injected into containers i.e. $(NGINX_SERVICE_PORT). Still curious to know if something like dns names such as nginx-service.default.svc.cluster.local also exists for ports. – Burson

Answer 1

Usually, you refer to a target port by its number. But you can give a specific name to each pod`s port and refer to this name in your service specification.

This will make your service clearer. Here a small example:

apiVersion: v1
kind: Pod
metadata:
  name: named-port-pod
  labels:
    app: named-port-pod
spec:
  containers:
    - name: echoserver
      image: gcr.io/google_containers/echoserver:1.4
      ports:
      - name: pod-custom-port
        containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: named-port-svc
spec:
  ports:
    - port: 80
      targetPort: pod-custom-port
  selector:
    app: named-port-pod

Melicent

Answer 2

Kubernetes DNS service provides SRV records for all named ports of services using below format

_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example

In your case, you should be able to access it by querying below domain

_nginx-port._tcp.nginx-service.default.svc.cluster.local

Example

nslookup -type=SRV _nginx-port._tcp.nginx-service.default.svc.cluster.local

And the result:

_nginx-port._tcp.nginx-service.default.svc.cluster.local   service = 0 100 80 nginx-service.default.svc.cluster.local.

In the above output, nginx-service.default.svc.cluster.local is the target domain and 80 is the target port that you should connect to, i.e. nginx-service.default.svc.cluster.local:80

Alyssaalyssum

Answer 3

No. You can't use port name instead of port number. Name field in ServicePort has different purpose.

All ports within a ServiceSpec must have unique names. This name maps to the 'Name' field in EndpointPort objects.

For each Service, one Endpoint object is generated. Every port of that Endpoint corresponds to a Service port. Name field in both ServicePort and EndpointPort is used for this matching.

Pericline

is it documented anywhere? could you provide the link, please? thanks :) – Contraption

ServicePorts and EndpointPorts. How they fit into the grand scheme of things - I have no clue. – Bellinzona

You are not right. kubernetes.io/docs/concepts/services-networking/dns-pod-service/… – Thereof

Answer 4

kube-dns is a DNS service that uses the same protocol as all the regular DNS servers. In this sense, DNS was not designed to resolve "port names", but domain names (which map to an IP address).

What several people do is to have a reverse proxy that would ProxyPass traffic from one port to another (provided that we are talking about HTTP/HTTPS traffic) https://serverfault.com/questions/85078/how-to-forward-dns-alias-to-hostnameport or use iptables rules https://www.digitalocean.com/community/tutorials/how-to-forward-ports-through-a-linux-gateway-with-iptables. However, these assume that you would forward traffic to a specific port in the first place (for example, 80)

As you wrote in the comment, using environment variables would be the option that fits your case.

Eugenie

Answer 5

The following works as expected:

{ name: svc-port, targetPort: pod-port, port: 1111 }
{ name: pod-port, containerPort: 2222 }

i.e. defines mapping service:1111 -> pod:2222

But everything goes wrong if service.port.name == pod.port.name:

{ name: web, targetPort: web, port: 1111 }
{ name: web, containerPort: 2222 }

In this case, service:1111 leads to pod:1111 and that may be the source of your problem.

Shalon