The Introduction to Kube-proxy

介绍

Kube-proxy是Kubernetes的核心组件，部署在每个节点上。作为服务的透明代理兼负载均衡器（在K8s中，提供相同服务的一组Pod可以抽象成一个服务，通过统一入口对外提供服务，每个服务都有一个虚拟IP地址和端口号供客户端访问），其核心功能是将到某个服务的访问请求转发到后端的Pod实例上。

Kube-proxy维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与Pod进行网络通信。如果操作系统提供了数据包过滤层，Kube-proxy会通过它来实现网络规则。否则，Kube-proxy仅转发流量本身。

此外，服务的虚拟IP与NodePort等概念是kube-proxy通过iptables的NAT转换实现的，Kube-proxy在运行过程中动态创建与服务相关的iptables规则，这些规则实现了将访问服务请求负载分发到后端Pod的功能。

架构

Kube-proxy提供集群内部的服务发现和负载均衡，在每个节点上，Kubernetes都通过DeamonSet的方式部署一个Kube-proxy。这一设计体现了Kube-proxy的伸缩性：需求访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多。

如图所示，Kube-proxy从API Server获取所有的服务信息，并根据服务信息创建代理服务，实现从服务到Pod的请求路由和转发，以及虚拟转发网络。

Kube-proxy使用DaemonSet进行部署：DaemonSet管理K8s集群中每个node上仅运行一份Pod的副本实例。当node加入集群时创建Pod，当node离开集群时回收Pod。如果删除DaemonSet，其创建的所有Pod也被删除，DaemonSet中的Pod将覆盖整个集群。

功能性

功能	子功能	Kube-proxy
服务发现		✓
流量治理	HTTP	✓
	TCP	✓
	UDP	✓
	SCTP	✓
负载均衡	随机	✓
	轮询	✓
外部访问		✓

模式

Userspace模式

在用户空间模式下，kube-proxy进程是一个TCP/UDP代理，负责从Service到Pod的访问流量的转发。当某个Pod以Cluster IP方式访问某个Service的时候，这个流量会被Pod所在本机的iptables转发到本机的kube-proxy进程，然后由kube-proxy建立起到后端Pod的TCP/UDP链接，随后将请求转发到某个后端的Pod上，并在这个过程中实现负载均衡功能。

kube-proxy 会为每个 Service 随机监听一个端口，并增加一条 IPtables 规则。从客户端到 ClusterIP:Port 的报文都会被重定向到该端口，而端口收到报文后，通过负载均衡策略分发给对应的 Pod。

用户空间模式的问题在于，Service的请求会先从用户空间进入内核iptables，然后再回到用户空间，由kube-proxy完成后端Endpoints的选择和代理工作，这样流量从用户空间进出内核带来的性能损耗是不可接受的。

Iptables模式

Iptable模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时追踪跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。

Iptable模式是全自动模式：根据Kubernetes的网络模型，一个Node上的Pod与其他Node上的Pod应该能够直接建立双向的TCP/IP通信通道，所以如果直接修改iptables规则，则也可以实现kube-proxy的功能。并且，iptables模式完全工作在内核态，不再经过用户态的kube-proxy中转，因此性能更强。

Iptable模式的缺陷在于：在集群中的Service和Pod大量增加以后，iptables中的规则会急速膨胀，导致性能显著下降，在某些极端情况下甚至会出现规则丢失的情况，并且这种故障难以重现与排查。

IPVS模式

Iptables是为防火墙而设计的；IPVS（IP Virtual Server）则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。相比iptables，IPVS拥有一下明显优势：

· 为大型集群提供了更好的可扩展性和性能

· 支持比iptables更复杂的负载均衡算法（最小负载、最少连接、加权等）

· 支持服务器健康检查和连接重试等功能

· 可动态修改ipset的集合

Ipset是iptables的一种扩展，引入了带索引的数据结构。因此，当规则很多时，ipset可提供高效地查找和匹配。