Kubernetes Ingress：统一入口的核心机制解析

在 Kubernetes 中部署多个服务后，通常会遇到如何对外提供访问入口的问题。
ClusterIP、NodePort、LoadBalancer 都可以使用，但在服务数量增多后，这几种方式会带来一定的负担。
Ingress 的出现，正是为了解决外部访问入口分散、成本高、路由能力不足等问题。

本文从实践角度出发，整理 Ingress 的定位、工作方式及常见使用方式。

---

1. Ingress 的角色与定位

Ingress 是一个描述 HTTP/HTTPS 访问规则的 Kubernetes 资源。
它的主要作用是：将多个内部服务通过一个统一的入口暴露出去，并根据条件（路径、域名等）完成路由。

需要特别注意的是：

• Ingress 本身不处理任何流量
• 实际转发请求的是 Ingress Controller

换句话说：

Ingress 负责“写规则”，
Ingress Controller 负责“执行规则”。

---

2. 为什么需要 Ingress？

在没有 Ingress 的场景中，一般有以下方式暴露服务：

• 每个服务一个 NodePort
• 或者每个服务一个 LoadBalancer

当服务数量多时，这种方式会让：

• 端口分配困难
• 维护复杂
• 成本上升（多 LB）
• 无法按路径/域名细分路由

Ingress 提供解决方案：

• 对外使用单一入口
• 在入口内部通过七层规则路由到不同服务
• 更容易管理域名、路径、证书等配置

因此，Ingress 是 Kubernetes 中最常用、也是最具扩展性的 HTTP 入口方式。

---

3. Ingress 与 Ingress Controller 的关系说明

仅创建 Ingress 资源并不会让服务自动暴露。
必须安装并运行 Ingress Controller，它负责：

• 监听 Ingress 配置变化
• 动态生成网关配置
• 接收并处理真实网络流量

常见实现包括：

• Nginx Ingress Controller（使用最广）
• Traefik
• HAProxy
• Kong
• Istio Gateway（使用 Gateway API）

因此，Ingress 是标准；Controller 是实现。

---

4. 工作机制（Mermaid 图示）

下面是 Ingress 的典型工作流程，通过 Mermaid 进行展示：

从图上可以看到几个关键点：

• 外部流量会先进入 LB 或节点端口
• Controller 作为统一入口，根据 Ingress 规则进行分发
• 规则变化会被 Controller 动态监听并更新配置

---

5. 一个典型的 Ingress 配置示例

假设有两个服务分别处理 API 和用户信息，可以通过一个 Ingress 暴露：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: service-a
            port:
              number: 80
      - path: /user
        pathType: Prefix
        backend:
          service:
            name: service-b
            port:
              number: 80

访问方式：

• https://www.example.com/api/... → Service A
• https://www.example.com/user/... → Service B

这是 Ingress 最常用的模式之一。

---

6. Ingress 的常见功能场景

1. 基于路径的路由

不同 URL 前缀对应不同服务。

2. 基于域名的虚拟主机

多个域名共用一个入口。

3. HTTPS 管理

Ingress 支持加载 TLS Secret，也能配合 cert-manager 自动完成证书签发。

4. 扩展性的反向代理能力

由 Controller 提供，例如：

• 超时控制
• 限流
• Path 重写
• Header 调整
• WAF（某些实现提供）

Ingress 只负责定义接口，能力由 Controller 决定。

---

7. 常见误区

在实际教学和生产中，几个误解经常出现：

误区 1：Ingress 就是 Nginx
实际是 Ingress Controller 可以选 Nginx，但并非强绑定。

误区 2：只要创建 Ingress 就能访问服务
必须要安装 Ingress Controller 才行。

误区 3：Ingress 等同于 LoadBalancer
LoadBalancer 是四层（TCP/UDP），Ingress 工作在七层（HTTP/HTTPS）。

---

8. 与 Gateway API 的关系

当前 Kubernetes 社区正在推动 Gateway API，它提供更现代、更细粒度的流量治理能力。
Gateway API 与 Ingress 并不冲突，你可以理解为：

• Ingress 简单、稳定、适合大多数 HTTP 场景
• Gateway API 功能更丰富，适合更复杂的服务网格或大型架构

目前 Ingress 在生产环境中仍然广泛使用。

---

9. 实际生产中的一些建议

为了确保 Ingress 稳定运行，可以参考以下做法：

• 使用成熟的 Nginx Ingress Controller
• 搭配 cert-manager 管理证书
• 默认使用 pathType: Prefix
• 为 Controller 设置合理的资源限制
• 配置超时和限流，避免入口在流量高峰时失去响应
• 将公共路由配置模块化，避免多个 Ingress 文件重复定义

---

10. 总结

Ingress 是 Kubernetes 中处理 HTTP/HTTPS 流量的核心组件，重点在于：

1. 通过统一入口管理多个服务
2. 提供基于七层协议的路由能力
3. 由 Ingress Controller 完成实际的流量转发