> For the complete documentation index, see [llms.txt](https://bohans.gitbook.io/devops/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bohans.gitbook.io/devops/kubernetes/ji-chu-zhi-shi/service/service-dai-li-mo-shi.md).

# Service代理模式

在Kubernetes集群中，每个节点运行一个<mark style="color:blue;">**kube-proxy**</mark>进程。<mark style="color:blue;">**kube-proxy负责为Service实现一种VIP（虚拟IP）的形式。**</mark>

* 在Kubernetesv 1.0版本中，代理完全是userspace
* 在Kubernetesv 1.1版中新增了**iptables代理**
* 从Kubernetesv 1.2版起，**默认是iptables代理**
* 从Kubernetesv 1.8版开始新增了**ipvs代理**

<mark style="color:orange;">**生产环境建议使用ipvs模式。**</mark>

## iptables代理模式

<mark style="color:orange;">**此代理模式仅适用于 Linux 节点。**</mark>

在这种模式下，<mark style="color:blue;">**kube-proxy 监视 Kubernetes 控制平面，获知对 Service 和 EndpointSlice 对象的添加和删除操作。**</mark>&#x20;

* **对于每个 Service，kube-proxy 会添加 iptables 规则**，这些规则捕获流向 Service 的 clusterIP 和 port 的流量， 并将这些流量重定向到 Service 后端集合中的其中之一。&#x20;
* **对于每个Endpoint，它会添加指向一个特定后端 Pod 的 iptables 规则**。
* **默认情况下，iptables 模式下的 kube-proxy 会随机选择一个后端**。
* **使用 iptables 处理流量的系统开销较低**，因为流量由 Linux netfilter 处理， 无需在用户空间和内核空间之间切换。这种方案也更为可靠。

## **ipvs代理模式**

<mark style="color:orange;">**此代理模式仅适用于 Linux 节点。**</mark>

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

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

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

* <mark style="color:blue;">**rr（轮询）**</mark>：流量被平均分发给后端服务器。
* <mark style="color:blue;">**wrr（加权轮询）**</mark>：流量基于服务器的权重被路由到后端服务器。 高权重的服务器接收新的连接并处理比低权重服务器更多的请求。
* <mark style="color:blue;">**lc（最少连接）**</mark>：将更多流量分配给活跃连接数较少的服务器。
* <mark style="color:blue;">**wlc（加权最少连接）**</mark>：将更多流量按照服务器权重分配给连接数较少的服务器，即基于连接数除以权重。
* <mark style="color:blue;">**lblc（基于地域的最少连接）**</mark>：如果服务器未超载且可用，则针对相同 IP 地址的流量被发送到同一后端服务器； 否则，流量被发送到连接较少的服务器，并在未来的流量分配中保持这一分配决定。
* <mark style="color:blue;">**lblcr（带副本的基于地域的最少连接）**</mark>：针对相同 IP 地址的流量被发送到连接数最少的服务器。&#x20;
  * 如果所有后端服务器都超载，则选择连接较少的服务器并将其添加到目标集中。
  * &#x20;如果目标集在指定时间内未发生变化，则从此集合中移除负载最高的服务器，以避免副本的负载过高。
* <mark style="color:blue;">**sh（源哈希）**</mark>：通过查找基于源 IP 地址的静态分配哈希表，将流量发送到某后端服务器。
* <mark style="color:blue;">**dh（目标哈希）**</mark>：通过查找基于目标地址的静态分配哈希表，将流量发送到某后端服务器。
* <mark style="color:blue;">**sed（最短预期延迟）**</mark>：流量被转发到具有最短预期延迟的后端服务器。 如果流量被发送给服务器，预期延迟为 **(C + 1) / U**，其中 C 是服务器上的连接数， **U** 是服务器的固定服务速率（权重）。
* <mark style="color:blue;">**nq（永不排队）**</mark>：流量被发送到一台空闲服务器（如果有的话），而不是等待一台快速服务器； 如果所有服务器都忙碌，算法将退回到 sed 行为。