Ingress Controller 是独立部署的七层流量网关，监听 Ingress 等资源变化，动态生成代理配置（如 Nginx），实现基于域名/路径的路由、TLS 终止与负载均衡，依赖 Service 作为唯一后端。
Ingress 控制器不是 Kubernetes 内置组件，而是独立部署的“流量网关”，它把 Ingress 资源中定义的 HTTP/HTTPS 路由规则，实时翻译成具体代理（如 Nginx）可执行的配置，并真正接管外部请求的转发。理解它，关键在三个层面：它不处理业务逻辑，只做七层路由；它依赖 Service 作为唯一后端；它靠监听+动态生成+轻量更新来维持高可用和低延迟。
Ingress Controller 的工作本质
Ingress 资源本身只是 YAML 文件，就像一份交通调度图纸；真正指挥车流、切换红绿灯、检查车牌的是 Ingress Controller 这个“交管系统”。它通过 Kubernetes Informer 持续监听 API Server 中 Ingress、Service、Endpoints、Secrets 等资源变化，一旦发现规则增删或证书更新，就触发配置重建流程：
- 构建上游（Upstream）：根据 Service 关联的 Endpoints，动态生成后端 Pod 列表
- 生成服务器块（Server Block）：按 host + path 组合，生成对应的 nginx server{} 配置
- 注入 TLS 配置：从 Secret 中读取证书，配置 ssl_certificate 和 ssl_certificate_key
- 避免高频重载：Pod IP 变更（如滚动更新）由 Lua 模块热更新 upstream，无需 reload nginx 进程
主流控制器选型与部署方式
不同控制器适配不同场景，选择取决于你对功能、运维复杂度和生态集成的要求：
- nginx-ingress：最成熟稳定，支持 Rewrite、Canary、Rate Limiting、External Auth 等丰富注解，适合生产环境统一网关
- Traefik：开箱自动发现服务，配置即生效，内置 Dashboard 和 ACME 自动签发，适合快速迭代的云原生项目
- ALB / NLB Ingress（AWS）：直接复用云厂商负载均衡能力，免运维 Controller，但功能受云平台限制
- Istio Ingress Gateway：深度集成服务网格，支持 mTLS、遥测、细粒度策略，适用于已有 Istio 架构的复杂微服务
部署模式也影响性能与可靠性：
- DaemonSet + hostNetwork：推荐生产使用，绕过 kube-proxy，直通宿主机网络，延迟最低
- Deployment + LoadBalancer：公有云首选，由云平台分配公网 IP，自动健康检查
- Deployment + NodePort：测试环境可用，但需额外前置 LB 或端口映射，链路多一跳
核心配置实战：从基础路由到灰度发布
一个 Ingress 资源要生效，必须满足三个前提：Ingress Controller 已运行、后端 Service 存在且 Ready、DNS 解析指向 Controller 的 IP。典型配置如下：
基础域名路由：
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
tls:
- hosts:
- app.example.com
secretName: app-tls-secret # 引用包含 cert/key 的 Secret
rules:
- host: app.example.com
http:
paths:
- path: /api(/|$)(.*)
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
进阶流量治理常用手段：
-
路径重写：用
rewrite-target注解将/api/v1/users映射为/v1/users转发给后端 -
基于 Header 的灰度：添加
nginx.ingress.kubernetes.io/canary: "true"及canary-by-header: "x-canary"，让指定 header 的请求打到新版本 Service -
限流保护：用
nginx.ingress.kubernetes.io/limit-rps: "10"防止突发流量压垮服务 -
外部认证：集成 OAuth2 Proxy，通过
auth-url注解实现统一登录网关
排错与可观测性要点
Ingress 流量不通，90% 的问题出在四层以下或配置细节。建议按顺序排查：
- 确认 Controller Pod Running 且 Ready：
kubectl get pods -n ingress-nginx - 检查 Controller Service 是否暴露成功：
kubectl get svc -n ingress-nginx，关注 EXTERNAL-IP 或 NodePort - 验证 Ingress 资源状态：
kubectl describe ingress <name></name>，重点看 Events 中是否有 “Successfully Reconciled” - 查看 Controller 日志：
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller，搜索 “error” 或 “denied” - 手动测试配置生成结果：
kubectl exec -n ingress-nginx <controller-pod> -- cat /etc/nginx/nginx.conf</controller-pod>，确认 server 块和 upstream 是否正确生成
生产环境建议接入 Prometheus + Grafana，监控 Controller 的请求量、5xx 错误率、upstream latency 等核心指标，再配合访问日志做链路追踪。
