kube-proxy IPVS 模式的工作原理

Posted 2023-04-26

参考技术A

Kubernetes 中的 Service 就是一组同 label 类型 Pod 的服务抽象，为服务提供了负载均衡和反向代理能力，在集群中表示一个微服务的概念。 kube-proxy 组件则是 Service 的具体实现，了解了 kube-proxy 的工作原理，才能洞悉服务之间的通信流程，再遇到网络不通时也不会一脸懵逼。

kube-proxy 有三种模式： userspace 、 iptables 和 IPVS ，其中 userspace 模式不太常用。 iptables 模式最主要的问题是在服务多的时候产生太多的 iptables 规则，非增量式更新会引入一定的时延，大规模情况下有明显的性能问题。为解决 iptables 模式的性能问题，v1.11 新增了 IPVS 模式（v1.8 开始支持测试版，并在 v1.11 GA），采用增量式更新，并可以保证 service 更新期间连接保持不断开。

目前网络上关于 kube-proxy 工作原理的文档几乎都是以 iptables 模式为例，很少提及 IPVS ，本文就来破例解读 kube-proxy IPVS 模式的工作原理。为了理解地更加彻底，本文不会使用 Docker 和 Kubernetes，而是使用更加底层的工具来演示。

我们都知道，Kubernetes 会为每个 Pod 创建一个单独的网络命名空间 (Network Namespace) ，本文将会通过手动创建网络命名空间并启动 HTTP 服务来模拟 Kubernetes 中的 Pod。

本文的目标是通过模拟以下的 Service 来探究 kube-proxy 的 IPVS 和 ipset 的工作原理：

跟着我的步骤，最后你就可以通过命令 curl 10.100.100.100:8080 来访问某个网络命名空间的 HTTP 服务。为了更好地理解本文的内容，推荐提前阅读以下的文章：

首先需要开启 Linux 的路由转发功能：

接下来的命令主要做了这么几件事：

在网络命名空间 netns_dustin 中启动 HTTP 服务：

打开另一个终端窗口，在网络命名空间 netns_leah 中启动 HTTP 服务：

测试各个网络命名空间之间是否能正常通信：

整个实验环境的网络拓扑结构如图：

为了便于调试 IPVS 和 ipset，需要安装两个 CLI 工具：

下面我们使用 IPVS 创建一个虚拟服务 (Virtual Service) 来模拟 Kubernetes 中的 Service :

创建了虚拟服务之后，还得给它指定一个后端的 Real Server ，也就是后端的真实服务，即网络命名空间 netns_dustin 中的 HTTP 服务：

该命令会将访问 10.100.100.100:8080 的 TCP 请求转发到 10.0.0.11:8080 。这里的 --masquerading 参数和 iptables 中的 MASQUERADE 类似，如果不指定，IPVS 就会尝试使用路由表来转发流量，这样肯定是无法正常工作的。

测试是否正常工作：

实验成功，请求被成功转发到了后端的 HTTP 服务！

上面只是在 Host 的网络命名空间中进行测试，现在我们进入网络命名空间 netns_leah 中进行测试：

哦豁，访问失败！

要想顺利通过测试，只需将 10.100.100.100 这个 IP 分配给一个虚拟网络接口。至于为什么要这么做，目前我还不清楚，我猜测可能是因为网桥 bridge_home 不会调用 IPVS，而将虚拟服务的 IP 地址分配给一个网络接口则可以绕过这个问题。

Netfilter 是一个基于用户自定义的 Hook 实现多种网络操作的 Linux 内核框架。Netfilter 支持多种网络操作，比如包过滤、网络地址转换、端口转换等，以此实现包转发或禁止包转发至敏感网络。

针对 Linux 内核 2.6 及以上版本，Netfilter 框架实现了 5 个拦截和处理数据的系统调用接口，它允许内核模块注册内核网络协议栈的回调功能，这些功能调用的具体规则通常由 Netfilter 插件定义，常用的插件包括 iptables、IPVS 等，不同插件实现的 Hook 点（拦截点）可能不同。另外，不同插件注册进内核时需要设置不同的优先级， 例如默认配置下，当某个 Hook 点同时存在 iptables 和 IPVS 规则时，iptables 会被优先处理。

Netfilter 提供了 5 个 Hook 点，系统内核协议栈在处理数据包时，每到达一个 Hook 点，都会调用内核模块中定义的处理函数。 调用哪个处理函数取决于数据包的转发方向，进站流量和出站流量触发的 Hook 点是不一样的。

内核协议栈中预定义的回调函数有如下五个：

iptables 实现了所有的 Hook 点，而 IPVS 只实现了 LOCAL_IN 、 LOCAL_OUT 、 FORWARD 这三个 Hook 点。既然没有实现 PRE_ROUTING ，就不会在进入 LOCAL_IN 之前进行地址转换，那么数据包经过路由判断后，会进入 LOCAL_IN Hook 点，IPVS 回调函数如果发现目标 IP 地址不属于该节点，就会将数据包丢弃。

如果将目标 IP 分配给了虚拟网络接口，内核在处理数据包时，会发现该目标 IP 地址属于该节点，于是可以继续处理数据包。

当然，我们不需要将 IP 地址分配给任何已经被使用的网络接口，我们的目标是模拟 Kubernetes 的行为。Kubernetes 在这里创建了一个 dummy 接口，它和 loopback 接口类似，但是你可以创建任意多的 dummy 接口。它提供路由数据包的功能，但实际上又不进行转发。dummy 接口主要有两个用途：

看来 dummy 接口完美符合实验需求，那就创建一个 dummy 接口吧：

