华为云在K8S大规模场景下的Service性能优化实践

讲师&＃xff1a;王泽锋 / 华为云 Kubernetes 开源负责人
编辑&＃xff1a;夏天

Kubernetes 原生的 Service 负载均衡基于 Iptables 实现&＃xff0c;其规则链会随 Service 的数量呈线性增长&＃xff0c;在大规模场景下对 Service 性能影响严重。本次分享介绍了华为云在 Kubernetes service 性能优化方面的探索与实践。

大家好&＃xff0c;今天给大家带来我们在 Kubernetes Service 上的一些优化实践&＃xff0c;这是一个网络相关的话题。首先&＃xff0c;我将给大家介绍 Kubernetes 的 Service 机制。现在 Kubernetes 中 Service 的三种模式&＃xff0c;包括原来的 Userspace 和 Iptables&＃xff0c;以及后来我们贡献的 IPVS&＃xff1b;第二部分会介绍原来社区是如何使用 Iptables 来实现 Service 负载平衡的&＃xff1b;第三部分主要是 Iptables 实现中存在的一些问题&＃xff1b;接下来是如何使用 IPVS 来做 Service 的负载实现的&＃xff1b;最后是一个对比。

Kubernetes 的 Service 机制

先看一下 Kubernetes 里面的 Service。在用 Kubernetes 之前&＃xff0c;当我们有了容器网络之后&＃xff0c;访问一个应用最直接的做法&＃xff0c;就是客户端直接去访问一个 Backend Container。这种做法最直观和容易&＃xff0c;同时问题也是显而易见的。当应用有多个后端容器的时候&＃xff0c;怎么做负载均衡&＃xff0c;会话保持怎么做&＃xff0c;某个容器迁了之后 IP 跟着变怎么办&＃xff0c;还有对应的健康检查怎么配&＃xff0c;如果想用域名来做访问入口要怎么处理……这些其实就是 Kubernetes 的 Service 引入所要解决的问题。

Kubernetes Service 与 Endpoints

这张图表现了 Service 与其它几个对象的对应关系。首先是 Service&＃xff0c;它保存的是服务的访问入口信息&＃xff08;如 IP、端口&＃xff09;&＃xff0c;可以简单理解为 Kubernetes 内置的一个 LoadBalancer&＃xff0c;它的作用就是给多个 Pod 提供负载均衡。

图中是一个 Replication Controller 部署出来 2 个 pod 所对应的 Service。我们知道 RC 和 pod 的关系是通过 label-selector 来关联的&＃xff0c;service 也是一样&＃xff0c;通过 Selector 来匹配它所要做负载均衡的 Pod。实际上这中间还有一个对象&＃xff0c;叫做 Endpoint&＃xff0c;为什么要有这个对象呢&＃xff1f;因为在实际应用中&＃xff0c;一个 pod 被创建&＃xff0c;并不代表它马上就能对外提供服务&＃xff0c;而这个 pod 如果将被删除&＃xff0c;或处于其他不良状态&＃xff0c;我们都希望客户端的请求不被分发到这个无法提供服务的 pod 上。Endpoint 的引入&＃xff0c;就是用来映射那些能对外提供服务的 pod。每个 Endpoints 对象的 IP 对应一个 Kubernetes 的内部域名&＃xff0c;可以通过这个域名直接访问到具体的 pod。

再看 Service 和 Endpoint 的定义。这里注意 Service 有一个 ClusterIP 的属性字段&＃xff0c;可以简单理解为是虚 IP。Service 的域名解析通常得到的就是这个 ClusterIP。另外值得注意的是 Service 支持端口映射&＃xff0c;即 Service 暴露的端口不必和容器端口一致。

Service 内部逻辑

刚才介绍了 Service、Pods 跟 Endpoint 三者的关系&＃xff0c;再来看 Service 的内部逻辑。这里主要看下 Endpoint Controller&＃xff0c;它会 watch Service 对象、还有 pod 的变化情况&＃xff0c;维护对应的 Endpoint 信息。然后在每一个节点上&＃xff0c;KubeProxy 根据 Service 和 Endpoint 来维护本地的路由规则。

