5.2 连接集群外部的服务

5.2 连接集群外部的服务

到现在为止，我们已经讨论了后端是集群中运行的一个或多个pod的服务。但也存在希望通过Kubernetes服务特性暴露外部服务的情况。不要让服务将连接重定向到集群中的pod，而是让它重定向到外部IP和端口。

这样做可以让你充分利用服务负载平衡和服务发现。在集群中运行的客户端pod可以像连接到内部服务一样连接到外部服务。

5.2.1 介绍服务endpoint

在进入如何做到这一点之前，先阐述一下服务。服务并不是和pod直接相连的。相反，有一种资源介于两者之间——它就是Endpoint资源。如果之前在服务上运行过kubectl describe，可能已经注意到了endpoint，如下面的代码清单所示。

代码清单5.7 用kubectl describe展示服务的全部细节

# kubectl describe svc kubia
Name:              kubia
Namespace:         custom
Labels:            <none>
Annotations:       <none>
Selector:          app=kubia  #用于创建endpoint列表的服务pod选择器
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.111.56.158
IPs:               10.111.56.158
Port:              <unset>  80/TCP
TargetPort:        8080/TCP
Endpoints:         172.18.0.2:8080,172.18.0.3:8080,172.18.0.4:8080 # 代表服务endpoint的pod的IP和端口列表
Session Affinity:  None
Events:            <none>

Endpoint资源就是暴露一个服务的IP地址和端口的列表，Endpoint资源和其他Kubernetes资源一样，所以可以使用 kubectl info 来获取它的基本信息。

$ kubectl get endpoint kubia

尽管在 spec服务中定义了pod选择器，但在重定向传入连接时不会直接使用它。相反，选择器用于构建IP和端口列表，然后存储在Endpoint资源中。当客户端连接到服务时，服务代理选择这些IP和端口对中的一个，并将传入连接重定向到在该位置监听的服务器。

5.2.2 手动配置服务的endpoint

或许已经意识到这一点，服务的 endpoint与服务解耦后，可以分别手动配置和更新它们。

如果创建了不包含pod选择器的服务，Kubernetes将不会创建Endpoint资源（毕竟，缺少选择器，将不会知道服务中包含哪些pod）。这样就需要创建Endpoint资源来指定该服务的endpoint列表。

要使用手动配置endpoint的方式创建服务，需要创建服务和Endpoint资源。

创建没有选择器的服务

首先为服务创建一个YAML文件，如下面的代码清单所示。

代码清单5.8 不含pod选择器的服务：external-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: external-service # 服务的名字必须和endpoint对象的名字相匹配
spec:
  ports:
  - port: 80

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
  externalIPs:
    - 80.11.12.10

定义一个名为external-service的服务，它将接收端口80上的传入连接。并没有为服务定义一个pod选择器。

为没有选择器的服务创建Endpoint资源

Endpoint是一个单独的资源并不是服务的一个属性。由于创建的资源中并不包含选择器，相关的Endpoints资源并没有自动创建，所以必须手动创建。如下所示的代码清单中列出了YAML manifest。

k get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
kubia-7d5b548867-4qn2x   1/1     Running   1          23h   172.18.0.2   minikube   <none>           <none>
kubia-7d5b548867-8wnls   1/1     Running   1          23h   172.18.0.3   minikube   <none>           <none>
kubia-7d5b548867-m4bfz   1/1     Running   1          23h   172.18.0.4   minikube   <none>           <none>

代码清单5.9 手动创建Endpoint资源：external-service-endpoints.yaml

apiVersion: v1
kind: Endpoints
metadata:
  name: external-service # endpoint的名称必须和服务相匹配
subsets:
  - addresses:
    - ip: 172.18.0.2 #服务将连接重定向到endpoint的ip地址
    - ip: 192.168.0.105 
    - ip: 119.147.33.43
    ports:
    - port: 8080  #endpoint的目标端口

验证一下

$ k exec -it kubia-7d5b548867-4qn2x -- bash
$ curl http://external-service

Endpoint对象需要与服务具有相同的名称，并包含该服务的目标IP地址和端口列表。服务和Endpoint资源都发布到服务器后，这样服务就可以像具有pod选择器那样的服务正常使用。在服务创建后创建的容器将包含服务的环境变量，并且与其IP:port对的所有连接都将在服务端点之间进行负载均衡。

图5.4显示了三个pod连接到具有外部endpoint的服务。

如果稍后决定将外部服务迁移到Kubernetes中运行的pod，可以为服务添加选择器，从而对Endpoint进行自动管理。反过来也是一样的——将选择器从服务中移除，Kubernetes将停止更新Endpoints。这意味着服务的IP地址可以保持不变，同时服务的实际实现却发生了改变。

5.2.3 为外部服务创建别名

除了手动配置服务的Endpoint来代替公开外部服务方法，有一种更简单的方法，就是通过其完全限定域名（FQDN）访问外部服务

创建ExternalName类型的服务

要创建一个具有别名的外部服务的服务时，要将创建服务资源的一个type字段设置为ExternalName。例如，设想一下在http://api.somecompany.com上有公共可用的API，可以定义一个指向它的服务，如下面的代码清单所示。

代码清单5.10 ExternalName类型的服务：external-service-externalname.yaml\

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  type: ExternalName
  externalName: www.baidu.com  #实际服务的域名
  ports:
  - port: 80

服务创建完成后，pod可以通过 external-service.default.svc.cluster.local 域名（甚至是 external-service ）连接到外部服务，而不是使用服务的实际FQDN。这隐藏了实际的服务名称及其使用该服务的pod的位置，允许修改服务定义，并且在以后如果将其指向不同的服务，只需简单地修改externalName属性，或者将类型重新变回ClusterIP并为服务创建Endpoint——无论是手动创建，还是对服务上指定标签选择器使其自动创建。

ExternalName 服务仅在DNS级别实施——为服务创建了简单的CNAME DNS记录。因此，连接到服务的客户端将直接连接到外部服务，完全绕过服务代理。

出于这个原因，这些类型的服务甚至不会获得集群IP。

注意 CNAME记录指向完全限定的域名而不是数字IP地址。