将虚拟 IP 分配给 dummy 接口 dustin-ipvs0 :

到了这一步，仍然访问不了 HTTP 服务，还需要另外一个黑科技： bridge-nf-call-iptables 。在解释 bridge-nf-call-iptables 之前，我们先来回顾下容器网络通信的基础知识。

Kubernetes 集群网络有很多种实现，有很大一部分都用到了 Linux 网桥:

不管是 iptables 还是 ipvs 转发模式，Kubernetes 中访问 Service 都会进行 DNAT，将原本访问 ClusterIP:Port 的数据包 DNAT 成 Service 的某个 Endpoint (PodIP:Port) ，然后内核将连接信息插入 conntrack 表以记录连接，目的端回包的时候内核从 conntrack 表匹配连接并反向 NAT，这样原路返回形成一个完整的连接链路:

但是 Linux 网桥是一个虚拟的二层转发设备，而 iptables conntrack 是在三层上，所以如果直接访问同一网桥内的地址，就会直接走二层转发，不经过 conntrack:

启用 bridge-nf-call-iptables 这个内核参数 (置为 1)，表示 bridge 设备在二层转发时也去调用 iptables 配置的三层规则 (包含 conntrack)，所以开启这个参数就能够解决上述 Service 同节点通信问题。

所以这里需要启用 bridge-nf-call-iptables :

现在再来测试一下连通性：

终于成功了！

虽然我们可以从网络命名空间 netns_leah 中通过虚拟服务成功访问另一个网络命名空间 netns_dustin 中的 HTTP 服务，但还没有测试过从 HTTP 服务所在的网络命名空间 netns_dustin 中直接通过虚拟服务访问自己，话不多说，直接测一把：

啊哈？竟然失败了，这又是哪里的问题呢？不要慌，开启 hairpin 模式就好了。那么什么是 hairpin 模式呢？ 这是一个网络虚拟化技术中常提到的概念，也即交换机端口的VEPA模式。这种技术借助物理交换机解决了虚拟机间流量转发问题。很显然，这种情况下，源和目标都在一个方向，所以就是从哪里进从哪里出的模式。

怎么配置呢？非常简单，只需一条命令：

再次进行测试：

还是失败了。。。

然后我花了一个下午的时间，终于搞清楚了启用混杂模式后为什么还是不能解决这个问题，因为混杂模式和下面的选项要一起启用才能对 IPVS 生效：

最后再测试一次：

这次终于成功了，但我还是不太明白为什么启用 conntrack 能解决这个问题，有知道的大神欢迎留言告诉我！

如果想让所有的网络命名空间都能通过虚拟服务访问自己，就需要在连接到网桥的所有 veth 接口上开启 hairpin 模式，这也太麻烦了吧。有一个办法可以不用配置每个 veth 接口，那就是开启网桥的混杂模式。

什么是混杂模式呢？普通模式下网卡只接收发给本机的包（包括广播包）传递给上层程序，其它的包一律丢弃。混杂模式就是接收所有经过网卡的数据包，包括不是发给本机的包，即不验证MAC地址。

如果一个网桥开启了混杂模式，就等同于将所有连接到网桥上的端口（本文指的是 veth 接口）都启用了 hairpin 模式 。可以通过以下命令来启用 bridge_home 的混杂模式：

现在即使你把 veth 接口的 hairpin 模式关闭：

仍然可以通过连通性测试：

在文章开头准备实验环境的章节，执行了这么一条命令：

这条 iptables 规则会对所有来自 10.0.0.0/24 的流量进行伪装。然而 Kubernetes 并不是这么做的，它为了提高性能，只对来自某些具体的 IP 的流量进行伪装。

为了更加完美地模拟 Kubernetes，我们继续改造规则，先把之前的规则删除：

然后添加针对具体 IP 的规则：

果然，上面的所有测试都能通过。先别急着高兴，又有新问题了，现在只有两个网络命名空间，如果有很多个怎么办，每个网络命名空间都创建这样一条 iptables 规则？我用 IPVS 是为了啥？就是为了防止有大量的 iptables 规则拖垮性能啊，现在岂不是又绕回去了。

不慌，继续从 Kubernetes 身上学习，使用 ipset 来解决这个问题。先把之前的 iptables 规则删除：

然后使用 ipset 创建一个集合 (set) ：

这条命令创建了一个名为 DUSTIN-LOOP-BACK 的集合，它是一个 hashmap ，里面存储了目标 IP、目标端口和源 IP。

接着向集合中添加条目：

现在不管有多少网络命名空间，都只需要添加一条 iptables 规则：

网络连通性测试也没有问题：

最后，我们把网络命名空间 netns_leah 中的 HTTP 服务也添加到虚拟服务的后端：

再向 ipset 的集合 DUSTIN-LOOP-BACK 中添加一个条目：

终极测试来了，试着多运行几次以下的测试命令：

你会发现轮询算法起作用了：

相信通过本文的实验和讲解，大家应该理解了 kube-proxy IPVS 模式的工作原理。在实验过程中，我们还用到了 ipset，它有助于解决在大规模集群中出现的 kube-proxy 性能问题。如果你对这篇文章有任何疑问，欢迎和我进行交流。

podip网段不同servicename不通

参考技术A 原因：kube-proxy使用了iptable模式，修改为ipvs模式则可以在pod内ping通clusterIP或servicename. 参考技术B 原因：kube-proxy使用了iptable模式，修改为ipvs模式则可以在pod内ping通clusterIP或servicename 参考技术C 原因：kube-proxy使用了iptable模式，修改为ipvs模式则可以在pod内ping通clusterIP或servicename.