实际上&＃xff0c;每当一个 Endpoint 发生变化&＃xff08;即 Service 以及它关联的 Pod 状态发生变化&＃xff09;&＃xff0c;Kubeproxy 都会在每个节点上做对应的规则刷新&＃xff0c;所以这个其实更像是一个靠近客户端的负载均衡——一个 Pod 访问其他服务的 Pod 时&＃xff0c;请求在出节点之前&＃xff0c;就已经通过本地的路由规则选好了它的目的 Pod。

Iptables 实现负载均衡

好&＃xff0c;我们来看一下 Iptables 模式是怎么实现的。

Iptables 主要分两部分&＃xff0c;一个是它的命令行工具&＃xff0c;在用户态&＃xff1b;然后它也有内核模块&＃xff0c;但本质上还是通过 Netfilter 这个内核模块来封装实现的&＃xff0c;Iptables 的特点是支持的操作比较多。

这是 IPtables 处理网络包的一个流程图&＃xff0c;可以看到&＃xff0c;每个包进来都会按顺序经过几个点。首先是 PREROUTING&＃xff0c;它会判断接收到的这个请求包&＃xff0c;是访问本地进程还是其他机器的&＃xff0c;如果是访问其他机器的&＃xff0c;就要走 FORWARD 这个 chain&＃xff0c;然后再会做一次 Routing desicion&＃xff0c;确定它要 FORWARD 到哪里&＃xff0c;最后经 POSTROUTING 出去。如果是访问本地&＃xff0c;就会进来到 INPUT 这条线&＃xff0c;找到对应要访问哪个本地请求&＃xff0c;然后就在本地处理了。处理完之后&＃xff0c;其实会生成一个新的数据包&＃xff0c;这个时候又会走 OUTPUT&＃xff0c;然后经 POSTROUTING 出去。

Iptables 实现流量转发与负载均衡

我们知道&＃xff0c;Iptables 做防火墙是专业的&＃xff0c;那么它是如何做流量转发、负载均衡甚至会话保持的呢&＃xff1f;如下图所示&＃xff1a;

Iptables 在 Kubernetes 的应用举例

那么&＃xff0c;在 Kubernetes 里面是怎么用 Iptables 来实现负载均衡呢&＃xff1f;来看一个实际的例子。在 Kubernetes 中&＃xff0c;从VIP到RIP&＃xff0c;中间经过的Iptables链路包括&＃xff1a;PREROUTING/OUTPUT&＃xff08;取决于流量是从本机还是外机过来的&＃xff09;-> KUBE-SERVICES&＃xff08;所有 Kubernetes 自定义链的入口&＃xff09;->KUBE-SVC-XXX&＃xff08;后面那串 hash 值由 Service 的虚 IP 生成&＃xff09;->KUBE-SEP->XXX&＃xff08;后面那串 hash 值由后端 Pod 实际 IP 生成&＃xff09;。

当前 Iptables 实现存在的问题

Iptables 做负载均衡的问题

那么 Iptables 做负载均衡主要有什么缺陷呢&＃xff1f;起初我们只是分析了原理&＃xff0c;后来在大规模场景下实测&＃xff0c;发现问题其实非常明显。

• 首先是时延&＃xff0c;匹配时延和规则更新时延。我们从刚刚的例子就能看出&＃xff0c;每个 Kubernetes Service 的虚 IP 都会在 kube-services 下对应一条链。Iptables 的规则匹配是线性的&＃xff0c;匹配的时间复杂度是 O(N)。规则更新是非增量式的&＃xff0c;哪怕增加/删除一条规则&＃xff0c;也是整体修改 Netfilter 规则表。
• 其次是可扩展性。我们知道当系统中的 Iptables 数量很大时&＃xff0c;更新会非常慢。同时因为全量提交的过程中做了保护&＃xff0c;所以会出现 kernel lock&＃xff0c;这时只能等待。
• 最后是可用性。服务扩容/缩容时&＃xff0c;Iptables 规则的刷新会导致连接断开&＃xff0c;服务不可用。

Iptables 规则匹配时延

