Ingress 详解：Kubernetes 集群的"智能交通指挥中心"

This article is extracted from the chat log with AI. Please identify it with caution.

AI 协助说明： 本页由 Codex 协助核验和修复站内链接；正文的技术事实和适用范围未因本次修改而改变，仍以文中来源及当前官方文档为准。

本文边界：本文聚焦 Ingress 资源、Ingress Controller 与 HTTP/HTTPS 路由；TLS 证书的签发、续期及 cert-manager 协作请阅读配套专题。

推荐深读：Kubernetes Ingress、证书与 cert-manager 总结。

什么是 Ingress？#

Ingress 是 Kubernetes 中的一种API 资源对象，它定义了如何从集群外部访问集群内服务的规则。简单来说，Ingress 是 Kubernetes 集群的入站流量管理器，负责将外部 HTTP/HTTPS 请求路由到集群内部的相应服务。

与 Service 不同，Ingress 不是简单的网络代理，而是一个智能路由系统，提供基于路径、主机名的路由，SSL 终止，负载均衡等高级功能。

Ingress 在 Kubernetes 中的核心角色#

1. 外部访问的"统一入口"#

在没有 Ingress 的情况下，暴露多个应用到集群外部需要为每个应用创建一个 LoadBalancer Service，这会导致：

  • 每个服务都需要一个公共 IP 地址（成本高）
  • 无法实现基于路径/域名的路由
  • 缺乏集中式的认证和安全策略

Ingress 通过单一入口点解决这些问题，将所有外部流量通过统一入口，再根据规则分发到不同服务。

2. 应用层路由的"决策中心"#

Ingress 工作在 OSI 模型的第7层（应用层），能够理解 HTTP/HTTPS 协议内容，实现：

  • 基于 URL 路径的路由（/api → backend, /static → frontend）
  • 基于主机名的路由（app.example.com → 应用A, admin.example.com → 应用B）
  • 智能负载均衡（会话亲和性、加权路由等）

3. 安全与优化的"网关"#

Ingress 通常提供一系列网关功能：

  • SSL/TLS 证书管理与终止
  • 请求重写和重定向
  • 身份验证和授权
  • 速率限制
  • Web 应用防火墙 (WAF) 集成

Ingress 的核心组件#

1. Ingress 资源（Ingress Resource）#

定义路由规则的 YAML 配置文件，包含：

  • 主机名规则（host）
  • 路径规则（path）
  • 后端服务（service）
  • TLS 配置
  • 注解（annotations）用于特定 Ingress Controller 的扩展功能

2. Ingress Controller#

实现 Ingress 规则的实际组件，负责：

  • 监听 Kubernetes API 中的 Ingress 资源变化
  • 将规则转换为具体配置（如 Nginx 配置文件）
  • 重新加载配置以应用更改
  • 处理实际流量路由

常见 Ingress Controller：

  • Nginx Ingress Controller
  • Traefik
  • HAProxy
  • GCE Ingress Controller (Google Cloud)
  • ALB Ingress Controller (AWS)
  • Azure Application Gateway Ingress Controller

3. Ingress Rules#

定义流量路由逻辑的具体规则，支持：

  • 基于主机的路由
  • 基于路径的路由
  • 默认后端（处理未匹配的请求）
  • 服务权重（金丝雀发布）

Ingress 工作流程（简化版）#

graph LR
A[客户端请求] --> B[Ingress Controller]
B --> C{匹配 Ingress Rules}
C -->|匹配规则1| D[服务A]
C -->|匹配规则2| E[服务B]
C -->|无匹配| F[默认后端]
D --> G[Pod A1, A2, A3]
E --> H[Pod B1, B2]
  1. 客户端发起 HTTP/HTTPS 请求到 Ingress Controller 的 IP 或域名
  2. Ingress Controller 检查请求的 Host 头和路径
  3. 根据 Ingress Rules 中定义的规则，确定请求应路由到哪个 Service
  4. 将请求转发到对应的 Service
  5. Service 将请求负载均衡到后端 Pod

Ingress 资源 YAML 结构详解#

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: default
  annotations:
    # 注解用于配置 Controller 特定功能
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  # TLS 配置
  tls:
  - hosts:
    - app.example.com
    secretName: example-tls-secret  # 预先创建的 TLS 证书
  
  # Ingress 规则
  rules:
  - host: app.example.com  # 基于主机名的路由
    http:
      paths:
      - path: /api        # 基于路径的路由
        pathType: Prefix  # 路径匹配类型：Exact, Prefix, ImplementationSpecific
        backend:
          service:
            name: backend-service  # 目标 Service 名称
            port:
              number: 80           # 目标 Service 端口
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
  
  # 默认后端（可选）
  defaultBackend:
    service:
      name: default-service
      port:
        number: 80

常见 Ingress Controller 对比#

Controller适用环境优势局限性
Nginx Ingress任何环境功能丰富，社区活跃，配置灵活需要额外维护，资源占用较高
GCE IngressGoogle Cloud与 GCP 深度集成，自动配置全球负载均衡仅限 GCP，配置变更慢（几分钟）
ALB IngressAWS与 AWS ALB 深度集成，支持高级路由仅限 AWS，成本较高
Traefik任何环境配置简单，自动服务发现，Dashboard 友好大规模集群性能不如 Nginx
Istio Gateway服务网格高级流量管理，与服务网格深度集成学习曲线陡峭，资源消耗大

