K8s 运维系列 | 第 19 天：流量治理——Ingress Controller 与 Gateway API

引言

在 Kubernetes 中，当你的应用由一个个 Pod 组成、通过 Service 对外暴露端口之后，真正的挑战才刚刚开始：如何优雅地把外部流量接入集群？如何基于域名和路径做路由？如何统一管理 TLS 证书、灰度发布、限流与重试？这一系列问题，正是「流量治理」要解决的核心命题。

在早期的 Kubernetes 中，最常用的做法是 Ingress + Ingress Controller。它用一条条规则描述「哪个域名、哪条路径，转发到哪个 Service」，再由控制器把规则翻译成 Nginx、Traefik、HAProxy 等实际代理的配置。而随着云原生场景越来越复杂，Ingress 的局限性逐渐暴露——不同厂商的实现差异巨大、缺少标准化的流量切分与跨命名空间协作能力，于是 Gateway API 应运而生，成为下一代流量治理的事实标准。

今天这一篇，我们从 Ingress 讲到 Gateway API，把 Kubernetes 流量治理的来龙去脉、实战配置和常见问题一次讲透。

核心概念

1. Ingress 与 Ingress Controller 的关系

很多人一开始会混淆这两个概念。Ingress 只是一个「规则对象」，它本身不干活；真正把流量转进集群的，是 Ingress Controller。

Ingress：一种 API 资源，声明式的描述路由规则。
Ingress Controller：一个常驻的控制器程序（通常是反向代理），监听 Ingress 资源变化并动态刷新配置。

常见的关系可以这样理解：Ingress 是「图纸」，Ingress Controller 是「施工队」。

2. Gateway API 是什么

Gateway API 是 Kubernetes SIG-Network 推出的新一代流量治理规范，它的核心思路是把「角色」拆开：

GatewayClass：定义用哪一类网关实现（相当于 Ingress Controller 的抽象）。
Gateway：实际部署出来的网关实例，监听某个端口。
HTTPRoute / TCPRoute / TLSRoute：具体的路由规则，与 Gateway 解耦。

这种分层设计让「基础设施团队」和「应用团队」可以各司其职：平台侧负责搭建 Gateway，业务侧只需要声明自己需要的 Route。

实战步骤

步骤一：部署 Nginx Ingress Controller

先来部署最主流的 Nginx Ingress Controller。这里以 Helm 方式为例：

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx 
  --namespace ingress-nginx 
  --create-namespace 
  --set controller.service.type=LoadBalancer

部署完成后，验证一下控制器 Pod 是否正常运行：

kubectl get pods -n ingress-nginx
kubectl get svc -n ingress-nginx

步骤二：编写 Ingress 规则

假设我们有一个应用 webapp，暴露在 80 端口，现在要把它绑定到域名 demo.example.com：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: demo.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp
                port:
                  number: 80

应用后，配置本地 DNS 指向集群入口 IP，就能通过 demo.example.com 访问到服务了：

kubectl apply -f webapp-ingress.yaml
curl -H "Host: demo.example.com" http://<INGRESS_IP>/

步骤三：配置 TLS 证书

生产环境离不开 HTTPS。先用 cert-manager 自动签发证书，再在 Ingress 里引用：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-tls
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - demo.example.com
      secretName: demo-tls
  rules:
    - host: demo.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp
                port:
                  number: 80

步骤四：用 Gateway API 做流量切分

相比 Ingress，Gateway API 在做金丝雀发布时更加优雅。下面是一个把 90% 流量导向稳定版、10% 导向金丝雀版的例子：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: webapp-route
spec:
  parentRefs:
    - name: my-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: webapp-stable
          port: 80
          weight: 90
        - name: webapp-canary
          port: 80
          weight: 10

可以看到，Gateway API 通过 weight 字段就能直观地表达流量权重，而不再需要依赖各厂商私有的注解（annotation）。

常见问题

问题一：Ingress 配置了但始终 404

最常见的原因是 ingressClassName 与已部署的控制器不匹配。可以通过下面的命令确认控制器的 IngressClass 名称：

kubectl get ingressclass

如果控制器是在旧版本部署的，可能还在用 kubernetes.io/ingress.class 注解，两者保持一致即可。

问题二：Service 端口与容器端口不对应

Ingress 里的 port.number 指的是 Service 的端口，而不是 Pod 里容器的端口。如果 Service 对外是 8080，而容器监听 80，那么在 Ingress 里必须写 8080，否则会出现 502 或 connection refused。

问题三：多租户下路由互相干扰

Ingress 默认所有规则都打到同一个控制器上，不同团队之间容易冲突。Gateway API 的 allowedRoutes 配合命名空间隔离，可以限制哪些命名空间的 Route 能挂载到某个 Gateway 上，从机制上避免互相干扰。

总结

流量治理是 Kubernetes 生产中绕不开的一环。Ingress + Ingress Controller 目前仍然是使用最广泛、生态最成熟的方案，适合大多数中小规模场景；而 Gateway API 凭借角色分离、流量权重、标准化等优势，正在成为下一代默认选择，尤其适合多团队、多集群的平台级架构。

在实际落地时，建议你：先用 Ingress 快速打通链路，理解域名、路径、TLS 的完整闭环；再逐步引入 Gateway API，把流量治理能力沉淀到平台层。下一篇，我们将进入服务网格的世界，看看 Istio 如何在更细的粒度上做流量管理与可观测性。