服务概述

Pod创建完成后，如果直接访问Pod会存在如下几个问题：

• Pod会随时被Deployment这样的控制器删除重建，那访问Pod的结果就会变得不可预知。
• Pod的IP地址是在Pod启动后才被分配，在启动前并不知道Pod的IP地址。
• 应用往往都是由多个运行相同镜像的一组Pod组成，逐个访问Pod也变得不现实。

举个例子，假设有这样一个应用程序，使用Deployment创建了前台和后台，前台会调用后台做一些计算处理，如图1所示。后台运行了3个Pod，这些Pod是相互独立且可被替换的，当Pod出现状况被重建时，新建的Pod的IP地址是新IP，前台的Pod无法直接感知。

图1 Pod间访问

为了解决上述问题，Kubernetes引入了Service对象，为Pod提供了一个稳定的网络接口和持久的IP地址（在创建CCE集群时通过“服务网段”进行设置，该网段专门用于给Service分配IP地址）。Service通过标签选择器来识别一组目标Pod，并使用负载均衡机制在这些Pod之间均匀分配流量。这不仅有效解决了直接访问Pod时存在的问题，还保障了应用的高可用性和运行效率。

对于上面的例子，如果为后台添加一个Service，并通过Service来访问Pod，这样前台Pod就无需感知后台Pod的变化，如图2所示。

图2 通过Service访问Pod

在Kubernetes中，Endpoint和EndpointSlice都是用于管理服务后端Pod网络端点的资源对象。

• Endpoint：Endpoint是Kubernetes中用于服务发现的传统资源对象，用于表示一个Service对应的所有Pod的网络端点集合。每个带选择器（selector）的Service都会自动创建一个对应的Endpoint资源，记录匹配该选择器的所有Pod的IP地址和端口。当Pod被删除或重建导致IP地址变化时，Endpoint会自动更新存储的Pod IP地址和端口信息，确保Service能够将流量定向到最新的Pod。

  Endpoint的主要特点如下：

  • 一个Service对应一个Endpoint资源。
  • 包含该Service所有后端Pod的IP地址和端口信息。
  • 当任何Pod发生变化时，整个Endpoint对象需要重新计算和存储。
  • 默认情况下，Endpoint资源最多包含1000个端点，超过部分会被截断。
• EndpointSlice：EndpointSlice是Kubernetes v1.16引入的alpha特性，在v1.21后稳定，是旧版Endpoints API的替代方案，旨在解决Endpoint在大规模集群中的性能问题。它通过分片（sharding）的方式管理端点：
  • 一个Service对应多个EndpointSlice
  • 每个EndpointSlice默认包含不超过100个端点，超过时Kubernetes就会创建一个新的EndpointSlice
  • 端点按协议、端口和服务名称分组
  • 支持IPv4、IPv6和FQDN（完全限定域名）三种地址类型

Endpoint与EndpointSlice的主要差异如下：

kube-proxy是Kubernetes集群的关键组件，负责Service和其后端容器Pod之间进行负载均衡转发。CCE支持iptables和IPVS两种服务转发模式：

• iptables：iptables是一个Linux内核功能，提供了大量的数据包处理和过滤方面的能力。它可以在核心数据包处理管线上用Hook挂接一系列的规则。iptables模式中kube-proxy 在NAT pre-routing Hook中实现NAT和负载均衡功能。对于每个Service，kube-proxy都会添加一个iptables规则，这些规则捕获流向Service的ClusterIP和Port的流量，并将这些流量重定向到Service后端的其中之一。默认情况下，iptables模式下的kube-proxy会随机选择一个Service后端。详情请参见iptables代理模式。
• IPVS：IPVS（IP Virtual Server）是在Netfilter上层构建的，并作为Linux内核的一部分，实现传输层负载均衡。IPVS可以将基于TCP和UDP服务的请求定向到真实服务器，并使真实服务器的服务在单个IP地址上显示为虚拟服务。

  IPVS模式下，kube-proxy使用IPVS负载均衡代替了iptables。这种模式同样有效，IPVS的设计就是用来为大量服务进行负载均衡的，它有一套优化过的API，使用优化的查找算法，而不是简单的从列表中查找规则。详情请参见IPVS代理模式。

更多关于两种服务转发模式的对比请参见iptables与IPVS如何选择。

NodePort类型及LoadBalancer类型的Service接收请求时，会先访问到节点，然后转到Service，再由Service选择一个Pod转发到该Pod，但Service选择的Pod不一定在接收请求的节点上。默认情况下，从任意节点IP+服务端口都能访问到后端工作负载，当Pod不在接收请求的节点上时，请求会再跳转到Pod所在的节点，带来一定性能损失。

• 通过YAML配置：Service有一个配置参数（externalTrafficPolicy），用于设置Service是否希望将外部流量路由到节点本地或集群范围的端点，示例如下：

  apiVersion: v1
  kind: Service
  metadata:
    name: nginx-nodeport
  spec:
    externalTrafficPolicy: Local # 服务亲和配置
    ports:
    - name: service
      nodePort: 30000
      port: 80
      protocol: TCP
      targetPort: 80
    selector:
      app: nginx
    type: NodePort

  • 当externalTrafficPolicy取值为Local时，通过节点IP:服务端口的请求只会转发给本节点上的Pod，如果节点没有Pod的话请求会挂起。
  • 当externalTrafficPolicy取值为Cluster时，请求会在集群内转发，从任意节点IP+服务端口都能访问到后端工作负载。
  • 如不设置externalTrafficPolicy，默认取值为Cluster。

总结服务亲和（externalTrafficPolicy）的两个选项对比如下：