📚 课程目录第2章 Ingress基础回顾

Ingress 基础回顾：Kubernetes Ingress 资源、Ingress Controller 工作原理、常见注解

在 Kubernetes 集群中，Service 和 Pod 的 IP 仅在集群内可达。要将外部流量引入集群内部服务，传统方式有 NodePort 和 LoadBalancer，但它们在多服务场景下存在端口管理复杂、成本高昂等问题。Ingress 作为集群入口的统一抽象层，提供了基于域名和路径的 HTTP/HTTPS 路由能力，是构建生产级流量管理体系的基石。

2.1 Ingress 资源定义

Ingress 是一个 Kubernetes API 对象，定义了从集群外部到内部服务的路由规则。一个典型的 Ingress 资源包含：路由规则（host/path）、后端 Service 映射、以及可选的 TLS 配置。

  核心字段说明：
  spec.rules：定义主机名（host）和路径（path）匹配规则，每个规则指向一个后端 Service。
spec.tls：配置 HTTPS 证书，指定 Secret 名称和关联的 host。
spec.ingressClassName：指定使用的 Ingress Controller 名称（K8s 1.18+ 推荐方式）。
spec.defaultBackend：兜底路由，当所有规则都不匹配时转发到此后端。

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

字段	类型	说明
host	string	域名匹配，支持精确匹配和通配符（如 *.example.com）
path	string	URL 路径，配合 pathType 使用
pathType	enum	Prefix（前缀匹配）、Exact（精确匹配）、ImplementationSpecific（由 Controller 决定）
backend.service	object	目标 Service 名称和端口
ingressClassName	string	关联的 Ingress Controller 类名

2.2 Ingress Controller 工作原理

Ingress 资源本身只是一个声明式配置，真正实现流量转发的是 Ingress Controller。它是一个运行在集群中的反向代理程序（如 Nginx、Traefik、HAProxy），负责监听 Ingress 资源变化并动态更新代理配置。

关键机制：Ingress Controller 通过 Kubernetes Informer 机制监听 Ingress、Service、Endpoint 资源的变化。当检测到 Ingress 规则变更时，Controller 会动态重写反向代理配置文件（如 Nginx 的 nginx.conf），并执行 reload 操作，整个过程无需重启 Pod。

2.3 常见注解（Annotations）

Annotations 是 Ingress 资源的扩展配置入口，不同 Ingress Controller 支持不同的注解集。以下以 nginx-ingress-controller 为例，列出生产环境中高频使用的注解：

注解名称	作用	典型值
nginx.ingress.kubernetes.io/rewrite-target	重写请求路径，常用于前端路由	`/` 或 `$2`
nginx.ingress.kubernetes.io/ssl-redirect	强制 HTTP 跳转到 HTTPS	`true`
nginx.ingress.kubernetes.io/proxy-body-size	设置请求体大小上限	`10m`
nginx.ingress.kubernetes.io/cors-enabled	启用跨域支持	`true`
nginx.ingress.kubernetes.io/limit-rps	限制每秒请求数（限流）	`100`
nginx.ingress.kubernetes.io/affinity	启用会话保持（Cookie 粘性）	`cookie`
nginx.ingress.kubernetes.io/canary	金丝雀发布流量权重控制	`true`
nginx.ingress.kubernetes.io/configuration-snippet	注入自定义 Nginx 配置片段	`more_set_headers "X-Frame-Options: DENY";`

注意事项：

注解的命名空间和格式因 Ingress Controller 实现而异，迁移 Controller 时需同步调整注解。
configuration-snippet 等注入式注解存在安全风险，建议在 CI/CD 流水线中做语法校验。
金丝雀注解（canary）在回滚场景中尤为重要，后续章节将结合故障演练详细展开。

2.4 Ingress 与 Service 的流量关系

理解 Ingress 的流量模型需要区分两个层面：Ingress → Service 的路由映射，以及 Service → Pod 的负载均衡。Ingress Controller 通常直接与 Endpoint（Pod IP）通信，跳过 kube-proxy 的 iptables 转发，以获得更低的延迟和更灵活的负载均衡策略。