Service代理模式

在Kubernetes集群中，每个节点运行一个kube-proxy进程。kube-proxy负责为Service实现一种VIP（虚拟IP）的形式。

• 在Kubernetesv 1.0版本中，代理完全是userspace

• 在Kubernetesv 1.1版中新增了iptables代理

• 从Kubernetesv 1.2版起，默认是iptables代理

• 从Kubernetesv 1.8版开始新增了ipvs代理

生产环境建议使用ipvs模式。

iptables代理模式

此代理模式仅适用于 Linux 节点。

在这种模式下，kube-proxy 监视 Kubernetes 控制平面，获知对 Service 和 EndpointSlice 对象的添加和删除操作。

• 对于每个 Service，kube-proxy 会添加 iptables 规则，这些规则捕获流向 Service 的 clusterIP 和 port 的流量， 并将这些流量重定向到 Service 后端集合中的其中之一。

• 对于每个Endpoint，它会添加指向一个特定后端 Pod 的 iptables 规则。

• 默认情况下，iptables 模式下的 kube-proxy 会随机选择一个后端。

• 使用 iptables 处理流量的系统开销较低，因为流量由 Linux netfilter 处理， 无需在用户空间和内核空间之间切换。这种方案也更为可靠。

ipvs代理模式

此代理模式仅适用于 Linux 节点。

在 ipvs 模式下，kube-proxy 监视 Kubernetes Service 和 EndpointSlice， 然后调用 netlink 接口创建 IPVS 规则， 并定期与 Kubernetes Service 和 EndpointSlice 同步 IPVS 规则。 该控制回路确保 IPVS 状态与期望的状态保持一致。 访问 Service 时，IPVS 会将流量导向到某一个后端 Pod。

IPVS 代理模式基于 netfilter 回调函数，类似于 iptables 模式， 但它使用哈希表作为底层数据结构，在内核空间中生效。 这意味着 IPVS 模式下的 kube-proxy 比 iptables 模式下的 kube-proxy 重定向流量的延迟更低，同步代理规则时性能也更好。 与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。

IPVS 为将流量均衡到后端 Pod 提供了更多选择：

• rr（轮询）：流量被平均分发给后端服务器。

• wrr（加权轮询）：流量基于服务器的权重被路由到后端服务器。 高权重的服务器接收新的连接并处理比低权重服务器更多的请求。

• lc（最少连接）：将更多流量分配给活跃连接数较少的服务器。

• wlc（加权最少连接）：将更多流量按照服务器权重分配给连接数较少的服务器，即基于连接数除以权重。

• lblc（基于地域的最少连接）：如果服务器未超载且可用，则针对相同 IP 地址的流量被发送到同一后端服务器； 否则，流量被发送到连接较少的服务器，并在未来的流量分配中保持这一分配决定。

• lblcr（带副本的基于地域的最少连接）：针对相同 IP 地址的流量被发送到连接数最少的服务器。

  • 如果所有后端服务器都超载，则选择连接较少的服务器并将其添加到目标集中。

  • 如果目标集在指定时间内未发生变化，则从此集合中移除负载最高的服务器，以避免副本的负载过高。

• sh（源哈希）：通过查找基于源 IP 地址的静态分配哈希表，将流量发送到某后端服务器。

• dh（目标哈希）：通过查找基于目标地址的静态分配哈希表，将流量发送到某后端服务器。

• sed（最短预期延迟）：流量被转发到具有最短预期延迟的后端服务器。 如果流量被发送给服务器，预期延迟为 (C + 1) / U，其中 C 是服务器上的连接数， U 是服务器的固定服务速率（权重）。

• nq（永不排队）：流量被发送到一台空闲服务器（如果有的话），而不是等待一台快速服务器； 如果所有服务器都忙碌，算法将退回到 sed 行为。