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

abstract.png

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

楔子

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

# 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只需通过访问该服务，即可实现对集群外运行的后端的访问

# 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

# 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

# 创建 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