企业级K8s集群两层Nginx架构实战：Ingress Controller独立部署与动态伸缩全解析

在ERP、OA等企业级多Web应用场景中，K8s集群的入口流量架构设计直接决定系统稳定性、可扩展性和安全性。本文结合实际项目经验，详细拆解"外层Nginx负载均衡+内层独立Ingress Controller"架构的设计逻辑、职责划分、动态伸缩实现及完整配置方案，适用于中大型企业多业务隔离场景。

一、架构核心认知：两层Nginx并非重复设计

很多同学会疑惑：外层已部署Nginx负载均衡，为何还要在K8s集群内部署Nginx Ingress Controller？二者本质是互补协作关系，核心差异体现在工作层级、部署位置和职责范围，绝非功能重复。

1.1 架构整体链路

用户请求流转路径：用户 → 公网域名 → 外层Nginx（集群外） → 内层Ingress Controller（集群内Pod） → 业务Service → 业务Pod

该架构通过分层解耦，实现流量接入、路由转发、安全防护的精细化管控，完全适配企业级多应用场景需求。

1.2 两层Nginx核心差异对比

外层Nginx与内层Nginx Ingress Controller虽同为Nginx，但定位、能力、使用场景完全不同，核心差异可通过下表清晰区分，兼顾运维交底与架构设计参考：

对比维度	外层Nginx（集群外负载均衡）	内层Nginx Ingress Controller（集群内）
工作层级	TCP/IP四层（传输层），仅识别IP和端口，不解析HTTP请求头、域名、路径等应用层内容。	HTTP/HTTPS七层（应用层），深度解析请求中的域名、URL路径、Cookie、请求头，支持基于这些信息做路由转发。
部署位置	K8s集群外部，通常部署在公网与集群之间，作为流量进入集群的第一道关口，可是物理机、虚拟机或云厂商SLB。	K8s集群内部，以Pod形式运行，受K8s调度管理，可依托K8s实现自动扩缩容、故障自愈。
核心职责	1. 公网IP与域名绑定，统一接入入口；2. SSL证书卸载，集群内统一走HTTP，减少重复加密损耗；3. 基础安全防护（IP黑白名单、防CC攻击、简单WAF）；4. 全局限流，防护整个集群免受突发流量冲击；5. 分发流量至内层多个Ingress Controller，保障Ingress层高可用。	1. 监听K8s Ingress资源，动态生成路由规则；2. 基于域名/路径转发至对应业务Service，实现应用级路由；3. 业务级精细化控制（路径重写、请求头修改、会话保持、灰度发布）；4. 依托K8s Service实现后端Pod服务发现，无需手动维护Pod IP；5. 针对单个应用做细粒度限流、错误页面自定义等。
配置管理	静态配置，需通过Ansible、SaltStack或配置中心（如Nacos）手动推送更新，修改后需重载Nginx生效。	动态配置，实时监听K8s API Server，当Ingress、Service、Pod资源变化时，自动更新内部Nginx配置，无需人工干预。
高可用实现	多实例部署+VIP漂移（如Keepalived），或依赖云厂商SLB的天然高可用能力，避免入口单点故障。	多Pod部署+K8s反亲和性配置，确保Pod分散在不同节点，配合K8s自愈能力，Pod故障后自动重启重建。
适用场景	集群全局入口管控，负责流量接入、安全防护、全局负载，适配多集群、混合云场景的统一入口需求。	集群内应用路由分发，适配多应用隔离、动态扩缩容、精细化流量控制的企业级业务需求。

通过上述差异可见，两层Nginx各司其职、层层互补，既避免了功能重叠，又实现了流量接入、路由转发、安全防护的全链路管控，共同构成企业级K8s集群的高可用入口架构，为后续多应用独立Ingress部署奠定基础。

二、多应用独立Ingress Controller设计意义

在企业K8s集群中，为每个Web应用部署独立Ingress Controller且多Pod运行，是经过实践验证的高可用设计，核心价值体现在四大维度：

