K8s的Service资源是一种为一组功能相同的Pod提供统一不变的流量入口的资源。这里介绍其中的ExternalName Service、Headless Service
对集群外运行的后端进行代理
楔子
在开始之前我们先创建一个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
| apiVersion: apps/v1
kind: ReplicaSet metadata: name: my-kubia-rs-1 spec: replicas: 3 selector: matchLabels: app: kubia template: metadata: labels: app: kubia spec: containers: - name: my-kubia-1 image: luksa/kubia ports: - containerPort: 8080 protocol: TCP
---
apiVersion: v1
kind: Service metadata: name: kubia-service spec: type: ClusterIP selector: app: kubia ports: - port: 9696 targetPort: 8080
|
创建上述资源后,查看该Service。不难看出,在Service中还有一个Endpoints资源。事实上,服务并不是直接与Pod直接相连的。而是通过Endpoints资源进行关联。具体地,服务会通过标签选择器来构建Pod的IP、Port列表。然后存储在Endpoints资源当中
无标签选择器的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
| apiVersion: v1
kind: Service metadata: name: external-service-1 spec: type: ClusterIP ports: - name: visit-port port: 9999 - name: test-port port: 8888
---
apiVersion: v1
kind: Endpoints metadata: name: external-service-1 subsets:
- addresses: - ip: 180.101.49.11 - ip: 202.89.233.100 ports: - name: visit-port port: 80 - name: test-port port: 443
|
创建上述资源后,我们来看下该服务的Endpoints资源。可以看到该服务收到请求后,会转发至我们期望的IP、Port上
现在我们通过Pod来访问该服务,可以看出其成功将请求分发到外部两个不同的IP了
ExternalName Service
我们还可以使用ExternalName Service来实现对外部服务的访问,直接通过externalName指定外部服务的域名即可。由于ExternalName Service是在DNS级别进行实施。即为服务创建了DNS CNAME记录。故访问该服务时会直连外部的服务,因此该ExternalName Service甚至不会获得集群IP
1 2 3 4 5 6 7 8 9 10 11
| apiVersion: v1
kind: Service metadata: name: external-service-3 spec: type: ExternalName externalName: cn.bing.com
|
创建上述资源后,我们就可以直接通过该服务的FQDN进行访问了。效果如下所示
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
|
apiVersion: apps/v1
kind: ReplicaSet metadata: name: my-linkedin-app spec: replicas: 4 selector: matchLabels: company: LinkedIn template: metadata: labels: company: LinkedIn spec: containers: - name: my-linkedin-app image: luksa/kubia ports: - containerPort: 8080 protocol: TCP
---
apiVersion: v1 kind: Service metadata: name: my-linkedin-headless-service spec: clusterIP: None selector: company: LinkedIn ports: - port: 12121 targetPort: 8080
---
apiVersion: v1 kind: Pod metadata: name: my-dnsutils spec: containers: - name: my-dnsutils image: tutum/dnsutils command: - sleep - infinity
|
效果如下所示
参考文献
- Kubernetes in Action中文版 Marko Luksa著
- 深入剖析Kubernetes 张磊著