【k8s】kube-proxy 工作模式

文章目录

Userspace模式：
iptables模式：
- 负载均衡（Load Balancing） LB
IPVS模式：

Kube-proxy是Kubernetes集群中的一个关键组件，它负责实现服务发现和负载均衡。Kube-proxy可以以三种不同的模式工作，分别是：userspace模式、iptables模式和IPVS模式。

Userspace模式：

在Userspace模式下，Kube-proxy通过在主机上创建一个userspace进程来实现服务代理。该进程拦截所有服务流量，并根据服务配置信息将流量转发到后端Pod。这种模式下，kube-proxy会动态更新iptables规则，将服务的虚拟IP地址映射到后端Pod的IP地址。但是，由于每个数据包都要经过userspace进程，因此性能相对较低。

iptables模式：

在iptables模式下，Kube-proxy使用iptables规则实现服务代理。当创建或删除服务时，kube-proxy会动态更新主机上的iptables规则，以将服务的虚拟IP地址映射到后端Pod的IP地址。这种模式下，数据包直接通过内核的iptables规则进行转发，因此性能较高。

缺点
不能提供灵活的LB策略，后端不可用时也不能重试

负载均衡（Load Balancing） LB

Kubernetes（K8s）中的负载均衡（Load Balancing）策略是用于分配网络流量给后端Pod的方法。K8s提供了几种不同的负载均衡策略，可以根据应用程序的需求进行选择。

以下是K8s中常见的负载均衡策略：

轮询（Round Robin）：

默认的负载均衡策略，请求按顺序依次分发给可用的后端Pod。每个请求都会按照顺序分配到下一个可用的Pod上。

SessionAffinity：

也称为会话粘滞（Sticky Sessions），该策略根据客户端的会话信息将请求路由到相同的后端Pod上。

这样可以确保来自同一客户端的请求都发送到同一个后端Pod，维护会话的状态。

最少连接（Least Connection）：

该策略会将请求发送给当前连接数量最少的后端Pod。

这样可以使负载均衡更加均匀，并避免某些Pod过载的问题。

IP哈希（IP Hash）：

根据客户端的IP地址将请求路由到后端Pod。

通过哈希算法，相同IP地址的请求将始终被路由到同一个后端Pod上。

这有助于保持与特定客户端的连接会话。

SessionAffinity和IP哈希的异同

相同点：

目标：SessionAffinity和IP哈希都旨在实现将来自同一客户端的请求路由到相同的后端Pod上，以维护会话状态或连接状态。

不同点：

粒度：SessionAffinity是基于会话信息进行分配的，而IP哈希是基于客户端的IP地址进行分配的。SessionAffinity更关注于维护特定会话的状态，而IP哈希更关注于维护与特定客户端的连接会话。
功能：SessionAffinity可以确保来自同一客户端的请求都发送到同一个后端Pod上，即使在负载均衡过程中发生变化。这对于需要保持会话状态的应用程序很有用。而IP哈希则通过哈希算法将相同IP地址的请求路由到同一个后端Pod上，有助于维护与特定客户端的连接状态，但它无法处理客户端IP地址的变化。
灵活性：SessionAffinity比IP哈希更加灵活，因为它可以基于请求中的任意会话信息进行路由。您可以选择使用Cookie、HTTP头部或任何其他会话标识符来实现SessionAffinity。而IP哈希则仅依赖于客户端的IP地址进行路由选择。
适用场景：SessionAffinity适用于需要维护会话状态的应用程序，例如在线购物网站的购物车或用户登录状态。IP哈希适用于需要保持与特定客户端的连接会话状态的应用程序，例如长连接应用或持久化会话。

自定义负载均衡器：

除了Kubernetes提供的默认策略，也可以使用外部负载均衡器来替代或补充K8s内置的负载均衡策略。这样可以利用更丰富的负载均衡功能和灵活性。

IPVS模式：

IP Virtual Server（IPVS）模式是一种高级的负载均衡模式，使用Linux内核的IPVS功能来实现服务代理。

在这种模式下，kube-proxy维护一个IPVS表，根据服务配置信息将流量转发到后端Pod。

相比于iptables模式，IPVS模式在性能和可扩展性方面更为优秀。

一般来说，对于大规模的生产环境，IPVS模式是一个更好的选择，因为它具有更好的性能和可扩展性。

IPVS实现了一种基于内核态的L4（传输层）负载均衡方案，能够承载大量并发请求，并分配到不同的后端Pod上。

以下是IPVS模式的详细介绍：

IPVS架构

IPVS通过将流量路由到虚拟服务和后端节点（Pod）之间的网络代理，从而实现负载均衡的目的。在K8s中，它是通过kube-proxy代理实现的。

在IPVS架构中，以下组件完成了流量的路由和转发：

VIP（Virtual IP Address）：虚拟服务的IP地址。
Real Server：后端节点的IP地址。
Service：定义了一个VIP和端口对应关系的抽象概念。Service对象会自动创建一个VIP并暴露给客户端。
Endpoint：定义了一个Service所依赖的真实后端节点的Pod信息。

IPVS和iptables的区别

与iptables模式相比，IPVS具有以下优势：

更快：系统可处理的请求量更高，性能更优，能够更好地处理高负载环境下的流量。
更灵活：可以使用多种负载均衡算法（包括Round Robin、Least Connection、Source Hash等），具有更好的扩展性和适应性。
更可靠：更可靠的连接状态检查和更高效的流量控制。
更安全：提供了更多的安全机制，例如集群中的计数器机制、防止DDoS攻击等。

如何启用IPVS模式

要启用IPVS模式，需要进行以下几个步骤：

1）在kubelet的启动命令中使用–kube-proxy-mode=ipvs参数。

  kubelet --kube-proxy-mode=ipvs ...

2）在所有节点上安装ipvsadm工具。

  sudo apt-get update
  sudo apt-get install ipvsadm

3）创建kube-proxy的ConfigMap保存IPVS代理的配置。

4）使用kubectl replace命令替换kube-proxy的DaemonsSet对象，以便使用新创建的ConfigMap作为配置文件。

  kubectl replace --force -f kube-proxy.yaml

5）重启kube-proxy daemon进程，以便应用新的配置。

支持的负载均衡算法

IPVS支持多种负载均衡算法，从而满足不同场景下的负载均衡策略。包括以下常见的负载均衡算法：

RR（Round Robin）：轮询法，平均分配请求到后端节点。
LC（Least Connection）：最少连接法，将请求发送到当前连接数最少的节点。
DH（Destination Hashing）：根据虚拟服务地址和端口，将请求路由到一组特定的后端节点。特别适合一些需要保持会话一致性的应用场景，例如Web应用中需要将同一个用户的请求路由到同一个后端节点以保持会话状态。
SH（Source Hashing）：根据客户端IP地址进行哈希计算，将同一客户端的请求路由到同一个后端节点。

总之，IPVS模式提供了一种高效、可扩展的负载均衡方案，能够满足K8s集群中高并发、高流量等复杂场景下的需求，并且在性能、安全、适应性等方面都具备优秀的表现。