2. Ingress 控制器基础回顾：Ingress 资源定义、Ingress Controller 工作原理、常见 Controller 对比

2.1 Ingress 资源定义

Ingress 是 Kubernetes 原生的 API 资源，用于定义集群外部流量如何路由到集群内部 Service。它本质上是七层（HTTP/HTTPS）路由规则的声明式描述，不包含任何网络监听或转发逻辑。

一个标准的 Ingress 资源定义包含以下关键字段：

以下是一个完整的 Ingress 资源示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

2.2 Ingress Controller 工作原理

Ingress Controller 是一个运行在集群中的 Pod，它持续监听 Kubernetes API Server 中的 Ingress、Service、Endpoint 和 Secret 资源变化，并将这些声明式规则转换为实际的反向代理配置。

其核心工作流程包含以下四个步骤：

1. 资源监听：Controller 通过 Informer 机制监听 Ingress 及相关资源的事件（Add/Update/Delete）。
2. 配置生成：将监听到的 Ingress 规则转换为目标代理软件（如 Nginx、Traefik、HAProxy）的配置文件。
3. 配置生效：将生成的配置文件写入 Pod 内部，并触发代理进程的热重载（Reload）或动态更新。
4. 流量转发：代理进程根据最新配置，将外部请求按域名和路径规则转发至对应的后端 Service Pod。

下图展示了 Ingress Controller 的核心工作流程：

2.3 常见 Ingress Controller 对比

社区中最主流的三种 Ingress Controller 分别是 Nginx Ingress Controller、Traefik 和 HAProxy Ingress。它们在性能、功能、配置方式和生态集成上各有侧重。

下图展示了三种 Controller 在配置更新方式上的核心差异：

2.4 升级场景下的关键考量

在集群升级过程中，Ingress Controller 的稳定性直接影响业务可用性。以下是三个必须关注的维度：

• API 版本兼容性：确认 Ingress Controller 版本支持的 Kubernetes API 版本。例如，Nginx Ingress Controller v1.0+ 才支持 networking.k8s.io/v1。
• 热重载与连接中断：Nginx 和 HAProxy 的热重载会短暂中断长连接（WebSocket、gRPC）。升级前需评估业务是否容忍秒级中断。
• 可观测性配置迁移：升级后需验证 Prometheus 指标、访问日志格式、链路追踪 Header 注入是否正常，避免监控盲区。