基于 Kubernetes 1.22 版本

一、基础概念

  Service 是 Kubemetes 最核心的概念，它定义了一组逻辑 Pod 和访问它们的策略（有时这种模式称为微服务）。即通过创建 Service ，可以为一组相同功能的 Pod 提供一个统一的入口地址，井且将请求负载均衡分发到后端的各个 Pod 上。Service 所管理的 Pod 集通常由 Label Selector 确定。
  运行在每个 Node 上的 kube-proxy 进程其实就是一个智能的软件负载均衡器，它负责把对 Service 的请求转发到后端的某个 Pod 上，井在内部实现服务的负载均衡与会话保持机制。每个 Service 会分配到一个全局唯一的虚拟 IP 地址，这个虚拟 IP 被称为 Cluster IP，这个虚拟 IP 在 Service 的整个生命周期内，它是不会发生改变的。
  要知道 Pod 的 Endpoint 地址随着其销毁和重建而发生改变，像使用 Deployment 来运行应用程序，它可以动态地创建和销毁 Pod。那么这样前端如何去找到后端呢，此时我们的 Servcie 就派上用场了，它通过 Label Selector 去对接后端 Pod，前端只需访问 Servcie 定义的服务入口地址即可。
  官方文档：https://kubernetes.io/docs/concepts/services-networking/service/
 

二、代理模式

  我们知道，Kubernetes 集群中的每个节点都运行一个 kube-proxy 进程，kube-proxy 负责为除 ExternalName 类型以外的 Service 实现虚拟 IP。
  在 Kubernetes 中，kube-proxy 有三种代理模式，分别是 Userspace、Iptables 和 Ipvs。官方推荐使用 Ipvs，不过当集群不支持 Ipvs 的时候，集群会自动使用 Iptables。
 

1、Userspace

  在这种模式下，kube-proxy 监控着 Service 和 Endpoint。对于每个 Service，它在本地节点上打开一个端口（随机选择），任何到此代理端口的连接都将代理到 Service 的一个后端 Pod。kube-proxy 在决定使用哪个后端 Pod 时会考虑 Service 的 SessionAffinity 设置。
  最后，Userspace 代理模式会创建 iptables 规则，用于捕获到服务的 ClusterIP 和端口的流量，规则将该流量重定向到代理后端 Pod 的代理端口。
  默认情况下，Userspace 代理模式下的 kube-proxy 通过轮询算法选择后端。

  例如，当创建 Service 时，Kubernetes 会分配一个虚拟 IP 地址（ClusterIP），例如 10.0.0.1。假设 Service 端口为 1234，集群中的所有 kube-proxy 实例都会观察到该 Service，当它看到一个新 Service 时，它会打开一个新的随机端口，建立一个从虚拟 IP 地址到这个新端口的 iptables 重定向，并开始接受该端口上的连接。当客户端连接到 Service 的虚拟 IP 地址时，iptables 规则生效，并将数据包重定向到代理自己的端口。然还代理将选择后端，并开始将流量从客户端代理到后端。
 

2、Iptables

  在这种模式下，kube-proxy 监控着 Service 和 Endpoint。对于每个 Service，它都创建 iptables 规则，这些规则捕获到 Service 的 ClusterIP 和端口的流量，并将该流量重定向到 Service 的一个后端集。对于每个端点对象，它创建 iptables 规则，这些规则会选择一个后端 Pod。
  默认情况下，iptables 代理模式下的 kube-proxy 随机选择后端。
  使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，无需在用户空间和内核空间之间切换，这种方法也更加可靠。
  如果 kube-proxy 在 iptables 代理模式下运行，并且选择的第一个 Pod 没有响应，则连接失败。这与 Userspace 代理模式不同的是：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接失败，并将自动使用不同的后端 Pod 重试。
  我们也可以使用 Pod 就绪探测来验证后端 Pod 是否正常工作，这样在 iptables 代理模式下的 kube-proxy 只会看到测试正常的后端。这样做意味着可以避免通过 kube-proxy 将流量发送到已知失败的 Pod。

 

