k8s教程（service篇）-概念和原理（下）

10.1 端点分片

kubernetes从1.19版本开始，EndpointSplice机制以及EndpointSliceProxying是默认开启的：

通过设置kube-apiserver和kube-proxy服务的启动参数--feature-gates=“EndpointSlice=true“进行启用。kube-proxy默认仍然使用Endpoint对象，为了提高性能，可以设置 kube-proxy启动参数--feature-gates-=“EndpointSliceProxying=true“让kube-proxy 使用EndpointSlice，这样可以减少kube-proxy与master之间的网络通信并提高性能。

以一个3副本的webapp服务为例，Pod列表如下：

服务和Endpoint的信息如下：

查看EndpointSlice，可以看到系统自动创建了一个名称前缀为“webapp-”的EndpointSlice：

查看其详情信息，可以看到3个Endpoint的IP地址和端口信息，同时为Endpoint设置了Topology相关信息：

10.1.1 参数

默认情况下，在由EndpointSlice控制器创建的EndpointSlice中最多包含100个Endpoint，如需修改，则可以通过kube-controller-manager服务的启动参数-- max-endpoints-per-slice设置，但上限不能超过1000。

EndpointSlice的关键信息如下：

10.1.2 复制功能

EndpointSlice复制（Mirroring）功能：应用程序有时可能会创建自定义的Endpoint资源，为了避免应用程序在创建Endpoint资源时再去创建EndpointSlice资源，Kubernetes控制平面会 自动完成 将Endpoint资源复制为EndpointSlice资源的操作。

以下几种情况下,不会执行自动复制操作：

• Endpoint资源设置了Label：endpointslice.kubernetes.io/skip-mirror=true；
• Endpoint资源设置了Annotation：control-plane.alpha.kubernetes.io/leader；
• Endpoint资源对应的Service资源不存在；
• Endpoint：资源对应的Service资源设置了非空的Selector；

一个Endpoint资源同时存在IPv4和IPv6地址类型时，会被复制为多个EndpointSlice资源，每种地址类型最多会被复制为1000个EndpointSlice资源。

10.1.3 数据分布管理机制

如上例所示，我们可以看到每个EndpointSlice资源都包含一组作用于全部Endpoint的端口号(Ports)。如果Service定义中的端口号使用了字符串名称，则对于相同name的端口号，目标Pod 的targetPort可能是不同的，结果是EndpointSlice资源将会不同。这与Endpoint 资源设置子集（subset)的逻辑是相同的。

Kubernetes控制平面对于EndpointSlice中数据的管理机制是尽可能填满，但不会在多个EndpointSlice数据不均衡衡的情况下主动执行重新平衡(rebalance)操作，其背后的逻辑也很简单，步骤如下：

1. 遍历当前所有EndpointSlice资源，删除其中不再需要的Endpoint，更新已更改的匹配Endpoint；
2. 遍历第1步中已更新的EndpointSlice资源，将需要添加的新Endpoint填充进去；
3. 如果还有新的待添加Endpoint，则尝试将其放入之前未更新的EndpointSlice中，或者尝试创建新的EndpointSlicez并添加。

重要的是，第3步优先考虑创建新的EndpointSlice而不是更新原EndpointSlice。例如，如果要添加l0个新的Endpoint，则当前有两个EndpointSlice各有5个剩余空间可用于填充，系统也会创建一个新的EndpointSlice用来填充这10个新Endpoint。换句话说，单个EndpointSlice的创建优于对多个EndpointSlice的更新。

以上主要是由于在每个节点上运行的kube-proxy都会持续监控EndpointSlice的变化，对EndpointSlice每次更新成本都很高，因为每次更新都需要Master将更新数据发送到每个kube-proxy。

上述管理机制旨在限制需要发送到每个节点的更新数据量，即使可能导致最终有许多EndpointSlice资源未能填满。实际上，这种不太理想的数据分布情况应该是罕见的。

