Headless Service:
1. When there is no need of load balancing or single-service IP addresses.
We create a headless service which is used for creating a service grouping. That does
not allocate an IP address or forward traffic.
2.
So you can do this by explicitly setting ClusterIP to “None” in the mainfest file, which
means no cluster IP is allocated.
3.
For example:
if you host MongoDB on a single pod. And you need a service definition on top of it for
taking care of the pod restart And also for acquiring a new IP address.
1.
But you don’t want any load balancing or routing. You just need the service to patch
the request to the back-end pod.
2.
3. So then you use Headless Service since it does not have an IP.
4. Kubernetes allows clients to discover pod IPs through DNS lookups.
Usually, when you perform a DNS lookup for a service, the DNS server returns a single
IP which is the service’s cluster IP.
5.
But if you don’t need the cluster IP for your service, you can set ClusterIP to None ,
then the DNS server will return the individual pod IPs instead of the service IP.
6.
7. Then client can connect to any of them.
Command:
Note: example file you will get on next page and copy that file and run.
1. Kubectl apply -f filename.yaml
2. Kubectl get all
3. Now you can see there is there is 1 service running
4. Service is ClusterIP type but without IP and here this also called headless service.
5. Now go inside the ubuntu pod by using the below command
kubectl exec -it pod/pod_name -- /bin/bash
Now install the curl and nslookup to test the headless service benefits by using the below
command
6.
apt update&& apt install curl -y && apt install dnsutils -y
7. Now run the command " nslookup headlessservice "
8. And you get the dns and then run the below command and you get the desired result
curl headlessservice.default.svc.cluster.local:80
Conclusion:
With a Headless Service, clients can connect to its pods by connecting to the service’s DNS
name.
1.
But using headless services, DNS returns the pod’s IPs and client can connect directly to the
pods instead via the service proxy