It might be a question based on curiosity which couldn't find help on google.
Consider this part of the yaml for a headless service:
ports:
- port: abcd --> this lineMy doubt is when the cluster-ip for a headless service is already none (as it is a set of pods that it points to), what is the use of having the port for a service? The dns record from the documentation for services states that:
“Headless” (without a cluster IP) Services are also assigned a DNS A record for a name of the form my-svc.my-namespace.svc.cluster.local. Unlike normal Services, this resolves to the set of IPs of the pods selected by the Service. Clients are expected to consume the set or else use standard round-robin selection from the set.
Hence, if the dns that is allocated to the headless services is solely used to have endpoints into the pods, is there any use-case of having the port functionality in a headless service?
I have seen issues that people have faced while excluding the port value from the definition of headless service (here). This seems to have been fixed. But then, do we really have a use-case for the port functionality of a headless service?
But then, do we really have a use-case for the port functionality of a headless service?
IMHO, yes: because the very idea of a Service is not "a random IP address" -- otherwise it would be called DHCPIPAddress. The idea of a Service in kubernetes is that you can consume some network functionality using one or more tuples of (address, protocol, port) just like in the non-kubernetes world.
So it can be fine if you don't care about the port of a headless Service, in which case toss in ports:\n- port: 80\n and call it a draw, but the benefit of a headless Service is to expose an extra-cluster network resource in a manner that kubernetes itself cannot manage. I used that very trick to help us transition from one cluster to another by creating a headless Service, whose name was what the previous Deployment expected, with the named ports: that the previous Deployment expected, but pointing to an IP that I controlled, not within the SDN.
Doing that, all the traditional kubernetes kube-dns and $(SERVICE_THING_HOST) and $(SERVICE_THING_PORT) injection worked as expected, but abstracted away the fact that said _HOST temporarily lived outside the cluster.