上图说明了 Service 访问时延随着规则数的增加而增长。但其实也还能接受&＃xff0c;因为时延最高也就 8000us&＃xff08;8ms&＃xff09;&＃xff0c;这说明真正的性能瓶颈并不在这里。

Iptables 规则更新时延

那么 Iptables 的规则更新&＃xff0c;究竟慢在哪里呢

首先&＃xff0c;Iptables 的规则更新是全量更新&＃xff0c;即使 --no--flush 也不行&＃xff08;--no--flush 只保证 iptables-restore 时不删除旧的规则链&＃xff09;。

再者&＃xff0c;kube-proxy 会周期性的刷新 Iptables 状态&＃xff1a;先 iptables-save 拷贝系统 Iptables 状态&＃xff0c;然后再更新部分规则&＃xff0c;最后再通过 iptables-restore 写入到内核。当规则数到达一定程度时&＃xff0c;这个过程就会变得非常缓慢。

出现如此高时延的原因有很多&＃xff0c;在不同的内核版本下也有一定的差异。另外&＃xff0c;时延还和系统当前内存使用量密切相关。因为 Iptables 会整体更新 Netfilter 的规则表&＃xff0c;而一下子分配较大的内核内存&＃xff08;>128MB&＃xff09;就会出现较大的时延。

Iptables 周期性刷新导致 TPS 抖动

上图就说明了在高并发的 loadrunner 压力测试下&＃xff0c;kube-proxy 周期性刷新 Iptables 导致后端服务连接断开&＃xff0c;TPS 的周期性波动。

K8S Scalability

所以这个就给 Kubernetes 的数据面的性能带来一个非常大的限制&＃xff0c;我们知道社区管理面的规模&＃xff0c;其实在去年就已经支持到了 5000 节点&＃xff0c;而数据面由于缺乏一个权威的定义&＃xff0c;没有给出规格。

我们在多个场景下评估发现 Service 个数其实很容易达到成千上万&＃xff0c;所以优化还是很有必要的。当时先到的优化方案主要有两个&＃xff1a;

• 用树形结构来组织 Iptables 的规则&＃xff0c;让匹配和规则更新过程变成树的操作&＃xff0c;从而优化两个时延。
• 使用 IPVS&＃xff0c;后面会讲它的好处。

使用树形结构组织 Iptables 规则的一个例子如下所示:

在这个例子中&＃xff0c;树根是 16 位地址&＃xff0c;根的两个子节点是 24 位地址&＃xff0c;虚 IP 作为叶子节点&＃xff0c;根据不同的网段&＃xff0c;分别挂在不同的树节点下。这样&＃xff0c;规则匹配的时延就从 O(N) 降低到 O(N 的 M 次方根)&＃xff0c;M 即树的高度。但这么做带来的代价是 Iptables 规则变得更加复杂。

IPVS 实现 Service 负载均衡

什么是 IPVS

• 传输层 Load Balancer&＃xff0c;LVS 负载均衡器的实现&＃xff1b;
• 同样基于 Netfilter&＃xff0c;但使用的是 hash 表&＃xff1b;
• 支持 TCP, UDP&＃xff0c;SCTP 协议&＃xff0c;IPV4&＃xff0c;IPV6&＃xff1b;
• 支持多种负载均衡策略&＃xff0c;如 rr, wrr, lc, wlc, sh,dh, lblc…
• 支持会话保持&＃xff0c; persistent connection 调度算法。

IPVS 的三种转发模式

IPVS 有三种转发模式&＃xff0c;分别是&＃xff1a;DR&＃xff0c;隧道和 NAT。

● DR 模式工作在 L2&＃xff0c;使用的 MAC 地址&＃xff0c;速度最快。请求报文经过 IPVS director&＃xff0c;转发给后端服务器&＃xff0c;响应报文直接回给客户端。缺点是不支持端口映射&＃xff0c;于是这种模式就很可惜地 PASS 掉了。

● 隧道模式&＃xff0c;使用 IP 包封装 IP 包。后端服务器接收到隧道包后&＃xff0c;首先会拆掉封装的 IP 地址头&＃xff0c;然后响应报文也会直接回给客户端。IP 模式同样不支持端口映射&＃xff0c;于是这种模式也被 PASS 掉了。

