# kube-proxy

<mark style="color:blue;">**在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程，可以把这个进程看作Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上**</mark>。

此外，**Service的Cluster IP与NodePort等概念是kube-proxy服务通过iptables的NAT转换实现的**，kube-proxy在运行过程中动态创建与Service相关的iptables规则，这些规则实现了将访问服务（Cluster IP或NodePort）的请求负载分发到后端Pod的功能。由于iptables机制针对的是本地的kube-proxy端口，所以在每个Node上都要运行kube-proxy组件，这样一来，在Kubernetes集群内部，我们可以在任意Node上发起对Service的访问请求。

综上所述，**由于kube-proxy的作用，在Service的调用过程中客户端无须关心后端有几个Pod，中间过程的通信、负载均衡及故障恢复都是透明的。**

## 代理模式

{% content-ref url="../../service/service-dai-li-mo-shi" %}
[service-dai-li-mo-shi](../../service/service-dai-li-mo-shi)
{% endcontent-ref %}

### <mark style="color:blue;">**userspace**</mark>

起初，**kube-proxy进程是一个真实的TCP/UDP代理，类似HA Proxy**，负责从Service到Pod的访问流量的**转发**，这种模式被称为<mark style="color:blue;">**userspace**</mark>（用户空间代理）模式。当某个Pod以Cluster IP方式访问某个Service的时候，这个流量会被Pod所在本机的iptables转发到本机的kube-proxy进程，然后**由kube-proxy建立起到后端Pod的TCP/UDP连接，随后将请求转发到某个后端Pod上，并在这个过程中实现负载均衡功能**。

### <mark style="color:blue;">**iptables**</mark>

Kubernetes从1.2版本开始，将iptables作为kube-proxy的默认模式。<mark style="color:blue;">**iptables**</mark>模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，**Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod**。与第1代的userspace模式相比，iptables模式完全工作在内核态，不用再经过用户态的kube-proxy中转，因而性能更强。

iptables模式虽然实现起来简单，但存在无法避免的缺陷：**在集群中的Service和Pod大量增加以后，iptables中的规则会急速膨胀，导致性能显著下降，在某些极端情况下甚至会出现规则丢失的情况**，并且这种故障难以重现与排查，于是Kubernetes从1.8版本开始引入第3代的IPVS（IP Virtual Server）模式

### <mark style="color:blue;">IPVS</mark>

iptables与IPVS虽然都是基于Netfilter实现的，但因为定位不同，二者有着本质的差别：

* **iptables是为防火墙而设计的**；
* I**PVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。**

与iptables相比，IPVS拥有以下明显优势：

* **为大型集群提供了更好的可扩展性和性能**；
* **支持比iptables更复杂的复制均衡算法**（最小负载、最少连接、加权等）；
* **支持服务器健康检查和连接重试等功能**；
* &#x20;**可以动态修改ipset的集合，即使iptables的规则正在使用这个集合**。

