Service 拓扑

FEATURE STATE: Kubernetes v1.17 [alpha]

Service 拓扑可以让一个服务基于集群的 Node 拓扑进行流量路由。例如,一个服务可以指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。

介绍

默认情况下,发往 ClusterIP 或者 NodePort 服务的流量可能会被路由到任意一个服务后端的地址上。从 Kubernetes 1.7 开始,可以将“外部”流量路由到节点上运行的 pod 上,但不支持 ClusterIP 服务,更复杂的拓扑 — 比如分区路由 — 也还不支持。通过允许 Service 创建者根据源 Node 和目的 Node 的标签来定义流量路由策略,Service 拓扑特性实现了服务流量的路由。

通过对源 Node 和目的 Node 标签的匹配,运营者可以使用任何符合运营者要求的度量值来指定彼此“较近”和“较远”的节点组。例如,对于在公有云上的运营者来说,更偏向于把流量控制在同一区域内,因为区域间的流量是有费用成本的,而区域内的流量没有。其它常用需求还包括把流量路由到由 DaemonSet 管理的本地 Pod 上,或者把保持流量在连接同一机架交换机的 Node 上,以获得低延时。

前提条件

为了启用拓扑感知服务路由功能,必须要满足以下一些前提条件:

  • Kubernetes 的版本不低于 1.17
  • Kube-proxy 运行在 iptables 模式或者 IPVS 模式
  • 启用 端点切片功能

启用 Service 拓扑

要启用 Service 拓扑,就要给 kube-apiserver 和 kube-proxy 启用 ServiceTopology 功能:

--feature-gates="ServiceTopology=true"

使用 Service 拓扑

如果集群启用了 Service 拓扑功能后,就可以在 Service 配置中指定 topologyKeys 字段,从而控制 Service 的流量路由。此字段是 Node 标签的优先顺序字段,将用于在访问这个 Service 时对端点进行排序。流量会被定向到第一个标签值和源 Node 标签值相匹配的 Node。如果这个 Service 没有匹配的后端 Node,那么第二个标签会被使用做匹配,以此类推,直到没有标签。

如果没有匹配到,流量会被拒绝,就如同这个 Service 根本没有后端。这是根据有可用后端的第一个拓扑键来选择端点的。如果这个字段被配置了而没有后端可以匹配客户端拓扑,那么这个 Service 对那个客户端是没有后端的,链接应该是失败的。这个字段配置为 "*" 意味着任意拓扑。这个通配符值如果使用了,那么只有作为配置值列表中的最后一个才有用。

如果 topologyKeys 没有指定或者为空,就没有启用这个拓扑功能。

一个集群中,其 Node 的标签被打为其主机名,区域名和地区名。那么就可以设置 ServicetopologyKeys 的值,像下面的做法一样定向流量了。

  • 只定向到同一个 Node 上的端点,Node 上没有端点存在时就失败:配置 ["kubernetes.io/hostname"]
  • 偏向定向到同一个 Node 上的端点,回退同一区域的端点上,然后是同一地区,其它情况下就失败:配置 ["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]。这或许很有用,例如,数据局部性很重要的情况下。
  • 偏向于同一区域,但如果此区域中没有可用的终结点,则回退到任何可用的终结点:配置 ["topology.kubernetes.io/zone", "*"]

约束条件

  • Service 拓扑和 externalTrafficPolicy=Local 是不兼容的,所以 Service 不能同时使用这两种特性。但是在同一个集群的不同 Service 上是可以分别使用这两种特性的,只要不在同一个 Service 上就可以。

  • 有效的拓扑键目前只有:kubernetes.io/hostnametopology.kubernetes.io/zonetopology.kubernetes.io/region,但是未来会推广到其它的 Node 标签。

  • 拓扑键必须是有效的标签,并且最多指定16个。

  • 通配符:"*",如果要用,那必须是拓扑键值的最后一个值。

接下来

最后修改 June 01, 2020 at 9:23 AM PST: add zh pages (4b35d4d40)