Nginx负载均衡实战：在容器化K8s环境下的入口配置-Nginx-PHP中文网

kubernetes中真正的负载均衡由ingress控制器（如nginx-ingress-controller）实现，而非手动部署nginx pod；需正确配置ingress资源、clusterip service及控制器部署参数（如daemonset、hostnetwork、externaltrafficpolicy: local），并结合路径路由、tls、可观测性等最佳实践。

nginx负载均衡实战：在容器化k8s环境下的入口配置

在Kubernetes中，Nginx本身不直接作为负载均衡器运行在集群内——真正承担入口流量分发的是Ingress控制器（如nginx-ingress-controller），它基于Nginx构建，但由K8s统一调度和配置。要实现可靠的负载均衡，关键不是手动部署Nginx容器，而是正确配置Ingress资源、后端Service以及Ingress Controller的部署参数。

明确角色分工：Ingress ≠ Nginx Pod

很多人误以为“在K8s里用Nginx做负载均衡”就是自己写个nginx.conf、打包成镜像、再起一个Deployment。这不仅绕过K8s服务发现机制，还丢失健康检查、自动重载、TLS终止等核心能力。正确路径是：

部署官方维护的ingress-nginx控制器（推荐使用kubernetes/ingress-nginx）
通过Ingress资源声明路由规则（host/path → Service）
后端Service类型设为ClusterIP，由Ingress控制器自动完成Endpoints发现与负载分发

Ingress Controller部署要点

以裸机或私有云环境为例，需确保控制器具备真实负载能力：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

使用DaemonSet或带hostNetwork: true的Deployment，让Pod直接绑定宿主机端口（如80/443）
添加tolerations和nodeSelector，确保调度到专用边缘节点（避免业务Pod抢占资源）
启用externalTrafficPolicy: Local（Service层面），保留客户端真实IP，避免SNAT
通过ConfigMap定制Nginx行为，例如调整upstream keepalive、超时、缓冲区大小

Ingress资源配置实战

一个典型多域名+路径路由示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - api.example.com
      - web.example.com
    secretName: example-tls
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1/(.*)
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080
  - host: web.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 3000

注意：pathType必须显式指定（Prefix/Exact/ImplementationSpecific），K8s 1.22+已弃用旧写法；rewrite-target用于路径重写，避免后端应用感知原始路径前缀。

可观测性与调优建议

生产环境不能只靠“能通”，还需验证负载是否真实均匀：

查看Ingress Controller日志：kubectl logs -n ingress-nginx deploy/ingress-nginx-controller，关注5xx和upstream响应时间
检查Endpoints同步状态：kubectl get endpoints <service-name></service-name>，确认数量与Pod就绪数一致
开启Prometheus指标（默认暴露在:10254/metrics），重点关注nginx_ingress_controller_requests_total和nginx_ingress_controller_upstream_latency_seconds
对高并发场景，适当调大worker_processes和worker_connections（通过ConfigMap中的worker-processes和max-worker-connections）