32. K8s 核心组件讲解——kube-proxy

本章讲解知识点

kube-proxy 概述
工作原理
kube-proxy 的代理模式

<br>

1. kube-proxy 概述

为了支持集群的水平扩展和高可用性，Kubernetes 抽象出了 Service 的概念。Service 是对一组 Pod 的抽象，它会根据访问策略（如负载均衡策略）来访问这组 Pod。

Service 提供了一个稳定的 IP 地址和 DNS 名称，这使得服务可以被客户端通过这些统一的方式访问，服务会将请求转发到后端的 Pod 上。在很多情况下，Service 只是一个概念，而真正将 Service 的作用落实的是它背后的 kube-proxy 服务进程。只有理解了 kube-proxy 的原理和机制，我们才能真正理解 Service 的实现逻辑。我们在 Service 章节中已经详细讲解了利用 Service + kube-proxy + iptables 实现负载均衡，本章再讨论一下 kube-proxy 组件。

<br>

2. 工作原理

Kube-proxy 维护节点上的网络规则，实现了 Kubernetes Service 概念的一部分。它的作用是使发往 Service 的流量（通过 ClusterIP 和端口）负载均衡到正确的后端 Pod。

kube-proxy 监听 API server 中资源对象的变化情况，包括以下三种：

service
endpoint/endpointslices
node

然后根据监听资源变化操作代理后端来为服务配置负载均衡。

如果你的 kubernetes 使用 EndpointSlice，那么 kube-proxy 会监听 EndpointSlice，否则会监听 Endpoint。

<br>

3. kube-proxy 的代理模式

kube-proxy 是 Kubernetes 集群中的一个组件，它实现了 Kubernetes Service 的负载均衡功能

在 Kubernetes 中，kube-proxy 有三种代理模式：

userspace（默认）：kube-proxy 在每个 Node 上通过一个 userspace 进程监听 Service 的 ClusterIP 和端口，将请求通过 NAT 的方式转发到后端 Pod 上。效率最低，不再推荐使用。
iptables：kube-proxy 通过 Linux Kernel 设置 iptables 规则实现 Service 的负载均衡，这种方式效率较高，能够支持大规模集群使用。但是，如果某个后端 Endpoint 在转发时不可用，此次客户端请求就会得到失败的响应，相对于 userspace 模式来说更不可靠。此时应该通过为 Pod 设置 readinessprobe（服务可用性健康检查）来保证只有达到 ready 状态的 Endpoint 才会被设置为 Service 的后端 Endpoint。
ipvs：kube-proxy 通过设置 Linux Kernel 的 netlink 接口设置 IPVS 规则，转发效率和支持的吞吐率都是最高的。ipvs 模式要求 Linux Kernel 启用 IPVS 模块，如果操作系统未启用 IPVS 内核模块， kube-proxy 则会自动切换至 iptables 模式。

同时 ipvs 模式支持更多的负载均衡策略，如下：

轮询（Round Robin，RR）：依次将请求分配到后端服务器，循环往复。
加权轮询（Weighted Round Robin，WRR）：根据服务器的权重分配请求，权重越高的服务器被分配到的请求越多。
最少连接（Least Connections，LC）：将请求分配到当前连接数最少的服务器。
源地址哈希（Source Hashing，SH）：根据请求来源的 IP 地址进行散列，将相同 IP 地址的请求分配到同一台后端服务器上。
永不排队（never queue）

3.1 iptables

从 1.2 版本开始，Kubernetes 将 iptables 作为 kube-proxy 的默认模式，其工作原理如图：

iptables 模式下的第二代 kube-proxy 进程不再起到数据层面的 Proxy 的作用，Client 向 Service 的请求流量通过 iptables 的 NAT 机制直接发送到目标 Pod，不经过 kube-proxy 进程的转发，kube-proxy 进程只承担了控制层面的功能，即通过 API Server 的 Watch 接口实时跟踪 Service 和 Endpoint 的变更信息，并更新 Node 节点上相应的 iptables 规则。