3、Ipvs

  在这种模式下，kube-proxy 监控着 Service 和 Endpoint，调用 netlink 接口创建相应的 ipvs 规则，并定期将 ipvs 规则与 Service 和 Endpoint 同步。该控制循环可确保 ipvs 状态与所需状态匹配。访问 Service 时，ipvs 将流量定向到后端 Pod 之一。
  Ipvs 代理模式基于 netfilter hook 函数，该函数类似于 iptables 模式，但使用哈希表作为底层数据结构，并在内核空间中工作。这意味着 ipvs 模式下的 kube-proxy 重定向流量的延迟比iptables 模式下的kube-proxy 低，在同步代理规则时具有更好的性能。与其他代理模式相比，ipvs 模式还支持更高的网络流量吞吐量。像 iptables 在大规模集群（例如10000个服务）中的运行速度显著降低。
  Ipvs 为平衡后端 POD 的流量提供了更多选项，几种调度算法如下：

• rr：轮询，即依次循环分配流量。
• lc：最少打开连接数，即优先分配流量给打开连接数最少的后端。
• dh：目标哈希，即流量按照目标 IP 的 hash 结果分配。
• sh：源哈希，即流量按照源 IP 的 hash 结果分配，这样会使得来自同一 IP 的客户端固定访问一个后端。
• sed：最短的预期延迟，即响应时间越短的后端优先分配流量
• nq：从不排队，即当后端有空闲时，先调度到空闲的上，否则依据 sed 算法调度。

  要在 IPVS 模式下运行 kube-proxy，必须在启动 kube-proxy 之前保证节点上的 IPVS 可用。当 kube-proxy 在 IPVS 代理模式下启动时，它会验证 IPVS 内核模块是否可用。如果未检测到 IPVS 内核模块，则 kube-proxy 将回退到以 iptables 代理模式运行。

  以上不论哪种模式，kube-proxy 都监控着 kube-apiserver 写入 etcd 中关于 Pod 的最新状态信息，它一旦检查到那个 Pod 资源添加或者删除，它会立即将这些变化同步到 iptables 或 ipvs 规则中，以便 iptables 和 ipvs 在调度客户端请求到后端 Pod 时，不会出现 Pod 不存在的情况。
 

三、定义详解

Service 定义官方文档：https://kubernetes.io/docs/reference/kubernetes-api/service-resources/
yaml 格式的 Service 定义文件常用内容如下：

apiVersion: v1          # 必选，API版本号
kind: Service           # 必选，类型为Service
metadata:               # 必选，元数据
  name: string          # 必选，Service名称
  namespace: string     # 命名空间，默认为default
  labels:               # 标签列表
    name: string
  annotations:          # 注释列表
    name: string
spec:                   # 必选，定义Service的行为
  selector:             # 标签选择器，选择具有指定标签的Pod进行管理
    name: string
  type: string          # Service的类型，用于指定Service的访问方式，默认为CusterIP
  ports:                # 必选，定义Servcie端口相关信息
  - name: string        # 端口名称
    port: int           # 必选，端口，Service将公开的端口
    targetPort: int     # 目标端口，目标Pod的容器暴露端口，默认和port相同。
    protocol: string    # 端口协议，支持TCP、UDP和SCTP，默认为TCP
    nodePort: int       # 当type为NodePort或LoadBalancer时，Servic在宿主机节点上公开的端口，不指定随机分配
  clusterIP: string     # Service的IP地址，默认随机分配
  sessionAffinity: string   # Session亲和，即基于客户端IP地址进行会话保持的模式，可选值为ClientIP和None（默认）
                            # ClientIP表示将同一个客户端（IP）的访问请求都转发到同一个后端Pod上

Service 的类型（spec.type）：

• ClusterIP：在集群内部 IP 上公开此 Service，此类型服务只能从集群内部访问，这是默认的 Service 类型。
• NodePort：在宿主机节点 IP 的端口上公开此 Service，此类型将能够通过 NodePort 从集群外部访问服 Service。
• LoadBalancer：使用外部负载均衡器对外公开 Service，用于公有云环境。
• ExternalName：通过返回 CNAME 记录及其值，将 Service 映射到 externalName 字段的内容。