2.1 业务隔离，规避"一损俱损"风险

不同应用的Ingress Controller完全独立部署在专属命名空间，实现三重隔离：

• 故障隔离：某应用Ingress配置错误或流量突增，仅影响自身，不扩散至ERP、OA等核心业务。

• 资源隔离：为核心业务（如ERP财务模块）分配更高CPU、内存资源，避免非核心业务挤占资源。

• 配置隔离：每个应用的路由规则、限流策略、灰度配置独立管理，无规则冲突风险。

2.2 多Pod部署，消除单点故障

单Pod部署的Ingress Controller存在明显单点风险，多Pod部署结合K8s反亲和性配置，可实现：

• 流量自动分发：外层Nginx将流量转发至多个Ingress Pod，单个Pod故障时，请求自动切换至健康实例。

• 节点级容灾：通过反亲和性将Pod调度至不同节点，避免节点故障导致整个应用Ingress服务不可用。

2.3 灵活扩展，适配业务流量波动

企业应用流量存在明显峰值（如ERP月末结账、电商促销），独立Ingress Controller支持：

• 独立扩缩容：仅针对高负载应用的Ingress Controller扩容，无需影响其他应用，资源利用率更高。

• 定制化优化：针对不同应用特性调整配置（如静态资源应用开启缓存，API服务优化连接复用）。

2.4 安全合规，满足企业管控要求

金融、制造等行业对系统安全合规要求较高，该设计可实现：

• 权限隔离：为每个Ingress Controller绑定专属ServiceAccount，限制对K8s API的访问权限，降低安全风险。

• 审计追溯：独立的Ingress访问日志，可清晰追溯每个应用的访问行为，满足合规审计需求。

三、动态伸缩关键：外层Nginx如何发现Ingress Pod

Ingress Controller动态扩缩容时，外层Nginx需自动感知Pod新增/下线，无需人工修改配置。推荐采用K8s Service + 反向代理方案，无需额外引入组件，适配企业单集群多应用场景。

3.1 实现原理

核心依赖K8s Service的自动发现能力：

1. 为每个Ingress Controller创建专属Service，通过Label Selector关联对应Pod。

2. Service自动维护后端Endpoints列表，Ingress Pod扩缩容时，Endpoints实时更新。

3. 外层Nginx仅需转发流量至Service的固定ClusterIP，由Service完成Pod负载均衡。

推荐使用Headless Service（clusterIP: None），外层Nginx可直接解析Pod IP，减少转发层级，提升性能。

3.2 完整配置实操（以ERP订单模块为例）

以下配置可直接复制部署，实现Ingress Controller独立部署、多Pod运行及动态伸缩，适配企业生产环境。

3.2.1 命名空间创建（业务隔离必备）

创建ERP订单模块专属命名空间，避免资源冲突：

# erp-order-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: erp-order  # 订单模块专属命名空间
  labels:
    app: erp-order

3.2.2 Ingress Controller Deployment配置

管理Ingress Pod生命周期，支持动态扩缩容，配置中重点标注企业级优化项：

# erp-order-ingress-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: erp-order-ingress-controller
  namespace: erp-order
spec:
  replicas: 2  # 初始2个Pod，可动态调整
  selector:
    matchLabels:
      app: erp-order-ingress-controller  # 关联Service的核心标签
  template:
    metadata:
      labels:
        app: erp-order-ingress-controller
    spec:
      containers:
      - name: nginx-ingress-controller
        image: k8s.gcr.io/ingress-nginx/controller:v1.9.6  # 官方稳定版镜像
        args:
          # 仅监听本命名空间Ingress资源，实现多应用隔离
          - --watch-namespace=erp-order
          # 关联Service，确保Ingress规则正确生效
          - --publish-service=$(POD_NAMESPACE)/erp-order-ingress-service
          - --log-level=info  # 生产环境建议info级别
          # ERP长连接优化，适配大文件上传/报表导出
          - --proxy-connect-timeout=60s
          - --proxy-read-timeout=300s
        resources:
          # 资源限制，按业务负载调整
          limits:
            cpu: 1000m
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 512Mi
        ports:
        - name: http
          containerPort: 80
        - name: https
          containerPort: 443
        # 健康检查，异常Pod自动重启
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /healthz
            port: 10254
          initialDelaySeconds: 5
          periodSeconds: 5

