Kubernetes Service之ExternalName Service、Headless Service

K8s的Service资源是一种为一组功能相同的Pod提供统一不变的流量入口的资源。这里介绍其中的ExternalName Service、Headless Service

abstract.png

对集群外运行的后端进行代理

楔子

在开始之前我们先创建一个RS及其对应的Service,配置文件如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# API组、版本
apiVersion: apps/v1
# 资源类型
kind: ReplicaSet
metadata:
# RS名称
name: my-kubia-rs-1
spec:
# 副本数量
replicas: 3
# 标签选择器
selector:
matchLabels:
app: kubia
# Pod 模板
template:
metadata:
# 标签信息
labels:
app: kubia
spec:
# 容器信息
containers:
- name: my-kubia-1
image: luksa/kubia
# 仅用于展示容器所使用的端口
ports:
- containerPort: 8080
protocol: TCP

---

# API组、版本
apiVersion: v1
# 资源类型
kind: Service
metadata:
name: kubia-service
spec:
# Service类型
type: ClusterIP
# 标签选择器
selector:
app: kubia
ports:
- port: 9696 # 服务监听端口
targetPort: 8080 # 服务将请求转发到的目标端口

创建上述资源后,查看该Service。不难看出,在Service中还有一个Endpoints资源。事实上,服务并不是直接与Pod直接相连的。而是通过Endpoints资源进行关联。具体地,服务会通过标签选择器来构建Pod的IP、Port列表。然后存储在Endpoints资源当中

figure 1.jpeg

无标签选择器的Service

现在我们将服务与Endpoints资源进行解耦。先创建一个不包含标签选择器的Service,然后创建一个对应于该服务的Endpoints资源。具体地,我们在Endpoints资源中描述在服务某端口收到请求后,会将该请求转发重定向至哪个IP、Port上。通过这种方式即可实现服务对集群外运行的后端的代理。即K8s集群内部Pod只需通过访问该服务,即可实现对集群外运行的后端的访问

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# API组、版本
apiVersion: v1
# 资源类型
kind: Service
metadata:
# 资源名称
name: external-service-1
spec:
# Service类型
type: ClusterIP
ports:
- name: visit-port # 服务端口名称
port: 9999 # 服务监听端口
- name: test-port # 服务端口名称
port: 8888 # 服务监听端口

---

# API组、版本
apiVersion: v1
# 资源类型
kind: Endpoints
metadata:
# Endpoints的资源名称需要与相应的服务名称保持一致
name: external-service-1
subsets:
# 服务将收到的请求进行转发的目的地址、端口信息
- addresses:
- ip: 180.101.49.11 # 百度 IP
- ip: 202.89.233.100 # Bing IP
ports:
# 端口名称 需与 服务端口的名称对应起来
# 以便将指定服务端口收到的请求 转发重定向 至 目标端口上
- name: visit-port
port: 80 # 目标端口信息
- name: test-port
port: 443 # 目标端口信息

创建上述资源后,我们来看下该服务的Endpoints资源。可以看到该服务收到请求后,会转发至我们期望的IP、Port上

figure 2.jpeg

现在我们通过Pod来访问该服务,可以看出其成功将请求分发到外部两个不同的IP了

figure 3.jpeg

ExternalName Service

我们还可以使用ExternalName Service来实现对外部服务的访问,直接通过externalName指定外部服务的域名即可。由于ExternalName Service是在DNS级别进行实施。即为服务创建了DNS CNAME记录。故访问该服务时会直连外部的服务,因此该ExternalName Service甚至不会获得集群IP

1
2
3
4
5
6
7
8
9
10
11
# API组、版本
apiVersion: v1
# 资源类型
kind: Service
metadata:
# 资源名称
name: external-service-3
spec:
type: ExternalName
# 指定外部服务的域名
externalName: cn.bing.com

创建上述资源后,我们就可以直接通过该服务的FQDN进行访问了。效果如下所示

figure 4.jpeg

Headless Service

对于ClusterIP Service而言, 当clusterIP为None时, 表示这是一个Headless Service。换言之,此时服务将不会被分配集群IP。当集群内的Pod对该服务进行DNS查找时,会获取到该服务关联的所有Pod的DNS A记录。即会返回该服务所关联的所有Pod的IP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
# 创建 Linkedin 应用的RS资源

apiVersion: apps/v1
# 资源类型
kind: ReplicaSet
metadata:
name: my-linkedin-app
spec:
# 副本数量
replicas: 4
# 标签选择器
selector:
matchLabels:
company: LinkedIn
# Pod模板
template:
metadata:
# 标签信息
labels:
company: LinkedIn
spec:
# 容器信息
containers:
# 容器名称
- name: my-linkedin-app
# 镜像信息
image: luksa/kubia
# 仅用于展示容器所使用的端口
ports:
- containerPort: 8080
protocol: TCP

---

# 创建 Linkedin 应用的Headless Service资源

apiVersion: v1
kind: Service
metadata:
name: my-linkedin-headless-service
spec:
# 对于默认类型的ClusterIP服务而言
# 当clusterIP为None时, 表示这是一个Headless Service
clusterIP: None
selector:
company: LinkedIn
ports:
- port: 12121 # 服务监听端口
targetPort: 8080 # 服务将请求转发到Pod的目标端口

---

# 创建一个包含nslookup命令的Pod

apiVersion: v1
kind: Pod
metadata:
# Pod 名称
name: my-dnsutils
spec:
# 容器信息
containers:
- name: my-dnsutils
# 镜像信息
image: tutum/dnsutils
# 设置容器启动时执行的命令、参数
command: # 该命令可以保持容器一直运行, 而不会结束退出
- sleep
- infinity

效果如下所示

figure 5.jpeg

参考文献

  1. Kubernetes in Action中文版 Marko Luksa著
  2. 深入剖析Kubernetes 张磊著
0%