Kubernetes实现负载均衡

一、核心区别与容器化后的变化

维度	Node 集群模式	Nginx	Kubernetes（容器化编排）
资源扩展单位	单机多进程	跨机器的反向代理	Pod（最小调度单位，单容器或多边车容器）
弹性伸缩	手动调整进程数（依赖 PM2 等工具）	手动配置后端服务器列表	**HPA（Horizontal Pod Autoscaler）**自动扩缩容
服务发现	无（单机内进程固定）	需手动维护后端服务地址	通过 Service 自动发现动态 Pod IP
健康检查	依赖进程守护工具（如 PM2 重启崩溃进程）	主动探测后端服务存活状态	Liveness/Readiness Probes 自动检测容器状态
部署粒度	单机进程级	服务器级	容器级（跨主机、跨可用区调度）

---

二、Kubernetes 如何替代或增强原有角色

1. 替代 Node 集群模式

• 传统 Node 集群：单机启动多进程，利用多核。
• Kubernetes 方案：
  • 每个 Node.js 应用打包为独立容器（单进程），由 Kubernetes 启动多个 Pod 副本（如 replicas: 8）。
  • 优势：
    • 跨节点扩展：Pod 可分布在不同物理节点，避免单机故障。
    • 资源隔离：每个容器有独立 CPU/内存限制（通过 resources.limits）。
    • 自动化运维：崩溃的 Pod 由 K8s 自动重启或重建（无需 PM2）。

2. 替代 Nginx 反向代理

• 传统 Nginx：手动配置 upstream 指向后端服务器。
• Kubernetes 方案：
  • Service：通过 ClusterIP 或 NodePort 暴露 Pod 组，提供内部负载均衡（默认轮询）。
  • Ingress：替代 Nginx 的七层代理，支持 HTTPS、路由规则（如 Nginx Ingress Controller）。
  • 优势：
    • 动态服务发现：Service 自动关联 Pod，无需手动维护 IP。
    • 高级路由：通过 Ingress 实现路径分流、金丝雀发布等。

---

三、Kubernetes 架构下的协作模式

典型分层架构：

客户端 → Ingress (Nginx Controller) → Service → [Pod 1 (Node.js 容器)]  
                                      Service → [Pod 2 (Node.js 容器)]  
                                      Service → [Pod N...]

1. 替代 Node 集群的场景

• 单进程容器：每个 Pod 运行一个 Node.js 进程（遵循容器单进程最佳实践）。
• 多副本负载均衡：通过 replicas: 4 启动多个 Pod，由 Service 实现跨节点负载均衡。
• 资源优化：K8s 调度器将 Pod 分散到不同节点，避免单机资源争抢。

2. 替代 Nginx 的场景

• Service：提供四层负载均衡（TCP/UDP），替代 Nginx 的 upstream 配置。
• Ingress Controller：
  • 使用 Nginx Ingress Controller 实现七层代理（兼容原有 Nginx 功能）。
  • 支持自动生成 Nginx 配置（根据 Ingress 资源定义）。

---

四、关键功能对比（结合 Kubernetes）

功能	Node 集群模式	Nginx	Kubernetes 方案
负载均衡范围	单机多进程	跨物理机	跨节点、跨可用区（Pod 全局调度）
扩展性	手动调整进程数	手动添加服务器	HPA 自动扩缩（基于 CPU/内存或自定义指标）
高可用性	单机故障导致服务终止	依赖后端多服务器	自愈系统（自动迁移故障 Pod 到健康节点）
SSL 终止	需应用层处理	在 Nginx 配置证书	Ingress 统一管理 TLS（自动证书续签）
会话保持	需外部存储	通过 ip_hash 或 sticky 模块	通过 Service 的 sessionAffinity: ClientIP

---

五、最佳实践：Kubernetes 中的 Node.js 高并发架构

1. 容器化单进程：每个 Pod 运行一个 Node.js 进程（替代 Cluster 模式的多进程）。
2. 水平扩展：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs-app
spec:
  replicas: 4  # 根据 HPA 自动调整
  template:
    spec:
      containers:
      - name: nodejs
        image: your-nodejs-image
        resources:
          limits:
            cpu: "1"  # 限制单容器 CPU

3. 流量入口：
   • 使用 Nginx Ingress Controller 处理 HTTPS 和路由规则。
   • 配置 Ingress 实现路径分流（如 /api 到后端 Service）。
4. 服务发现：
   • 通过 Service 的 DNS 名称（如 http://nodejs-svc:3000）内部通信。
5. 监控与自愈：
   • 配置 livenessProbe 检测容器健康状态。
   • 使用 Prometheus + Grafana 监控 QPS 和延迟，触发 HPA 扩缩容。

---

六、总结：三者的角色演变

• Node 集群模式：在容器化中逐渐被弃用，转为依赖 K8s 多 Pod 副本。
• Nginx：在 K8s 中退化为 Ingress Controller（专注七层代理），而非核心负载均衡器。
• Kubernetes：
  • 通过 Service 和 Ingress 接管负载均衡。
  • 通过 Pod 副本 和 HPA 实现弹性扩展，彻底解决单机限制。
  • 通过 声明式配置 实现基础设施即代码（IaC），简化运维。