3.2.3 Ingress Controller Service配置

创建Service为Ingress Pod提供固定入口，自动感知Pod变化：

# erp-order-ingress-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: erp-order-ingress-service
  namespace: erp-order
spec:
  selector:
    app: erp-order-ingress-controller  # 与Deployment标签一致
  type: ClusterIP  # 集群内访问，外层Nginx通过ClusterIP转发
  ports:
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP
  # 如需HTTPS，启用以下配置
  # - name: https
  #   port: 443
  #   targetPort: 443
  #   protocol: TCP

3.2.4 外层Nginx对接配置

外层Nginx只需对接Service的固定ClusterIP，无需关心Pod数量，配置如下：

# 外层Nginx配置（erp-order.conf）
http {
    upstream erp_order_ingress_cluster {
        server 10.96.100.10:80;  # 替换为实际Service ClusterIP
        keepalive 32;  # 开启连接复用，提升性能
    }

    server {
        listen 80;
        server_name order.erp.wolfcode.cn;  # 订单模块公网域名

        location / {
            proxy_pass http://erp_order_ingress_cluster;
            # 传递真实IP和域名，便于业务日志溯源
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            # 适配ERP长请求场景
            proxy_connect_timeout 60s;
            proxy_read_timeout 300s;
        }
    }
}

3.2.5 部署与动态扩缩容测试

# 1. 部署Ingress Controller
kubectl apply -f erp-order-ingress-deployment.yaml

# 2. 创建Service
kubectl apply -f erp-order-ingress-service.yaml

# 3. 查看Service ClusterIP（替换外层Nginx配置）
kubectl get svc erp-order-ingress-service -n erp-order

# 4. 扩容至5个Pod
kubectl scale deployment erp-order-ingress-controller -n erp-order --replicas=5

# 5. 验证Pod状态
kubectl get pods -n erp-order

# 6. 查看Service关联的Pod（Endpoints）
kubectl describe svc erp-order-ingress-service -n erp-order

四、企业级优化与避坑指南

4.1 避免功能重叠，减少性能损耗

• SSL卸载：仅在外层Nginx处理HTTPS证书，集群内流量用HTTP传输，避免重复加密解密。

• 限流分层：外层做全局限流（防护集群），内层做业务级限流（精准控制单应用）。

4.2 简化配置维护，降低运维成本

• 外层Nginx：用Ansible或配置中心管理静态配置，批量同步更新。

• 内层Ingress：完全通过K8s Ingress资源定义路由规则，实现配置动态更新。

4.3 性能优化，适配企业高负载场景

• 外层Nginx：开启连接复用、Gzip压缩、缓存静态资源，提升访问速度。

• Ingress Controller：调整worker进程数匹配宿主机CPU核心数，优化连接超时时间适配ERP长连接。

4.4 监控告警，提前发现问题

• 外层Nginx：监控公网入口QPS、延迟、错误率，告警异常流量攻击。

• Ingress Controller：监控各应用转发延迟、Pod健康状态，告警Pod扩缩容异常。

五、总结

"外层Nginx负载均衡+内层独立Ingress Controller"架构，通过分层解耦、业务隔离、动态伸缩设计，完美适配企业级多Web应用的稳定性、安全性和可扩展性需求。核心在于明确两层Nginx的职责边界，依托K8s Service实现Ingress Pod的自动发现，无需额外组件即可满足生产环境需求。

该架构已在多个ERP项目中落地验证，能够有效支撑业务迭代和流量波动，同时降低运维复杂度，适合中大型企业K8s集群长期演进。