集群中的每个节点上都有 kube-proxy 服务，负责为 Service（除 ExternalName 外）实现一种形式的虚拟网络地址；
1）在 Kubernetes v1.0 中，Service 是“第 4 层”（基于 IP 的 TCP/UDP）构造，代理纯粹在用户空间中；
2）在 Kubernetes v1.1 中，添加 Ingress API（beta）来表示“第 7 层”（HTTP）服务，也添加 iptables 代理，并成为自 Kubernetes v1.2 以来的默认操作模式；
3）在 Kubernetes v1.8.0-beta.0 中，添加 ipvs 代理；

下面是 kube-proxy 运行的三种模式：

代理模式：userspace

该模式下，kube-proxy 观察 Kubernetes master 节点，然后删除和添加 Service 与 Endpoints 对象。为每个 Service 在本地节点打开一个端口（随机），任何访问该“代理端口”的连接将被代理到 Service 的后端 Pod 上。至于用哪个后端 Pod，要基于 Service 的 SessionAffinity。最后，它安装防火墙规则，捕获到 Service 的 Cluster IP（虚拟）和端口的流量，然后重定向流量到“代理端口”；

默认后端是循环选择的；

Client  =>  ClusterIP:Port(iptables)  =>  proxy port(kube-proxy)  =>  Backend Pod 1 ~ N

（”为每个 Service 在本地节点打开一个端口“，该端口号存在于 Cluster IP 上）

代理模式：iptables

该模式下，kube-proxy 观察 Kubernetes master 节点，然后删除和添加 Service 与 Endpoints 对象。对于每个 Service，它安装防火墙规则，捕获到 Service 的 Cluster IP（虚拟）和端口的流量，然后重定向流量到 Service 的后端集合。对于每个 Endpoints 对象，它安装防火墙规则，来选择后端的 Pod；

默认后端是循环选择的；

Client  =>  ClusterIP:Port(iptables)  =>  Backend Pod 1 ~ N
											^
											|
										kube-proxy <= api-server

代理模式：ipvs

该模式下，kube-proxy 观察 Kubernetes 的 Service 和 Endpoints，然后调用 netlink 接口来创建 ipvs 规则，并定期和 k8s 的 Service 和 Endpoints 同步 ipvs 规则，确保 ipvs 状态符合预期。当访问服务时，流量将被重定向到其中一个后端 Pod 上；

类似于 iptables，ipvs 基于 netfilter 的钩子函数，但是使用哈希表作为底层的数据结构，并工作在内核空间。这表示 ipvs 重定向流量更快，当同步规则时由更好的效率。并且 ipvs 提供了更好的负载均衡算法：

使用 ipvs 模式需要在节点上安装了 IPVS 内核模块，然后再运行 kube-proxy 服务。当 kube-proxy 以 ipvs 代理模式启动时，kube-proxy 将验证节点上是否安装了 IPVS 模块，如果未安装，则 kube-proxy 将回退到 iptables 代理模式；

Client  =>  ClusterIP:Port(Virtual Server(ipvs))  =>  Backend Pod 1 ~ N
											^
											|
									kube-proxy <- apiserver

Strict ARP

https://www.ctyun.cn/developer/article/442824893210693

kube-proxy 是 Kubernetes 集群中的一个重要组件，负责实现集群内部的负载均衡和服务的访问控制。kube-proxy 可以通过实现不同的代理模式来提供这些功能。其中之一就是 strictARP。

在 strictARP 模式下，kube-proxy 通过监视集群中的 Pod IP 地址和 MAC 地址的变化，并使用静态 ARP 条目来确保流量正确路由。当一个新的 Pod IP 地址被分配时，kube-proxy 会在集群内部生成一个静态 ARP 项，将该 IP 地址映射到 Pod 的 MAC 地址上。这样，其他节点上的 Pod 就可以直接通过这个静态 ARP 项找到目标 Pod 并发送网络流量。

性质：

• strictARP 模式的优点是简单且高效。它不需要依赖额外的网络配置或专门的路由器设备来实现流量的路由和负载均衡。同时，这种模式还可以实现相对较低的延迟，因为流量不需要经过额外的网络层。
• 然而，strictARP 模式也存在一些限制。由于 ARP 协议设计的原因，它只能在一个局域网内工作，因此 strictARP 只适用于同一网络子网内的 Pod 间通信。此外，strictARP 模式还可能对大规模集群的性能产生一定的影响，因为每个节点上的 kube-proxy 都需要维护并处理大量的静态 ARP 条目。

总的来说，strictARP 模式是 kube-proxy 提供的一种基于静态 ARP 的负载均衡和访问控制机制。它适用于小型集群或在同一网络子网内的 Pod 间通信，并具有简单高效的特点。

strict ARP 开启之后相当于把将 arp_ignore 设置为 1 并将 arp_announce 设置为 2 启用严格的 ARP，这个原理和 LVS 中的 DR 模式对 RS 的配置一样.

代理模式的总结

在任何一种代理模式中，访问 IP:Port 的流量被代理到对应的后端，而不需要 Client 知道任何的 k8s 的 Service 和 Endpoints 或 Pod。基于 Client-IP 的 Session 亲和可以通过将service.spec.sessionAffinity设置为ClientIP来实现。基于此，还可以设置 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 来实现最大的 Session 粘贴时间（默认 10800）；

参考文献

kubernetes – How to find which mode kube-proxy is running in – Stack Overflow
Manage kube-proxy by using IPVS