我觉得你需要一些理论。整个互联网上有很多解释（包括官方文档），但我认为Marco Luksa做得最好：
到服务的每个连接被转发到一个随机选择的后备pod。但是如果客户端需要连接到所有这些pod呢？如果备份pod本身需要每个连接到所有其他备份pod。通过服务连接显然不是这样做的方式。是什么？
对于连接到所有pod的客户端，它需要计算出每个pod的IP。一种选择是让客户端调用Kubernetes API服务器，并通过API调用获取pod列表及其IP地址，但由于您应该始终努力保持应用程序与Kubernetes无关，因此使用API服务器并不理想
幸运的是，Kubernetes允许客户端通过DNS查找来发现Pod IP。通常，当您对服务执行DNS查找时，DNS服务器返回单个IP -服务的群集IP。但是，如果您告诉Kubernetes您的服务不需要集群IP（您可以通过在服务规范中将clusterIP字段设置为None来做到这一点），DNS服务器将返回Pod IP而不是单个服务IP。DNS服务器将返回服务的多个A记录，而不是返回单个DNS A记录，每个A记录都指向当时支持服务的单个pod的IP。因此，客户端可以执行简单的DNS A记录查找，并获取属于该服务的所有Pod的IP。然后，客户端可以使用该信息连接到其中的一个、多个或全部。
将服务规范中的clusterIP字段设置为None会使服务无头，因为Kubernetes不会为其分配集群IP，客户端可以通过该IP连接到支持它的Pod。
《Kubernetes in Action》作者：Marco Luksa

让我把这个问题分解成每个子部分，就像我们在敏捷中所做的那样。
究竟什么是无头服务。
它用于发现单个Pod（特别是IP），允许另一个服务直接与Pod交互，而不是代理。使用NodePort，LoadBalancer，ExternalName和ClusterIP客户端通常通过Service（Kubernetes Services simply visually explained）连接到Pod，而不是直接连接。
它实现了什么？
要求是不像其他服务类型的情况下那样使用单个IP。我们需要所有的吊舱的IP坐在后面的服务。
它有哪些合理的使用案例？

• 创建有状态服务。
• 将RabbitMQ或Kafka（或任何消息代理服务）部署到Kubernetes需要为RabbitMQ集群节点设置一个有状态集。
• 关系数据库的部署
• 还有更多

一些实际行动
部署配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  labels:
    app: server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

常规服务

apiVersion: v1
kind: Service
metadata:
  name: regular-svc
spec:
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

无头服务

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None # <= Don't forget!!
  selector:
    app: web
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

创建所有资源并运行tmp pod。

k run tmp01 --image=tutum/dnsutils -- sleep infinity

k exec tmp01 -it -- /bin/sh

#=> nslookup regular-svc
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   regular-svc.moon.svc.cluster.local
Address: 10.109.150.46

#=> nslookup headless-svc
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   headless-svc.moon.svc.cluster.local
Address: 172.17.0.31
Name:   headless-svc.moon.svc.cluster.local
Address: 172.17.0.30
Name:   headless-svc.moon.svc.cluster.local
Address: 172.17.0.32

DNS服务器为headless-svc.moon.svc.cluster.localFQDN返回三个不同的IPs。

**注1：**对于无头服务，客户端可以通过连接到服务的DNS名称来连接到其Pod，就像使用常规服务一样。但是对于无头服务，因为DNS返回pod的IP，所以客户端直接连接到pod，而不是通过服务代理。
**注2：**Headless服务仍然提供跨Pod的负载均衡，但通过DNS轮询机制，而不是通过服务代理。

Headless服务是指没有分配clusterIP地址的服务。这是通过将clusterIP设置为None来实现的。
这是什么意思？：kube-proxy不会处理这些类型的服务，因此不会为无头服务提供负载平衡或代理，相反，DNS响应将包含作为服务一部分的每个端点（podIP）的所有IP地址列表。
何时使用：

• 当您不想使用Kubernetes服务发现机制时，可以使用它。
• 使用stateful set。

无头服务（docs）