Kubernetes--LoadBalancer类型的Service资源和ExternalName Service

LoadBalancer类型的Service资源

NodePort类型的Service资源虽然能够于集群外部访问得到，但外部客户端必须得事先得知NodePort和集群中至少一个节点的IP地址，且选定的节点发生故障时，客户端还得自行选择请求访问其他的节点。另外，集群节点很可能是某IaaS云环境中使用私有IP地址的VM，或者是IDC中使用的私有地址的物理机，这类地址对互联网客户端不可达，因此，一般还应该在集群之外创建一个具有公网IP地址的负载均衡器，由它接入外部客户端的请求并调度至集群节点相应的NodePort之上。

IaaS云计算环境通常提供了LBaaS（Load Balancer as a Service）服务，它允许租户动态地在自己的网络中创建一个负载均衡设备。那些部署于此类环境之上的Kubernetes集群在创建Service资源时可以直接调用此接口按需创建出一个软负载均衡器，而具有这种功能的Service资源即为LoadBalancer类型。不过，如果Kubernetes部署于裸的服务器之上，系统管理员也可以自行手动部署一个负载均衡器（推荐使用冗余配置），并配置其将请求流量调度至各个节点的NodePort之上即可。

• 下面是一个LoadBalancer类型的Service资源配置清单，若Kubernetes系统满足其使用条件，即可自行进行应用测试。需要注意的是，有些环境中可能还需要为Service资源的配置定义添加Annotations，必要时请自行参考Kubernetes文档中的说明~:

kind: Service
apiVersion: v1
metadata:
  name: myapp-svc-lb
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 32224

进一步地，在IaaS环境支持手动指定IP地址时，用户还可以使用.spec.loadBalancerIP指定创建的负载均衡器使用的IP地址，并可使用.spec.loadBalancerSourcwRanges指定负载均衡器允许的客户端来源的地址范围。

ExternalName Service

ExternalName类型的Service资源用于将集群外部的服务发布到集群中以供Pod中的应用程序访问，因此，它不需要使用标签选择器关联任何的Pod对象，但必须要使用spec.externalName属性定义一个CNAME记录用于返回外部真正提供服务的主机的别名，而后通过CNAME记录值获取到相关主机的IP地址。

下面是一个ExternalName类型的Service资源示例，名为external-redis-svc，相应的externalName为“redis.ilinux.io”：

kind: Service
apiVersion: v1
metadata:
  name: external-redis-svc
spec:
  type: ExternalName
  externalName: redis.ilinux.io
  ports:
  - protocol: TCP
    port: 6379
    targetPort: 6379
    nodePort: 0
  selector: {}

待Service资源external-redis-svc创建完成后，各Pod对象即可通过external-redis-svc或其FQDN格式的名称external-redis-svc.default.svc.cluster.local访问相应的服务。ClusterDNS会将此名称以CNAME格式解析为.spec.externalNAME字段中的名称，而后通过DNS服务将其解析为相应的主机的IP地址。例如，通过此前创建的交互Pod资源客户端进行服务名称解析：

]$ nslookup external-redis-svc
Server:        223.5.5.5
Address:    223.5.5.5#53

 

由于ExternalNAME类型的Service资源实现于DNS级别，客户端将直接接入外部的服务而完全不需要服务代理，因此，它也无须配置ClusterIP，此种类型的服务也成为Headless Service。