K8s 中 Ingress 和 LoadBalancer 类型的 Service 是什么关系？

结论：LoadBalancer Service 工作在四层——云厂商为每个这样的 Service 分配一个外部负载均衡器和公网 IP，按 TCP/UDP 转发；Ingress 工作在七层——由集群内的 Ingress Controller（nginx、traefik 等）按 HTTP 主机名/路径路由到多个后端 Service。典型架构是：一个 LoadBalancer Service 暴露 Ingress Controller，多个 Ingress 规则复用这一个入口。

展开：对比要点：1）成本与数量——每个 LoadBalancer Service 一个 LB 实例一份钱，服务多了不划算；Ingress 一层路由规则收敛到单个入口。2）能力——Ingress 做域名/路径路由、TLS 终结、限流、灰度 header 匹配（取决于 controller 注解）；LoadBalancer 只做四层转发，TLS 要么直通要么后端自己终结。3）依赖——Ingress 资源本身只是声明，必须部署 Ingress Controller 才生效（没装 controller 建 Ingress 什么都不会发生）；LoadBalancer 依赖云厂商 CCM 或 MetalLB（裸金属）。演进：Gateway API 是 Ingress 的官方继任者，把入口拆成 GatewayClass/Gateway/HTTPRoute 三层角色（基础设施/平台/应用），表达力和多租户隔离更好。易错点：Ingress 规则匹配的是七层流量，TCP/UDP 服务（数据库、游戏协议）不能用 Ingress 暴露。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service: { name: user-svc, port: { number: 80 } }

追问方向：Ingress Controller 的热更新与 reload 问题（nginx 方案 vs envoy 方案）、Gateway API 的迁移路径。