<p>It might be a question based on curiosity which couldn't find help on google.</p>

<p>Consider this part of the yaml for a headless service:</p>

<pre><code>ports:
 - port: abcd  --&gt; this line
</code></pre>

<p>My 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 <a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services" rel="noreferrer">documentation</a> for services states that:</p>

<blockquote>
  <p>“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.</p>
</blockquote>

<p>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?</p>

<p>I have seen issues that people have faced while excluding the port value from the definition of headless service (<a href="https://github.com/kubernetes/kubernetes/issues/55158" rel="noreferrer">here</a>). This seems to have been fixed. But then, do we really have a use-case for the port functionality of a headless service?</p>

<blockquote>
  <p>But then, do we really have a use-case for the port functionality of a headless service?</p>
</blockquote>

<p>IMHO, yes: because the very idea of a <code>Service</code> is not "a random IP address" -- otherwise it would be called <code>DHCPIPAddress</code>. The idea of a <code>Service</code> in kubernetes is that you can consume some network functionality using one or more tuples of <code>(address, protocol, port)</code> just like in the non-kubernetes world.</p>

<p>So it can be fine if you don't care about the port of a headless <code>Service</code>, in which case toss in <code>ports:\n- port: 80\n</code> and call it a draw, but the <strong>benefit</strong> of a headless <code>Service</code> 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 <code>Service</code>, whose name was what the previous <code>Deployment</code> expected, with the named <code>ports:</code> that the previous <code>Deployment</code> expected, but pointing to an IP that I controlled, not within the SDN.</p>

<p>Doing that, all the traditional kubernetes <code>kube-dns</code> and <code>$(SERVICE_THING_HOST)</code> and <code>$(SERVICE_THING_PORT)</code> injection worked as expected, but abstracted away the fact that said <code>_HOST</code> temporarily lived outside the cluster.</p>
