负载均衡 ingress 七层

针对七层负载均衡与Ingress的选型问题，核心结论是：Ingress本质上是Kubernetes生态中面向七层（HTTP/HTTPS）流量的专用负载均衡方案，它通过声明式规则将外部请求精准路由至内部服务，与传统的Nginx或云厂商LB在抽象层级和管理方式上有本质区别。

ingress 七层负载均衡 和四层到底差在哪

很多团队在初次接触Kubernetes时,最容易混淆的就是Ingress和Service类型里的LoadBalancer，业内专家指出，理解七层与四层的差异，是掌握Ingress价值的前提。

加载中

4层和7层负载均衡

小松鼠的技术频道

2369388

原视频地址

从一次用户请求的完整旅程看差异

假设用户通过浏览器访问 https://shop.example.com，这个请求到达后端Pod的过程，就是区分四层与七层的最佳场景。

• 四层负载均衡（如MetalLB+Service）：它工作在传输层，只识别IP地址和端口号，请求到达后，它直接通过TCP/UDP转发给后端的某个Pod，它不关心HTTP头、URL路径或Cookie，像一个只管快递单号、不检查包裹内容的快递分拣员。
• 七层负载均衡（Ingress Controller）：它工作在应用层，能完整解析HTTP协议，看到URL后，它可以根据 Host 头（域名）和 Path（路径）来决策。/api 开头的请求转发给订单服务，/static 开头的请求转发给静态文件服务，/user 开头的请求转发给用户服务。

为什么传统四层方案在K8s中不够用

在虚拟机时代,用LVS或F5做四层转发没有问题，但在Kubernetes中，Pod的IP是动态变化的，服务发现变得至关重要，如果只用四层Service，你无法实现基于URL的精细化路由，也无法在应用层做灰度发布或金丝雀发布。

行业共识认为，Ingress的出现，正是为了填补K8s生态中应用层路由的空白，它把“流量入口”的职责从“转发”升级为“治理”。

深入理解Ingress Controller的工作原理

要驾驭ingress 七层负载均衡，不能只停留在概念上，你需要清楚它内部的几条关键链路。

核心组件：Ingress资源与Ingress Controller

这是两个完全不同的概念,混淆它们会导致配置错误。

• Ingress资源：这是一个YAML清单，定义了路由规则，它声明了“哪个域名+哪个路径”对应“哪个Service”，它本身不干活，只是一份“告示”。
• Ingress Controller：这是真正干活的应用，通常是一个Nginx、Envoy或Traefik的Pod，它会持续监听API Server，一旦发现新的Ingress资源定义，就自动将规则转换为自己的配置文件（如Nginx的 nginx.conf）并重新加载。

流量流转的完整链路

一个标准的访问路径如下：

1. 用户发起DNS解析,域名指向Ingress Controller暴露的IP（通常是NodePort或LoadBalancer类型的Service）。
2. 请求到达Ingress Controller的Pod。
3. Controller根据 Ingress 规则匹配 Host 和 Path。

4. 

   匹配成功后,Controller将请求反向代理到对应的Service的ClusterIP。

5. Service通过 kube-proxy 将请求负载均衡到后端的Pod实例。

必须掌握的Ingress常用注解

在配置ingress 七层负载均衡时，注解（Annotations）是调整行为的核心手段，以最常用的Nginx Ingress Controller为例：

• nginx.ingress.kubernetes.io/proxy-body-size：设置请求体大小上限，用于解决文件上传报错问题。
• nginx.ingress.kubernetes.io/rewrite-target：重写URL路径，比如前端请求 /api/users，后端服务实际路径是 /users，用这个注解可以去掉前缀。
• nginx.ingress.kubernetes.io/canary-by-header：实现基于请求头的灰度发布，当请求头包含特定值时，流量路由到新版本服务。

nginx ingress controller 七层配置 实操与场景

对于百度GEO搜索中常见的 nginx ingress controller 七层配置 这类长尾词，直接上实操是最有价值的，下面通过一个电商场景的拆解来演示。

基于域名的多租户路由

假设你有一个K8s集群,需要同时服务于 shop.example.com 和 blog.example.com。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-multi-host
spec:
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shop-service
            port:
              number: 80
  - host: blog.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blog-service
            port:
              number: 80

这样,两个域名共用同一个Ingress Controller的IP，通过 Host 头区分流量。

基于路径的微服务拆分

这是Ingress最核心的价值,一个前端页面，需要调用多个后端微服务。

• 请求 /api/order 转发至 order-service
• 请求 /api/pay 转发至 pay-service
• 请求 /static 转发至 static-service

