一、负载均衡概念
负载均衡 是一种技术，其核心目标是将网络请求或计算任务分布到多个后端服务器（或称为服务实例、节点）上，以确保：
-
高可用性：避免单点故障。即使某个后端服务器宕机，其他服务器仍能继续提供服务。
-
高并发性：通过水平扩展，利用多台服务器的资源共同处理大量请求，提升系统整体的吞吐量。
-
可扩展性：可以方便地通过增加或减少后端服务器来应对流量高峰或低谷。
可以把负载均衡器想象成一个交通警察，它站在十字路口（服务的入口），将源源不断的车流（网络请求）有序地引导到多条通畅的道路（健康的服务实例）上，避免某一条道路拥堵不堪。
二、常见的负载均衡策略
负载均衡器根据不同的算法来决定将下一个请求分发给哪个后端服务器。
| 策略 | 工作原理 | 适用场景 |
|---|---|---|
| 轮询 | 按顺序将每个新请求依次分配给下一个服务器，循环往复。 | 后端服务器性能相近的简单场景。 |
| 加权轮询 | 在轮询的基础上，为性能更强的服务器分配更高的权重，使其处理更多的请求。 | 后端服务器性能不均（如CPU、内存不同）。 |
| 最少连接 | 将新请求发送给当前活跃连接数最少的服务器。 | 处理请求所需时间长短不一的场景（如有些是长连接，有些是短连接）。 |
| IP哈希 | 根据客户端的IP地址计算出一个哈希值，根据该值将同一客户端的请求总是路由到同一个后端服务器。 | 需要会话保持的场景，如用户登录状态存储在单台服务器上。 |
| URL哈希 | 根据请求的URL路径进行哈希计算，将相同URL的请求定向到同一服务器。 | 希望利用后端服务器缓存，提高缓存命中率。 |
| 随机 | 随机选择一个后端服务器。 | 通常用于测试或作为其他复杂算法的组成部分。 |
三、负载均衡组件：Nginx vs Kube-proxy
这是两种在不同层面、不同场景下工作的负载均衡器，理解它们的区别至关重要。
1. Nginx
-
工作层级 ：主要工作在OSI模型的第7层。
-
角色 ：一个强大的反向代理服务器 和Web服务器。
-
工作原理：
-
作为反向代理，它终结客户端的TCP连接，并代表客户端与后端服务器建立新的连接。
-
因为它能解析应用层协议 ，所以可以根据 HTTP头部信息 、URL路径 、请求方法等做出非常精细的路由决策。
-
例如，可以将
/api/路径的请求路由到一组API服务器，将/images/路径的请求路由到另一组静态文件服务器。
-
-
配置示例（负载均衡）：
nginx
http { upstream my_backend { # 定义后端服务器组 server backend1.example.com weight=3; # 加权轮询 server backend2.example.com; server backend3.example.com down; # 标记为下线 } server { listen 80; location / { proxy_pass http://my_backend; # 将流量代理到后端组 proxy_set_header Host $host; } } } -
主要特点：
-
功能丰富：支持缓存、SSL终结、限流、重写URL、Gzip压缩等。
-
精细化路由：基于HTTP内容的路由能力非常强。
-
性能优秀：事件驱动架构，能处理高并发连接。
-
2. Kube-proxy
-
工作层级 ：工作在OSI模型的第4层。
-
角色 ：Kubernetes Service 资源的网络代理 ，运行在集群的每个节点上。
-
工作原理：
-
它不处理 HTTP协议等应用层细节，只关心 IP地址和端口。
-
它监听Kubernetes API Server，当有 Service 或 Endpoints （后端Pod列表）发生变化时，它就动态地配置节点上的网络规则（如
iptables或ipvs）。 -
当一个Pod想要访问某个Service（如
my-svc）时，请求会被本地的kube-proxy设置的网络规则拦截，并通过一定的负载均衡策略（如随机）转发到该Service对应的一个健康Pod上。
-
-
工作模式：
-
iptables模式（默认）：通过配置大量的iptables规则来实现负载均衡。效率高，但规则多了之后性能会下降，且不支持复杂的调度算法（如最少连接）。
-
IPVS模式：使用Linux内核的IPVS模块，专为负载均衡设计。支持更多调度算法（如rr, wrr, lc, wlc等），性能更好，适合大规模集群。
-
-
主要特点：
-
Kubernetes原生：与Kubernetes Service机制深度集成，是集群内部服务发现的基石。
-
透明代理：对Pod内的应用程序完全透明，应用无需任何修改。
-
工作在传输层：简单高效，但不具备应用层智能路由能力。
-
四、核心对比总结
| 特性 | Nginx | Kube-proxy |
|---|---|---|
| 工作层级 | 主要在第7层 | 第4层 |
| 路由依据 | HTTP头部、URL、Cookie等 | IP地址、端口号 |
| 部署位置 | 通常是集群边缘的独立实例 | 集群每个节点上都运行 |
| 主要角色 | 入口控制器、API网关、反向代理 | Kubernetes Service的代理实现 |
| 配置方式 | 静态配置文件 | 动态监听Kubernetes API |
| 负载均衡算法 | 轮询、加权、IP哈希、最少连接等 | iptables模式主要为随机，IPVS模式支持更多 |
| 典型使用场景 | 对外提供服务的入口流量 | 集群内部服务间的通信 |
五、在现代架构中的协同工作
在实际的Kubernetes生产环境中，Nginx 和 Kube-proxy 常常是协同工作的，它们各司其职：
-
外部用户 -> Nginx Ingress Controller ：用户访问网站，流量首先到达部署在K8s集群边缘的Nginx Ingress Controller。Nginx在这里充当第7层负载均衡器 和API网关 ，根据域名和路径将请求路由到集群内部相应的后端Service。
-
Nginx Ingress -> K8s Service ：Nginx将请求发送到某个Service的虚拟IP。
-
K8s Service -> Pod ：
kube-proxy在节点上设置的网络规则生效，将到达Service VIP的请求，通过第4层负载均衡 ，最终转发到一个具体的、健康的 Pod 上。
简单来说：Nginx（作为Ingress）负责"外交"，处理来自集群外的复杂请求；而Kube-proxy负责"内政"，管理集群内部服务之间简单高效的通信。