Kube.NETes的概念很多，有的著實讓人費解，比如說Headless服務，聽名字就很拗口。那Headless服務是什么，使用場景是什么。一句話總結：Headless服務就是一組Pod組成的只供集群內訪問（沒有ClusterIP）的Service，一般結合StatefulSet用于部署有狀態應用的場景。
1、Service與服務發現
提到Headless Service就得先說說Service和服務發現。
1.1、Service簡述
Service主要用于實現對一組Pod的訪問，Service 通過標簽選擇器來關聯 Pod 資源。Service對外暴露服務的方式有nodePort和loadbalancer。Service 根據訪問的端口將對應的請求轉發至后端Pod的端口上。
Service對象的IP地址（ClusterIP）是虛擬IP地址，僅在 Kubernetes集群內可訪問，外部無法訪問。一般有以下幾種方式將Service暴露給外部訪問：
- 通過hostPort方式在單一節點上做端口映射
- 通過Pod的hostNetwork配置讓Pod資源使用工作節點上的網絡
- 使用NodePort或LoadBalancer類型的Service
- 使用Ingress 資源
本質上來講，一個Service 對象對應于工作節點內核之中的一組路由規則，這些規則能夠將到達Service對象的ClusterIP的流量轉發至相應Pod對象的IP地址和端口。
每個工作節點的kube-proxy組件通過API Server持續監聽各個Service及其關聯的Pod對象，并將Service對象的創建或變動，實時寫入到當前工作節點的路由規則上。客戶端、Service及Pod對象的關系如下圖所示：
1.2、Service類型
Service 一般分為3種類型：ClusterIP、NodePort、LoadBalancer。
ClusterIP
通過集群內部IP 地址暴露服務，CusterIP地址僅在集群內部可以訪問，無法被集群外部的客戶端訪問。
NodePort
NodePort類型，將Service的端口號映射到每個Node的一個端口號上，然后分發給后端的Pod處理。這種類型的Service 既可以被集群內部客戶端通過 CIusterIP 直接訪問，也可以在集群外部客戶端通過nodeIP:nodePort進行訪問。
LoadBalancer
LoadBalancer類型建立在 NodePort基礎上，將Service映射到一個負載均衡器的IP 地址上，通常在公有云環境中使用。
客戶端通過負載均衡器的IP和Service的端號就可以訪問到具體的服務，無須再通過 kube-proxy提供的負載均衡機制進行流量轉發，可以直接將流量轉發到后端 Pod上。
如果是本地搭建LoadBalancer，一般采用metallb方案，官網地址：https://metallb.universe.tf/，有興趣的朋友自行搭建。
2、Headless Service的概念
在某些場景中，無需對外提供訪問能力，只需要在內部找到自己想找到的Pod資源時，可以通過Headless Service來實現。
這種不具有ClusterIP的Service資源就是Headless Service，該 Service 的請求流量不需要 kube-proxy 處理，也不會有負載均衡和路由規則，而是由ClusterDNS的域名解析機制直接去訪問固定的Pod資源。
一般Headless會搭配著StatefulSet一起使用，下面繼續介紹。
3、StatefulSet結合Headless使用
3.1、StatefulSet概述
StatefulSet是編排有狀態應用的控制器。所謂有狀態的應用就是一組具有唯一持久數據和固定訪問名稱的 Pod。StatefulSet主要用來部署有狀態應用，比如部署ZK、Kafka、MySQL、redis等。
有狀態的資源通常由兩個組件構成：Headless Service和StatefulSet。Headless Service用于為各個Pod資源分配唯一固定的標識，然后生成DNS 解析記錄。StatefulSet用于編排Pod 對象，并借助volumeClAImTemplate自動為Pod資源創建專有的存儲。
數據的高可用是StatefulSet會極力保障的一個特性，不管是縮容還是擴容的場景。StatefulSet控制器不支持并行擴縮容機制，它一次只啟動或者終止一個Pod 資源，避免數據錯誤。
StatefulSet、volumeClaimTemplate、PVC、PV的關系見下圖：
3.2、StatefulSet特性
有序性
StatefulSet借助 Headless Service 為每個 Pod資源分配唯一固定的標識，一般是在Pod名稱后面添加-0、-1、-2、...等等，。假設設置副本數replicas=2，啟動時，先啟動pod-0再啟動pod-1，停止時則以相反的順序進行，先停止pod-1再停止pod-0。
有狀態
無狀態應用沒有固定標識，他們不受其他Pod影響，同樣模板創建的任意Pod就可以替換之前的Pod。
有狀態應用有固定的名稱和存儲，會受到同一組內的其他Pod的影響。Pod對象如果被替換，新的Pod仍然具有相同的標識和相同的存儲。
StatefulSet使用存儲卷模板為每個 Pod 對象創建專用的 PVC存儲卷，通過volumeClaimTemplate自動創建綁定的存儲PVC不變。
刪除 Pod 對象并不會刪除相關的 PV 資源，如果Pod 對象由于節點故障等原因被重新調度到其他節點時，之前同名Pod實例專用的 PV數據可以繼續復用。
穩定服務發現
因為是有狀態的，所以想找到自己想找到的Pod，可以直接通過pod名稱.svc名稱.命名空間.svc.cluster.local訪問。
4、Yaml示例
示例部署一個Headless Service + StatefulSet，比如部署一個帶有存儲的Nginx服務。文中使用到了volumeClaimTemplates，前提要創建一個storageClassName。后面會單獨寫一篇講解PV、PVC、StorageClass、Provisioner。
apiVersion: v1
kind: Service
metadata:
name: nginx-statefulset-svc
namespace: dev
spec:
# ClusterIP | NodePort | LoadBalancer
type: ClusterIP
# headless service 這里的clusterIP使用None
clusterIP: None
selector:
App: nginx-statefulset-tpl
ports:
- name: http
port: 80
targetPort: 80
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nginx-statefulset
namespace: dev
labels:
app: nginx-statefulset
spec:
replicas: 2
serviceName: nginx-statefulset-svc
selector:
matchLabels:
app: nginx-statefulset-tpl
template:
metadata:
labels:
app: nginx-statefulset-tpl
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
# volumeClaimTemplates是StatefulSet獨有的配置，前提要先創建一個storageClassName
volumeClaimTemplates:
- metadata:
name: www
spec:
resources:
requests:
storage: 200Mi
accessModes:
- ReadWriteOnce
storageClassName: nfs-client
5、總結
一句話總結：Headless服務就是一組Pod組成的只供集群內訪問（沒有ClusterIP）的Service，一般結合StatefulSet用于部署有狀態應用的場景。
既然是Headless Service，那首先它是Service，一般的Service能被內部和外部訪問。之所以叫Headless Service是因為只對內提供訪問。既然只對內訪問，那肯定就需要提供穩定的訪問能力了，否則就沒什么作用了。比如說擁有固定的Pod名稱和存儲，所以一般會結合StatefulSet一起使用，用來部署有狀態的應用。