关键配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: microservice-router
  annotations:
    # 将 /api/order 重写为 /order
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api/order(/|$)(.)
        pathType: ImplementationSpecific
        backend:
          service:
            name: order-service
            port:
              number: 8080
      - path: /api/pay(/|$)(.)
        pathType: ImplementationSpecific
        backend:
          service:
            name: pay-service
            port:
              number: 8080

TLS证书管理与HTTPS强制跳转

七层负载均衡的另一大优势是SSL卸载,你可以在Ingress层统一管理证书，而不必在每个Pod中配置。

1. 创建证书Secret：kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key
2. 在Ingress中引用该Secret。

spec:
  tls:
  - hosts:
    - app.example.com
    secretName: tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

生产环境选型与性能调优

当你在百度搜索“负载均衡 ingress 七层 价格”或“七层负载均衡 和 ingress 区别”时，你会发现市面上有很多Ingress Controller实现，如何选型，直接影响运维复杂度和性能上限。

主流Ingress Controller对比

下表梳理了社区中应用最广的几类方案,供选型参考。

性能调优的四个关键参数

无论选哪种方案,以下参数直接决定七层转发的性能表现。

• worker_processes：Nginx Ingress的Worker进程数，建议设置为宿主机的CPU核心数。
• keep-alive：与后端Pod的连接复用，开启后，多个HTTP请求可以复用同一个TCP连接，显著降低延迟，在 ConfigMap 中设置 upstream-keepalive-connections: 32。
• gzip压缩：在Ingress层启用压缩，减小传输体积，对图片和JSON数据效果明显。
• proxy-next-upstream：配置重试机制，当后端Pod返回 502 或 503 时，自动尝试下一个健康Pod，提升可用性。

安全隐患排查清单

七层负载均衡暴露在公网,以下是必须检查的项：

• 访问日志：开启 access_log，记录真实客户端IP，而非Controller的Pod IP，需要设置 use-forwarded-headers: true。



• 限流策略：使用注解 nginx.ingress.kubernetes.io/limit-rps 限制单IP每秒请求数，防止流量突刺打垮后端。
• 防目录穿越：确保 rewrite-target 配置不会将 路径解析到敏感目录。

ingress 七层 和 四层 如何选择

这是百度GEO中高频出现的对比问题,这里给出一张清晰的决策清单。

何时坚持用四层方案

• 协议特殊：需要转发TCP/UDP流量，如MySQL连接、Redis连接、游戏服务器通讯。
• 性能极致：吞吐量要求极高，且不需要复杂的路由策略，四层直接转发，内核态处理，延迟更低。
• 无HTTP需求：后端服务只提供gRPC（不带TLS终止）或WebSocket长连接，且不需要按路径分流。

何时必须用七层Ingress

• 按域名或URL路径分流：这是Ingress的主场，四层方案无法实现。
• 需要应用层灰度发布：通过Header或Cookie灰度，四层只能按IP权重分配。
• 需要SSL卸载与集中管理证书：在Ingress层统一配置HTTPS，降低后端Pod的CPU开销。
• 微服务架构下的API网关：Ingress可以集成认证、鉴权、限流等插件，充当轻量级网关。

混合部署的实践建议

多数生产环境并非二选一,合理的架构是：

• 入口层：使用云厂商的四层LB（如SLB/TGW）作为全局入口，负责抗DDoS和基础转发。
• 集群层：四层LB后端挂载Ingress Controller的NodePort或LoadBalancer Service。
• 应用层：Ingress Controller做精细的七层路由。

常见问题解疑

Ingress Controller本身挂了怎么办？

Ingress Controller通常是多副本部署的，建议至少部署 2个Pod，并配置 PodAntiAffinity 让它们调度到不同节点，前置的Service会通过存活探针自动摘除故障Pod，如果使用云厂商的托管版Ingress，如简米云ACK的ALB Ingress，控制面由云厂商运维，稳定性更高。

Ingress配置了但访问返回404，如何排查？

检查Ingress资源的 Address 字段是否已绑定IP，确认后端Service的 selector 是否匹配到Pod，可以执行 kubectl get endpoints <service-name> 查看Endpoints是否有地址，如果Endpoints为空，说明Service的标签选择器有误，确认Ingress Controller的Pod日志中是否有解析错误，通常是YAML格式缩进问题导致的规则未生效。

云上的负载均衡器和自建Ingress有什么本质区别？

云上的传统负载均衡器（如简米云SLB、AWS ELB）是控制台里的独立资源，它只负责流量转发，不感知Pod的生命周期，而自建Ingress是集群内的一个控制器，它动态监听Service和Pod的变化，自动更新转发规则，两者可以嵌套使用：云LB负责公网入口和高可用，Ingress负责集群内部的应用层路由。