除了文件定义，我们还可以使用命令快速创建 Service：

[root@master ~]# kubectl expose deployment nginx-deployment --port=80 --type=NodePort
service/nginx-deployment exposed
[root@master ~]# kubectl get svc
NAME               TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
nginx-deployment   NodePort    10.1.82.56    <none>        80:32080/TCP   11s

[root@master ~]# curl -s localhost:32080 | head -n4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

 

四、基本使用

1、ClusterIP

  下面是一个简单的示例，创建了一个 Deployment，并定义了一个名为 "nginx-service" 的 Service ，它的服务端口为80 ，将对接拥有 "app: nginx" 这个 label 的所有 Pod。

[root@master ~]# vim nginx-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18.0
        ports:
        - containerPort: 80

[root@master ~]# vim nginx-service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80  
    protocol: TCP 

  我们来简单解读 Service 的定义文件 nginx-service.yaml：spec.selector 定义选择具有指定标签的 Pod 进行管理；在 spec.ports 的定义中， port 定义了 Service 的端口，targetPort 则定义了该服务的容器所暴露（EXPOSE）的端口，如果没有指定 targetPort，则默认 targetPort 和 port 相同。

[root@master ~]# kubectl apply -f nginx-deployment.yaml,nginx-service.yaml 
deployment.apps/nginx-deployment created
service/nginx-service created

[root@master ~]# kubectl get endpoints
NAME            ENDPOINTS                                         AGE
kubernetes      10.0.0.100:6443                                   23d
nginx-service   10.244.2.120:80,10.244.2.121:80,10.244.2.122:80   12s

[root@master ~]# kubectl get svc
NAME            TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.1.0.1      <none>        443/TCP   23d
nginx-service   ClusterIP   10.1.10.223   <none>        80/TCP    18s

[root@master ~]# curl -s 10.1.10.223 | head -n4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

 

2、NodePort

现在将 nginx-service 改为 NodePort 模式，以使得能从集群外部访问：

# 将spec.type改为NodePort
[root@master ~]# kubectl edit service nginx-service 
service/nginx-service edited

[root@master ~]# kubectl get svc nginx-service 
NAME            TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
nginx-service   NodePort   10.1.10.223   <none>        80:30577/TCP   68m

[root@master ~]# curl -s localhost:30577 | head -n4
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

 

3、多端口

  对于某些服务，是需要公开多个端口。Kubernetes 允许给 Service 定义多个端口。为一个 Service 使用多个端口时，必须配置所有端口的名称，例如：

[root@master ~]# cat nginx-service-port.yaml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-service-port
spec:
  selector:
    app: nginx
  ports:
  - name: http
    protocol: TCP
    port: 80
  - name: https
    protocol: TCP
    port: 443

[root@master ~]# kubectl apply -f nginx-service-port.yaml 
service/nginx-service-port created

[root@master ~]# kubectl get svc nginx-service-port 
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)          AGE
nginx-service-port   ClusterIP   10.1.92.51   <none>        80/TCP,443/TCP   6s

 

五、外部服务

  Service 最常见的用法是抽象对 Pod 的访问，但它们也可以抽象其它类型的后端，即定义一个没有选择器的服务。
  例如以下场景：

• 将外部数据库作为后端服务进行连接。
• 将另一个集群或 Namespace 中的服务作为服务的后端。

例如下例，10.0.0.100 上有一个 web 服务，我们创建一个Service指向它。

[root@master ~]# curl -s 10.0.0.100 | head -n4
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Welcome to CentOS</title>

[root@master ~]# vim ext-service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: ext-service
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80

[root@master ~]# kubectl apply -f ext-service.yaml 
service/ext-service created

[root@master ~]# kubectl get svc ext-service 
NAME          TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
ext-service   ClusterIP   10.1.179.200   <none>        80/TCP    8s

