Kubernetes--Headless类型的Service资源

Headless类型的Service资源

Service对象隐藏了各Pod资源，并负责将客户端的请求流量调度至该组Pod对象之上。不过，偶尔也会存在这样一类需求： 客户端需要直接访问Service资源后端的所有Pod资源，这时就应该向客户端暴露每个Pod资源的IP地址，而不再是中间层Service对象的ClusterIP，这种类型的Service资源便称为Headless Service。

Headless Service对象没有ClusterIP，于是kube-proxy便无须处理此类请求，也就更没有了负载均衡或代理它的需要。在前端应用拥有自有的其他服务发现机制时，Headlees Service即可省去定义ClusterIP的需求。至于何如为此类Service资源配置IP地址，则取决于它的标签选择器的定义。

• 具有标签选择器： 端点控制器（Endpoints Controller） 会在API中为其创建Endpoints记录，并将ClusterDNS服务中的A记录直接解析到此Service后端的各Pod对象的IP地址上。

• 没有标签选择器： 端点控制器（Endpoints Controller）不会在API中为其创建Endpoints记录，ClusterDNS的配置分为两种情形，对ExternalName类型的服务创建CNAME记录，对其他三种类型来说，为那些与当前Service共享名称的所有Endpoints对象创建一条记录。

 

创建Headless Service资源

配置Service资源配置清单时，只需要将ClusterIP字段的值设置为“None”即可将其定义为Headless类型。下面是一个Headless Service资源配置清单示例，它拥有标签选择器：

apiVersion: v1
metadata:
  name: myapp-headless-svc
spec:
  clusterIP: None
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80
    name: httpport

使用资源创建命令“kubectl create”或“kubectl apply” 完成资源创建后，使用相关的查看命令获取Service资源的相关信息便可以看出，它没有ClusterIP，不过，如果标签选择器能够匹配到相关的Pod资源，它便拥有Endpoints记录，这些Endpoints对象会作为DNS资源记录名称Mmyapp-headless-svc查询时的A记录解析结果：

Name:              myapp-headless-svc
······
Endpoints:         10.244.1.132:80,10.244.1.138:80,10.244.2.136:80
······

Pod资源发现

根据Headless Service的工作特性可知，它记录于ClusterDNS的A记录的相关解析结果是后端Pod资源的IP地址，这就意味着客户端通过此Service资源的名称发现的是各Pod资源。

下面依然选择创建一个专用的测试Pod对象，而后通过其交互式接口进行测试：

/ #
/ # nslookup myapp-headless-svc
Server:        10.96.0.10
Address 1:    10.96.0.10:53

Name：          myapp-headless-svc
Address 1:      10.244.2.13
Address 2:      10.244.1.113
Address 3:      10.244.3.104

 

其解析结果正式Headless Service通过标签选择器关联到的所有Pod资源的IP地址。于是，客户端向此Service对象发起的请求将直接接入到Pod资源中的应用之上，而不再由Service资源进行代理转发，它每次接入的Pod资源则是由DNS服务器接收到查询请求时以轮询（roundrobin）的方式返回的IP地址。