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 line
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 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?
With a Headless Service, clients can connect to it's pods by connecting to the service's DNS name. But using headless services, DNS returns the pod's IPs and client can connect directly to the pods instead via the service proxy.
Advantages of Headless ServicesDirect access to each pod. Easy Pod discovery in the StatefulSet. Pods can be addressed more generally by using their DNS names. Utilizes each pod's sticky identity in a stateful service (i.e. you can address a specific pod by name).
StatefulSets currently require a Headless Service to be responsible for the network identity of the Pods. You are responsible for creating this Service.
Headless servicesIf your application does not need load balancing or single-service IP addresses, you can create a headless service. When you create a headless service, no load-balancing or proxying is done and no cluster IP is allocated for this 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With