Master的EndpointSlice控制器处理的大多数更新所带来的数据量都足够小，使得对已存在 (仍有空余空间）EndpointSlice的数据填充都没有问题，如果实在无法填充，则无论如何都需要创建新的EndpointSlice资源。

此外，对Deployment执行滚动升级操作时，由于后端Pod列表和相关Endpoint列表全部会发生变化，所以也会很自然地对EndpointSlice资源的内容全部进行更新。

10.2 服务拓扑

在默认情况下，发送到一个Service的流量会被均匀转发到每个后端Endpoint，但无法根据更复杂的拓扑信息设置复杂的路由策略。服务拓扑机制的引入就是为了实现基于Node拓扑的服务路由，允许Service创建者根据来源Node和目标Node的标签来定义流量路由策略。

通过对来源Node和目标Node标签的匹配，用户可以根据业务需求对Node进行分组，设置有意义的指标值来标识 “较近” 或者 “较远” 的属性：

例如：对于公有云环境来说，通常有区域（Zone或Region)的划分，云平台倾向于把服务流量限制在同一个区域内，这通常是因为跨区域网络流量会收取额外的费用。另一个例子是把流量路由到由DaemonSet管理的当前Node的Pod 上。又如希望把流量保持在相同机架内的Node上，以获得更低的网络延时。

10.2.1 配置

服务拓扑机制需要通过设置kube-apiserver和kube-proxy服务的启动参数--feature-gates-=“ServiceTopology=true，EndpointSlice=true“进行启用（需要同时启用EndpointSlice功能)，然后就可以在Service资源对象上通过定义 topologyKeys字段来控制到Service的流量路由了。

对于需要使用服务拓扑机制的集群,管理员需要为Node设置相应的拓扑标签，包括kubernetes.io/hostname、topology.kubernetes.io/zone 和topology.kubernetes.io/region。

然后为Service设置topologyKeys的值，就可以实现如下流量路由策略：

• 配置为[“kubernetes.io/hostname“]：流量只会被路由到相同Node的
  Endpoint上，如果Node的Endpoint不存在，则将请求丢弃。
• 配置为[“kubernetes.io/hostname" "topology.kubernetes.io/zone“ “topology.kubernetes.io/region“]：流量优先被路由到相同Node的Endpoint上， 如果Node没有Endpoint，流量则被路由到同zone的Endpoint，如果在zone中没有Endpoint，流量则被路由到通region中的Endpoint上。
• 配置为[“topology.kubernetes.io/zone“，“*“]：流量优先被路由到同zone 的Endpoint上，如果在zone中没有可用的Endpoint，流量则被路由到任意可用的
  Endpoint上。

目前使用服务拓扑有以下几个约束条件：

• 服务拓扑和externalTrafficPolicy=Local是不兼容的，所以一个Service不能同时使用这两种特性。在同一个Kubernetes集群中，启用服务拓扑的Service和设置externalTrafficPolicy=Local特性的Service：是可以同时存在的。
• topologyKeys目前可以设置的标签只有3个：kubernetes.io/hostname、topology.kubernetes.io/zone和topology.kubernetes.io/region，未来会增加更多 的标签。
• topologyKeys必须是有效的标签格式，并且最多定义16个。
• 如需使用通配符“*”，则它必须是最后一个值。

10.2.2 举例

下面通过Service的YAML文件对几种常见的服务拓扑应用实例进行说明。

① 只将流量路由到相同Node的Endpoint上，如果Node没有可用的Endpoint，则将请求丢弃：

apiVersion: v1
kind: Service
metadata:
 name: webapp
spec:
  selector:
    app: webapp
  ports:
  - port: 8080
  topologykeys:
  - "kubernetes.io/hostname"

② 优先将流量路由到相同Node的Endpoint上，如果Node没有可用的Endpoint，则将请求路由到任意可用的Endpoint：

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  selector:
    app: webapp
  ports:
  - port:8080
  topologyKeys:
  - "kubernetes.io/hostname"
  - "*"

③ 只将流量路由到相同zone或同region的Endpoint上，如果没有可用的Endpoint，则将请求丢弃：

apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  selector:
    app: webapp
  ports:
  - port:8080
  topologyKeys:
  - "topology.kubernetes.io/zone" 
  - "topology.kubernetes.io/region"

④ 按同Node、同zone、同region的优先级顺序路由流量，如果Node、 zone、region都没有可用的Endpoint，则将请求路由到集群内任意可用的Endpoint.上:

apiVersion: v1
kind: Service
metadata: 
  name: webapp
spec:
  selector:
  app: webapp
  ports:
  - port:8080
  topologyKeys:
  - "kubernetes.io/hostname"
  - "topology.kubernetes.io/zone" 
  - "topology.kubernetes.io/region"
  - "*"