[root@master ~]# kubectl describe svc ext-service | grep -i endpoint
Endpoints:         <none>

  由于此 Service 没有选择器，无法选择后端 Pod，因此是不会自动创建相应的 Endpoint 记录的。因此需要手动创建一个和该 Service 同名的 Endpoint ，用于指向实际的后端访问地址。

[root@master ~]# vim ext-service-endpoint.yaml 
apiVersion: v1
kind: Endpoints
metadata:
  name: ext-service
subsets:
- addresses:
  - ip: 10.0.0.100
  ports:
  - port: 80

[root@master ~]# kubectl apply -f ext-service-endpoint.yaml
endpoints/ext-service created

[root@master ~]# kubectl get endpoints ext-service 
NAME          ENDPOINTS       AGE
ext-service   10.0.0.100:80   34s

[root@master ~]# kubectl describe svc ext-service | grep -i endpoint
Endpoints:         10.0.0.100:80

[root@master ~]# curl -s 10.1.179.200 | head -n4
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title>Welcome to CentOS</title>

  注：端点地址不能是环回（127.0.0.0/8）、私有保留地址（169.254.0.0/16 ）、组播地址（224.0.0.0/24）和其它 Kubernetes 服务的集群IP。
 

六、Headless Service

 Headless Service（无头服务），即不为 Service 设置 ClusterIP 入口地址 ，仅通 Label Selector 将后端的 Pod 列表返回给调用的客户端。对于 headless Services，kube-proxy 是不处理这些服务，也不会为它们做负载均衡或代理。
 例如以下场景：

• 不使用 Service 提供的默认负载均衡的功能，想自己控制负载均衡策略
• 不通过 Service 转发，想直接访问 Pod 等场景。
•  配合其它服务发现，而不受 Kubernetes 中实现的束缚。

对于 Headless Services，DNS 的自动配置方式取决于 Service 是否定义了选择器：

•  有选择器：对于定义选择器的 Headless Service，端点控制器在 API 中创建 Endpoints 记录，并修改 DNS 配置以返回直接指向支持 Service 的 POD 的记录（IP地址）。
•  无选择器：对于未定义选择器的 Headless Service，端点控制器不会创建 Endpoints 记录。但是，DNS 系统会查找并配置 ExternalName 类型服务的 CNAME 记录和A记录与服务共享名称的所有其他类型的端点。

例如，下面示例：

[root@master ~]# vim nginx-svc-headless.yaml
apiVersion: v1 
kind: Service 
metadata: 
  name: nginx-svc-headless
  labels: 
    app: nginx
spec:
  selector:
    app: nginx
  ports:
  - port: 80
  clusterIP: None

[root@master ~]# kubectl apply -f nginx-svc-headless.yaml 
service/nginx-svc-headless created

[root@master ~]# kubectl get svc nginx-svc-headless 
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
nginx-svc-headless   ClusterIP   None         <none>        80/TCP    16s

[root@master ~]# kubectl describe service nginx-svc-headless | grep Endpoints
Endpoints:         10.244.2.120:80,10.244.2.121:80,10.244.2.122:80

# Service DNS 命名一般是为：<服务名>.<命名空间>.svc.cluster.local
# 下面通过 DNS 查询一下
[root@master ~]# kubectl run test -it --rm --image=busybox
If you don't see a command prompt, try pressing enter.
/ # nslookup nginx-svc-haeadless.default.svc.cluster.local
Server:     10.1.0.10
Address:    10.1.0.10:53

Name:   nginx-svc-haeadless.default.svc.cluster.local
Address: 10.244.2.121
Name:   nginx-svc-haeadless.default.svc.cluster.local
Address: 10.244.2.122
Name:   nginx-svc-haeadless.default.svc.cluster.local
Address: 10.244.2.120

  这样 Service 就不再具有一个特定 ClusterIP，当客户端对其进行访问将获得包含 Label "app=nginx" 的全部 Pod 。
  像 StatefulSet 就是使用 Headless Service 来指定具体的 pod。

 
参考文章：

https://kubernetes.io/docs/
《Kubernetes 权威指南》