从一次apisix限流故障窥探kube-proxy原理

一、背景

笔者在项目上用apisix网关limit-count插件对接口限流时，发现在k8s环境下，用nodeport 请求接口，无法按客户端IP进行限流。

实验环境如下：

复制代码

k8s版本  1.19.3
apisix版本  3.2.2

路由配置了limit-count插件

json 复制代码

"limit-count":{"count":3,"time_window":60,"policy":"local"}

期望：

每个客户端均可以在1分钟的限流窗口内访问三次。

现状：

在某客户端请求三次后被限流，在此限流期之中，其他客户端也均被限流。

二、原因分析

先说结论，k8s nodeport的external-traffic-policy属性可以设置成 Cluster 或者 Local。

Cluster：当设置为 Cluster 时，。kube-proxy会做SNAT改写，此时客户端源ip会被改写为节点的ip。

Local：当设置为 Local 时，kube-proxy会保留源IP。

k8s nodeport service 默认是采用Cluster，客户端源ip会被改写为节点的ip。而apisix需要通过对源客户端ip进行计数（感兴趣可以读读源码），从而引发了限流计数异常。现在我们将external-traffic-policy设置成Local以保留客户端源IP。但是又遇见一个问题，设置成 Local 后，只能通过apisix所在地的宿主机nodeport访问，所以我们深入一下原因。

三、探究一下

在此之前，需要先了解一下kube-proxy的基本代理。以下是k8s各个版本的代理机制实现。

k8s版本	代理机制
version<=1.0	userspace mode
1.0<version<=1.8	userspace mode ,iptables
version>1.8	iptables,ipvs

让我们实际探究一下。external-traffic-policy设置成local后，kube-proxy做了什么？

笔者当前环境1.19版本，所以默认采用的是ipvs的代理模式

当external-traffic-policy设置成cluster时，用 ipvsadm -L -n查看ipvs规则，会发现集群各个节点的ipvs规则，都配置了当前节点的30842端口都转向了apisix的地址100.116.59.53:9080，如下图：

节点10.240.11.209的ipvs规则

节点10.240.11.131的ipvs规则

当external-traffic-policy设置成local后，再查看ipvs规则，会发现只有apisix pod所在的宿主机的ipvs规则保持不变。其他节点ipvs规则都不再将30842端口流量转发到apisix上，如下图

*节点10.240.11.209的ipvs规则（apisix所在的宿主机）

节点10.240.11.131的ipvs规则

由此可以得出一个初步结论：

当external-traffic-policy设置成local时，不允许跨节点转发，kube-proxy通过感知service变化，更新了各个节点的ipvs规则，只有pod所在宿主机ipvs规则能接收nodeport访问。

具体地，kube-proxy通过netlink接口与内核中的IPVS子系统通信，以便动态地创建、更新或删除IPVS规则，从而控制Kubernetes集群中的服务流量路由，netlink是Linux内核与用户空间进程之间进行通信的一种机制，它允许内核与用户空间之间传递消息，netlink直接工作在内核态，所以在性能上比 iptables 更优。

四、最终的解决方案

1）external-traffic-policy设置成local

2）给apisix设置对外提供访问的nodeport节点的亲和性