Ingress 与 Service 的关系#

特性Service (LoadBalancer/NodePort)Ingress
工作层级L4 (TCP/UDP)L7 (HTTP/HTTPS)
路由能力仅基于 IP/Port基于 Host, Path, Header 等
SSL/TLS通常在应用层处理内置 SSL 终止
IP 地址每个 Service 可能需要独立 IP多个服务共享单一 IP
使用场景非 HTTP 服务，简单暴露Web 应用，复杂路由需求
成本多个 LB 意味着高成本单一 LB 服务多个应用

关键理解：Ingress 通常与一个 LoadBalancer 或 NodePort 类型的 Service 结合使用，该 Service 用于暴露 Ingress Controller 本身，而不是直接暴露应用服务。

实际配置示例（Nginx Ingress）#

1. 安装 Nginx Ingress Controller#

# 安装控制器（使用 Helm 最简单）
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

2. 创建 TLS 证书（可选）#

# 创建自签名证书（生产环境应使用 Let's Encrypt 或正式证书）
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout tls.key -out tls.crt -subj "/CN=app.example.com/O=MyOrg"

# 创建 Kubernetes Secret
kubectl create secret tls example-tls-secret \
  --key tls.key \
  --cert tls.crt

3. 创建 Ingress 资源#

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"  # 允许大文件上传
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: example-tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 8080
      - path: /(.*)  # 前端服务捕获所有其他路径
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

4. 验证 Ingress#

# 查看 Ingress 状态
kubectl get ingress

# 测试访问
curl -k -H "Host: app.example.com" https://<INGRESS_IP>/api/users

# 查看详细信息
kubectl describe ingress my-app-ingress

高级功能#

1. 金丝雀发布（Canary Releases）#

annotations:
  nginx.ingress.kubernetes.io/canary: "true"
  nginx.ingress.kubernetes.io/canary-weight: "10"  # 10%流量到新版本

2. 身份验证（Basic Auth）#

annotations:
  nginx.ingress.kubernetes.io/auth-type: basic
  nginx.ingress.kubernetes.io/auth-secret: basic-auth-secret
  nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"

3. 速率限制#

annotations:
  nginx.ingress.kubernetes.io/limit-rps: "5"  # 每秒5个请求
  nginx.ingress.kubernetes.io/limit-connections: "10"  # 每IP 10个连接

4. CORS 配置#

annotations:
  nginx.ingress.kubernetes.io/enable-cors: "true"
  nginx.ingress.kubernetes.io/cors-allow-origin: "https://example.com"

常见问题与解决方案#

1. Ingress 无法访问#

  • 检查点：
    • Ingress Controller 是否正常运行
    • Ingress 资源是否有正确配置的规则
    • 服务和 Pod 是否处于 Ready 状态
    • DNS 是否正确解析到 Ingress IP
# 检查 Controller 状态
kubectl get pods -n ingress-nginx

# 检查 Ingress 事件
kubectl describe ingress <ingress-name>

2. SSL/TLS 问题#

  • 解决方案：
    • 确保证书和私钥正确格式
    • 证书域名与访问域名匹配
    • 使用 kubectl describe secret <secret-name> 验证 Secret

3. 路径匹配不生效#

  • 常见原因：
    • 路径类型（pathType）配置错误
    • 重写目标配置不正确
    • 服务端点不健康

最佳实践#

  1. 始终使用 TLS：即使在开发环境，也应使用自签名证书模拟生产环境
  2. 为每个环境分离 Ingress：dev/staging/prod 使用不同 Ingress 资源
  3. 合理使用注解：将特定于 Controller 的配置放在 annotations 中
  4. 集中管理证书：使用 cert-manager 自动管理 Let’s Encrypt 证书
  5. 监控 Ingress：收集请求率、延迟、错误率等指标
  6. 安全加固：
    • 限制请求大小
    • 配置适当超时
    • 启用 WAF（如 ModSecurity）
    • 定期更新 Ingress Controller

未来趋势：Gateway API#

Kubernetes 正在开发下一代 Ingress API —— Gateway API，它将提供：

  • 更丰富的路由功能
  • 多团队协作支持（不同团队管理不同路由部分）
  • 标准化扩展点
  • 更精细的流量控制

Gateway API 不会立即取代 Ingress，但代表了未来发展方向。

一个简单类比#

想象 Kubernetes 集群是一座大型购物中心：

  • Service 就像商场内各个店铺的内部电话系统，仅在商场内部有效
  • NodePort/LoadBalancer Service 就像为每个店铺单独设置一个对外电话，需要多个号码
  • Ingress 就像商场的总机系统，顾客只需拨打一个总机号码（IP），总机根据请求内容（要找哪个店铺/部门）将电话转接到正确的地方
  • Ingress Controller 就是总机接线员，根据预设规则决定如何转接电话
  • Ingress Rules 就是转接规则手册，告诉接线员什么号码转到哪里

作为初学者，理解 Ingress 是掌握 Kubernetes 服务暴露的关键一步。它不仅解决技术问题，也体现了云原生架构中的核心思想：通过标准化 API 和解耦组件，实现灵活、可扩展的系统设计。与 kubeadm 一样，Ingress 是 Kubernetes 生态中不可或缺的组件，掌握它将为你的云原生之旅奠定坚实基础。

本文共 2740 字，创建于 Dec 31, 2025

相关标签： Kubernetes, ByAI