1 Introduction
Headless Service is a special type of service that does not assign virtual IPs, but directly exposes the IP and DNS records of all Pods. This client can directly access the Pod IP addresses and use these IP addresses for load balancing.
Headless Services is a special service whose spec:clusterIP is expressed as None, so that ClusterIP will not be assigned during actual operation. Also known as a headless service.
Case:
Create a Headless Service as follows:
apiVersion: v1
kind: Service
metadata:
name: statefulset-service
spec:
clusterIP: None
selector:
app: statefulset-app
ports:
- name: http
port: 80
This creates a Headless Service named statefulset-service , and selects all Pods with the label app: statefulset-app as its backend.
When querying the DNS records of the Service, you will get the following results:
$ nslookup statefulset-service.default.svc.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: statefulset-service.default.svc.cluster.local
Address: 10.244.0.5
Name: statefulset-service.default.svc.cluster.local
Address: 10.244.0.6
Name: statefulset-service.default.svc.cluster.local
Address: 10.244.0.7
As you can see, three IP addresses were returned, corresponding to the IP addresses of the three Pods.
If you want to access one of the Pods, such as pod-1, you can use a domain name like pod-1.statefulset-service.default.svc.cluster.local to access it.
2 How Headless works
When you create a headless service named statefulset-service , Kubernetes will create a DNS record for each Pod. The name of this DNS entity is of the form: " {podname}.{headless-name}.{namespace}.svc.cluster.local ".
- {podname} is the Pod name
- {headless-name} is the Headless service name
- {namespace} is the namespace name
When querying " pod-1.statefulset-service.default.svc.cluster.local ", an A record containing all matching Pod IP addresses will be returned in DNS. This means that the Headless service can be accessed directly through the Pod IP address and use CoreDNS to return the IP address in the A record for load balancing ( of course you can use the configured LoadBalancer instead of the load balancing provided by Kubernetes).
3 Headless advantages and disadvantages
3.1 Advantages
- Highly dynamic and scalable : Since there is no virtual VIP, the Headless service has no limit on the number of Pods and is highly dynamic and scalable.
- Direct access to Pod IP address : Compared to ClusterIP, there is no default load balancer in the Headless service, so you can directly access the actual IP address of the Pod.
- Support for API selectors : In the Headless service, API selectors are supported. This allows us to select specific Pods based on tags.
3.2 Disadvantages
- No default load balancer : Since there is no default load balancer, we need to load balance manually.
4 Differences between Headless and ClusterIP
ClusterIP is the default service type of Kubernetes. It provides a virtual IP for the Pod group and performs load balancing through proxy mode. When writing a Service configuration file, the ClusterIP type is usually specified. This allows you to use Virtual IP to access Pod groups across nodes in Kubernetes.
On the other hand, the Headless service type does not assign virtual IPs, but directly exposes the DNS records of all Pods. There is no default load balancer and the Pod IP address is directly accessible. Therefore, the Headless service comes in handy when direct interaction with the real Pod IP address in the cluster is required.
5 Differences between headless svc and ordinary svc
Ordinary svc
It can be regarded as a headed svc, which means that the svc itself also has an address (cluster ip). When dns queries, only the address of the Service will be returned. The specific Real Server that the client accesses is determined by iptables.
headless svc
headless, headless means that the load balancing of this svc does not have clusterip, and the dns query will faithfully return 2 real endpoints.
6 Headless usage scenarios
The headless service type is usually suitable for distributed applications that need to directly access the Pod IP address, especially in the following scenarios:
- Database cluster : Database clusters require high availability and scalability, and each node needs to be accessible at all times. The headless service can assign a unique DNS entity name to each node, thereby supporting direct access to the Pod IP address to achieve load balancing and failover.
- Message queue : Message queue requires high throughput and low latency to support real-time data processing and streaming computing. The headless service can assign a unique DNS entity name to each node, thereby supporting direct interaction with the node and load balancing, and achieving efficient data transmission.
- Distributed cache : Distributed cache needs to support data synchronization and replication between multiple nodes, and requires that each node can be accessed at any time. The headless service can assign a unique DNS entity name to each node, thereby supporting direct access to the Pod IP address and achieving high availability and reliability of data.
- Ultra-high-performance applications : Ultra-high-performance applications need to support dynamic scaling and load balancing, and need to be able to be accessed by every node at all times while being sensitive to latency. The headless service can assign a unique DNS entity name to each node, thereby supporting direct access to the Pod IP address and achieving high availability and reliability. In these cases, each node has its own identity and state, requiring the use of persistent storage for data sharing.
When calling a node, the individual services and endpoints are less important than ensuring that the correct node is tracked during data sharing. In this case, using the Headless service is very useful.
7 Why use headless service+statefulSet to deploy stateful applications?
Headless service is generally used in conjunction with statefulSet, and its relationship is:
- The headless service will assign a domain <service name>.$<namespace name>.svc.cluster.local to the associated Pod.
- StatefulSet will maintain a constant Pod Name for the associated Pod. The hostname format of the Pod in the statefulset is $(StatefulSet name)-$(pod serial number)
- StatefulSet will assign a dnsName to the associated Pod. The domain name standard is: $<Pod Name>.$<service name>.$<namespace name>.svc.cluster.local.
Headless Service is first and foremost a Service. A general Service can be accessed internally and externally. The reason why it is called Headless Service is that it only provides internal access and needs to provide stable access capabilities, otherwise it will have no effect. For example, it has a fixed Pod name and storage, so it is generally used in conjunction with StatefulSet to deploy stateful applications.
8 The impact of Headless on Kube-proxy
The impact of the headless service on Kube-proxy is mainly reflected in its load balancing implementation. In Kubernetes, Kube-proxy is responsible for providing load balancing functions for the Service so that the client can directly connect to any Pod. For ClusterIP type services, Kube-proxy will create a virtual IP address and send the request to one or more Pods bound to the address.
For Headless Service, Kube-proxy creates a set of DNS records to resolve to the IP address of each Pod. In this way, the client can obtain the IP address of the Pod through DNS resolution and establish a direct connection with it, completely bypassing the Kube-proxy component.
For the Kube-proxy + IPVS method (that is, using IPVS to implement load balancing of Kube-proxy), Headless services will also not be affected by IPVS because they all achieve load balancing by directly accessing the Pod IP address. In this case, IPVS only provides the network layer forwarding function and has no deeper intervention.
Therefore, when using Headless services, manual load balancing is required.
9 How CoreDNS works with Headless
CoreDNS is the default DNS server in Kubernetes and manages service discovery for the entire cluster. CoreDNS is a separate container that runs on each node. When CoreDNS starts, it retrieves the entire service definition from kube-apiserver and converts it into a DNS record.
When you create a headless service, CoreDNS will create a DNS record for each Pod that points directly to the Pod's actual IP address. This will facilitate direct access to Pods in the Headless service type.
The ability to use the headless service's traffic balancing load is implemented by CoreDNS's RR polling algorithm.
10 The relationship between Headless and Endpoint
All Pods under the headless service type will be published to the Kubernetes API server as independent Endpoints. This allows other Kubernetes components suitable for the ClusterIP service type to discover and route it.
In the Headless service, you can use the Endpoints object to access all Pod IP addresses. This is an object automatically generated by Kubernetes, which contains all Endpoint information of the corresponding Service.
In terms of the Endpoint object, its main role is to manage specific Pod IP addresses and keep synchronized with the Headless service. When a Pod fails or needs to be expanded, the Endpoint object is updated in time and ensures that the Headless service always has the latest Pod IP address. This ensures that developers can always access available Pods and ensures the stability and reliability of the application.
11 How does Selector affect Headless and CoreDNS?
Clusters using CoreDNS are configured with automatic service discovery by default, which can automatically generate DNS resolution records based on Service and Endpoint objects. For ordinary Service objects, CoreDNS will map its ClusterIP to a domain name, which is {service-name}.{namespace}.svc.cluster.local . For Headless Service, since there is no Selector object, CoreDNS will not generate the corresponding A record, but only the SRV record.
Specifically, in a Kubernetes cluster using CoreDNS, for Headless Service, CoreDNS will generate an SRV record under the domain name .{service-name}.{namespace}.svc.cluster.local . This record contains each Pod. IP address and port number. The client can obtain the addresses and port numbers of all Pods by querying this SRV record and connect. In other words, the Headless Service can work normally in a Kubernetes cluster using CoreDNS and provides a more flexible load balancing method. The client can flexibly select the Pod to connect to by querying the SRV record.
It should be noted that in a scenario using CoreDNS + Headless Service, if you want to implement service discovery and load balancing functions, the client must support the SRV record type. Therefore, when developing applications, you need to ensure that the client can correctly parse and use SRV records.
12 Risks of using Headless
- Directly exposing the DNS records of all Pods may lead to security vulnerabilities. Malicious users may exploit the Headless service type to attack the system.
- Since there is no default load balancer, manual load balancing is required. This may result in overworked workloads for some personnel and complicated management.
- Using the Headless service may increase the workload of the DNS server. In larger clusters with a large number of Pods and Headless services, the DNS server can become a bottleneck.