● NAT 模式支持端口映射&＃xff0c;与前面两种模式不同的是&＃xff0c;NAT 模式要求回程报文经过 IPVS 的 director。内核原生版本 IPVS 只做 DNAT&＃xff0c;不做 SNAT。

使用 IPVS 实现流量转发

使用 IPVS 做流量转发只需经过以下几个简单的步骤。

• 绑定 VIP

由于 IPVS 的 DNAT 钩子挂在 INPUT 链上&＃xff0c;因此必须要让内核识别 VIP 是本机的 IP。绑定 VIP 至少有三种方式&＃xff1a;

1.创建一块 dummy 网卡&＃xff0c;然后绑定&＃xff0c;如下所示。

# ip link add dev dummy0 type dummy # ip addr add 192.168.2.2/32 dev dummy0

2.直接在本地路由表中加上 VIP 这个 IP 地址。

# ip route add to local 192.168.2.2/32 dev eth0proto kernel

3.在本地网卡上增加一个网卡别名。

# ifconfig eth0:1 192.168.2.2netmask255.255.255.255 up

• 为这个虚 IP 创建一个 IPVS 的 virtual server

# ipvsadm -A -t 192.168.60.200:80 -s rr -p 600

这上面的例子中&＃xff0c;IPVS virtual server 的虚 IP 是 192.168.60.200:80&＃xff0c;会话保持时间 600s。

• 为这个 IPVS service 创建相应的 real server

# ipvsadm -a -t 192.168.60.200:80 -r 172.17.1.2:80–m

# ipvsadm -a -t 192.168.60.200:80 -r 172.17.2.3:80–m

这上面的例子中&＃xff0c;为 192.168.60.200:80 这个 IPVS 的 virtual server 创建了两个 real server&＃xff1a;172.17.1.2:80 和 172.17.2.3:80。

Iptables vs. IPVS

Iptables vs. IPVS 规则增加时延

通过观察上图很容易发现&＃xff1a;

• 增加 Iptables 规则的时延&＃xff0c;随着规则数的增加呈“指数”级上升&＃xff1b;
• 当集群中的 Service 达到 2 万个时&＃xff0c;新增规则的时延从 50us 变成了 5 小时&＃xff1b;
• 而增加 IPVS 规则的时延始终保持在 100us 以内&＃xff0c;几乎不受规则基数影响。这中间的微小差异甚至可以认为是系统误差。
• Iptables vs. IPVS 网络带宽

这是我们用 iperf 实测得到两种模式下的网络带宽。可以看到 Iptables 模式下第一个 Service 和最后一个 Service 的带宽有差异。最后一个 Service 带宽明显小于第一个&＃xff0c;而且随着 Service 基数的上升&＃xff0c;差异越来越明显。

而 IPVS 模式下&＃xff0c;整体带宽表现高于 Iptables。当集群中的 Service 数量达到 2.5 万时&＃xff0c;Iptables 模式下的带宽已基本为零&＃xff0c;而 IPVS 模式的服务依然能够保持在先前一半左右的水平&＃xff0c;提供正常访问。

Iptables vs. IPVS CPU/内存消耗

很明显&＃xff0c;IPVS 在 CPU/内存两个维度的指标都要远远低于 Iptables。

特性社区状态

这个特性从 1.8 版本引入 Alpha&＃xff0c;到 1.9 版本发布 Beta&＃xff0c;修复了大部分的问题&＃xff0c;目前已经比较稳定&＃xff0c;强烈推荐大家使用。另外这个特性目前主要是我们华为云 K8S 开源团队在维护&＃xff0c;大家在使用中如果发现问题&＃xff0c;欢迎反映到社区&＃xff0c;或者我们这边。谢谢大家&＃xff01;

王泽锋/华为云 Kubernetes 开源负责人

多年电信领域系统软件开发和性能调优经验&＃xff0c;对深度报文解析、协议识别颇有研究。华为云 PaaS 服务团队核心成员&＃xff0c;专注于 PaaS 产品和容器开源社区&＃xff0c;目前负责华为云 K8S 开源团队在社区贡献的整体工作。