Service的无头服务（headless类型的service）
[root@K8s-master01 chapter7]#kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql ClusterIP 10.98.118.147 <none> 3306/TCP 5d22h
Service的各类型中，ClusterIP、NodePort和LoadBalancer都为其Service配置一个ClusterIP，CoreDNS上，这些Service对象的A记录也解析为它的ClusterIP；
广义上，那些没有ClusterIP的Service则称为Headless Service，它们又可以为分两种情形
⚫ 有标签选择器，或者没有标签选择器，但有着与Service对象同名的Endpoint资源
◆ Service的DNS名称直接解析为后端各就绪状态的Pod的IP地址
◆ 调度功能也将由DNS完成
◆ 各Pod IP相关PTR记录将解析至Pod自身的名称，假设Pod IP为a.b.c.d，则其名称为a-b-c-d.<service>.<ns>.svc.<zone>
◆ 这种类型也就是狭义上的Headless Service
⚫ 无标签选择器且也没有与Service对象同名的Endpoint资源
◆ Service的DNS名称将会生成一条CNAME记录，对应值由Service对象上的spec.externalName字段指定
示例：无ClusterIP，调度功能交给了DNS的资源记录
[root@K8s-master01 chapter7]#cat demoapp-headless.yaml
kind: Service
apiVersion: v1
metadata:
name: demoappheadless
namespace: default
spec:
clusterIP: None
selector:
app: demoapp
version: v1.2
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
创建service并查看
[root@K8s-master01 chapter7]#kubectl apply -f demoapp-headless.yaml
service/demoappheadless created
[root@K8s-master01 chapter7]#kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demoappheadless ClusterIP None <none> 80/TCP 10s
集群某一pod对他进行访问
[root@K8s-node02 ~]#curl demoapp-headless.default
可以访问成功
[root@K8s-master01 chapter7]#host -t A demoapp-headless.default
demoapp-headless.default.svc.cluster.local has address 192.168.108.3
demoapp-headless.default.svc.cluster.local has address 192.168.119.3
调度功能交给了DNS的资源记录，并且CoreDNS默认对某一名称做解析的时候，如果有多条记录，是使用负载均衡的方式来完成解析
并且可以反解
[root@K8s-master01 chapter7]#host -t PTR 192.168.108.3
示例：ExterName Service：目的将名称解析为外部的DNS名称，从而作为对外部服务的访问而存在，基于此，就没必要为其提供ClusterIP。
ExterName Service先解析外部服务的名字，由名字再解析成IP地址
[root@K8s-master01 chapter7]#cat externalname-redis-svc.yaml
kind: Service
apiVersion: v1
metadata:
name: externalname-redis-svc
namespace: default
spec:
type: ExternalName #类型为ExternalName
externalName: redis.ik8s.io #外部服务的名字
ports:
- protocol: TCP
port: 6379
targetPort: 6379
nodePort: 0
selector: {}
创建并查看：
[root@K8s-master01 chapter7]#kubectl apply -f externalname-redis-svc.yaml
service/externalname-redis-svc created
[root@K8s-master01 chapter7]#kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
externalname-redis-svc ExternalName <none> redis.ik8s.io 6379/TCP 7s
对service进行解析：
[root@K8s-master01 chapter7]#host -t A externalname-redis-svc
externalname-redis-svc.wang.org has address 205.178.189.129
总结
1、Service Name解析成别名（CNAME：Canonical Name）
ExterName Service要点：没有selector
能够以名称解析方式，将集群外部的服务，引入到集群上来，从而集群内部的客户端能使用集群服务名称来访问集群外部的服务；
将集群外部的服务引入到集群上来的另一种方法：自建 Endpoints资源对象
任何存在标签选择器的Service，在创建时，都会被自动创建一个同名的Endpoints资源对象
Endpoints对象会使用Label Selector自动发现后端端点，并各端点的IP配置为可用地址列表的元素
对于集群外部的服务端点：（如有状态应用mysql，想让集群内布的客户端访问它）
手动创建一个Endpoints资源对象，直接把外部端点的IP地址，放入可用地址列表；
额外创建一个不带selector的同名的Service对象
将集群外部的服务引入到集群上来的示例如下：
apiVersion: v1
kind: Endpoints
metadata:
name: mysql-external
namespace: default
subsets:
- addresses:
- ip: 172.29.9.51
- ip: 172.29.9.52
ports:
- name: mysql
port: 3306
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
name: mysql-external
namespace: default
spec:
type: ClusterIP
clusterIP: None #可直接使用集群内部的名字，解析集群外部的地址
ports:
- name: mysql
port: 3306
targetPort: 3306
protocol: TCP
service重点非常多：
如：
service的类型
service的模式
service的整体确保客户端访问服务端的时候的逻辑
如：先名称解析,由CoreDNS参与，所有解析的IP地址，IP地址会存在于何处，iptables何ipvs模式各不一样，随后又如何转到端点上去的。
作业：
1、把service mode调整为ipvs；以及在部署集群时，使用文档中第二种初始控制平面第一个节点的方式，配置其默认直接使用ipvs；
2、Pod/Wordpress-APACHE, 部署在Kubernetes上，Service使用ExternalIP接入； MySQL要部署在集群外部，Wordpress基于Kubernetes SErvice名称访问MySQL;
3、Pod/Wordpress-FPM和nginx, 部署在Kubernetes上，Nginx Service使用ExternalIP接入，并反代给Wordpress；MySQL要部署在集群外部，Wordpress基于Kubernetes SErvice名称访问MySQL;
4、Pod/Tomcat-jpress和Nginx，部署在Kubernetes上，Nginx Service使用ExternalIP接入，并反代给tomcat；MySQL要部署在集群外部，jpress基于Kubernetes SErvice名称访问MySQL;
