一、开篇：网关讲完了，集群内的流量怎么出去？
前面两篇我们分别聊了 Kong 和 APISIX 两款主流 API 网关的落地实战。有读者在后台问我：“小花，网关我懂了，可是我的服务都跑在 Kubernetes 里，Pod 的 IP 是随时会变的内网地址，外面用户怎么访问进来？难道每个服务都挂一个 Kong？”
这个问题问到了点子上。
我刚接手公司容器化改造那会儿，团队用的是一个极其"朴素"的方案：每个需要对外暴露的服务，手动创建一个NodePort类型的 Service，然后在前面挂一层 Nginx，把不同端口映射成不同域名。结果就是——Nginx 配置几千行、端口表一张 A4 纸都列不下、新增一个服务要同时改三处地方，运维同学每周都要因为配错端口背一次锅。
那次线上故障我到现在都记得：一个新来的同事把 30080 和 30081 两个 NodePort 在 Nginx 里写反了，导致支付回调流量被打到了测试环境，好在测试环境当时没数据，不然又是一次 P0。
所以今天这篇，我们专门聊 Kubernetes 里"对外暴露服务"这件事的集大成者——Ingress。它本质上是把"路由规则"这件事，从手工改 Nginx 配置，变成了声明式、可版本管理、跟着集群一起走的资源对象。
二、服务暴露的四种姿势，以及为什么最终是 Ingress
Kubernetes 把服务暴露给集群外，历史上有这么几种演进：
1. hostNetwork / hostPort：让 Pod 直接用宿主机的网络命名空间。简单粗暴，但端口冲突、调度受限、没法做负载均衡，生产环境基本告别。
2. NodePort：每个节点开一个固定端口（默认 30000-32767），kube-proxy 把它转发到 Pod。优点是省事，缺点是端口号丑、要自己在前端再挡一层负载均衡，而且端口资源是有限的。
3. LoadBalancer：云厂商直接给你每个 Service 分配一个外部负载均衡器（SLB/ELB）。爽是真爽，但一个服务一个 LB，几十个服务就是几十个公网 IP，月底账单能让你怀疑人生。我们曾经一个月光 LB 就烧了小两万。
4. Ingress：一个 LB 打底，后面用 Ingress 规则把不同域名、不同路径路由到不同 Service。一个入口，N 个后端，这才是性价比最高的解法。
Ingress 的核心价值就一句话：用一份 YAML 描述"什么流量去哪里"，剩下的转发、TLS、负载均衡交给 Controller 自动处理。
三、最容易搞混的概念：Ingress ≠ Ingress Controller
这是我带新人时必考的一道题，错的人能有一半。
- Ingress：只是一个声明式的资源对象，相当于你写的一份"路由需求清单"。它本身不干活。
- Ingress Controller：真正干活的进程，它监听 Ingress 资源的变化，动态生成底层数据面（Nginx/Envoy 等）的配置并 reload。
打个比方：Ingress 是你要装修时画的户型图，Ingress Controller 是施工队。你只画图纸，施工队按图施工。没有 Controller，你画一百张图也不会有一面墙被砌起来。
这也是为什么你光创建一个 Ingress YAML 没反应时，第一反应应该是：我的 Controller 装了吗？跑起来了吗？它监听的是哪个 IngressClass？
四、主流 Controller 横评（含前两篇的网关）
既然前面聊了 Kong 和 APISIX，这里正好把它们的 Ingress 形态也一并对比，方便你选型时有个全局视角：
| 方案 | 数据面 | 配置热更新 | 动态能力 | 适用场景 |
|---|---|---|---|---|
| Nginx Ingress | Nginx | reload（大配置有抖动） | 中，靠注解 | 绝大多数公司首选，稳 |
| Traefik | 自研 | 真正热加载 | 强，原生支持灰度 | 云原生原生、追求自动化 |
| APISIX Ingress | APISIX/etcd | 全动态，无 reload | 极强 | 已用 APISIX、要插件生态 |
| Kong Ingress | Kong | 动态 | 强 | 已用 Kong、要丰富插件 |
我的建议很直接：如果你们没有既有的网关体系，直接用 Nginx Ingress Controller 起手，它资料最多、坑最少、社区最活跃。等业务复杂到需要灰度、限流、插件了，再考虑 APISIX/Traefik 这类更动态的方案——而且它们本质上也能复用你已有的 Ingress 声明。
五、基础路由实战：host、path 与 rewrite
一个最小可用的 Ingress 长这样：
apiVersion:networking.k8s.io/v1kind:Ingressmetadata:name:shop-ingressannotations:nginx.ingress.kubernetes.io/rewrite-target:/spec:ingressClassName:nginxrules:-host:mall.example.comhttp:paths:-path:/apipathType:Prefixbackend:service:name:order-serviceport:number:8080这里有几个关键点，都是我踩过坑才记住的：
pathType一定要显式写。Prefix是前缀匹配，Exact是精确匹配，ImplementationSpecific是看 Controller 心情。新版本里不写会报错，老版本里不写会行为诡异。rewrite-target常常被忽略。比如你的 Service 实际路径是/，但外面暴露的是/api，不做 rewrite，请求打到后端就变成/api/xxx，后端大概率 404。这个注解就是告诉 Controller：“把/api这段前缀摘掉再转发”。
六、TLS 实战：cert-manager 让证书"自愈"
HTTPS 现在是标配，但手工管理证书是运维噩梦：申请、部署、盯着到期、续期……任何一个环节漏了，就是一次全站 HTTPS 崩盘。
我们吃过这个亏。一次证书过期那天正好是周日，值班同学手机被打爆，用户在微信里骂街。从那以后我们全面上了cert-manager：它作为一个 Kubernetes 控制器，自动向 Let’s Encrypt 申请证书、自动注入到 Secret、到期前自动续期，全程无人值守。
Ingress 里引用证书只要一行：
spec:tls:-hosts:-mall.example.comsecretName:mall-tls-secretrules:-host:mall.example.com证书的事，就从"每月一次惊魂"变成了"忘掉它存在"。让机器管证书，把人从到期焦虑里解放出来，这才是云原生该有的样子。
七、灰度与流量切分：和前面讲的灰度发布一脉相承
如果你看过我讲 Kong、APISIX 灰度的文章，会发现 Ingress 层的灰度逻辑是一脉相承的——只是配置位置从网关面板搬到了 YAML 注解。
Nginx Ingress 支持基于权重的金丝雀：
annotations:nginx.ingress.kubernetes.io/canary:"true"nginx.ingress.kubernetes.io/canary-weight:"10"这表示把 10% 的流量切到新版本。配合 CI/CD，我们可以先放 10%，观察监控，再逐步 30%、50%、100%。灰度不是炫技，是给线上的自己留一条退路。这和我在 Kong/APISIX 篇里强调的"零风险上线"是同一个灵魂。
八、一个灵魂拷问：限流、鉴权放 Ingress 还是放网关？
这是架构评审时经常被争论的问题。我的判断标准就两条：
- 集群边界通用的东西（HTTPS 终止、基础限流、跨域 CORS、基础鉴权），放 Ingress 层统一做，避免每个服务重复造轮子。
- 业务相关的精细治理（按用户维度限流、复杂鉴权、协议转换、插件链），放 API 网关层做，那里有更丰富的插件生态和动态能力。
一句话总结：Ingress 是你的"小区大门"，管进出和第一道安检；API 网关是你的"楼栋管家"，管每家每户的精细服务。职责分清，各司其职。
九、生产踩坑实录（都是真金白银换来的）
坑 1：path 末尾的/导致 404。path: /api/和path: /api在 Prefix 模式下行为不同，配合 rewrite 时尤其容易踩。我们曾经因为一个斜杠，排查了三个小时。建议团队统一规范：对外路径一律不带末尾斜杠。
坑 2：正则路由的顺序陷阱。
用pathType: ImplementationSpecific配正则时，Controller 按配置顺序匹配，把具体路由写前面、通配写后面，否则通配比你先命中。
坑 3：大文件上传超时。
默认proxy-body-size是 1M，传个大附件直接 413。要在注解里放开：nginx.ingress.kubernetes.io/proxy-body-size: "50m"，同时调整后端超时。
坑 4：Ingress Controller 成了新单点。
很多人忘了 Controller 本身也要高可用。我们一开始只部署了一个副本，结果一次节点故障，全站入口直接挂掉。后来改成多副本 + HPA 自动扩缩，并把它单独调度到专用节点池，才真正稳下来。
坑 5：注解拼写错误静默失效。
Ingress 的注解写错了不会报错，只是"不生效"。比如把canary-weight写成canary-weigh，灰度就悄悄没生效，你还在以为已经切了 10% 流量。建议把常用注解做成 Helm values 模板，减少手抖。
十、写在最后
回头看，Ingress 的本质不是一项多高深的技术，而是一种**"把路由这件事声明化、标准化、跟着集群走"的工程思想**。它把我们从"手工改 Nginx"的泥潭里拉出来，让流量入口也变成了可以版本管理、可以 Code Review、可以一键回滚的代码。
从 NodePort 到 LoadBalancer 再到 Ingress，从手工配置到 cert-manager 自愈，从单副本到多副本 HPA——这一路踩的坑，本质上都在回答同一个问题：如何让"流量从哪里来、到哪里去"这件事，既灵活又可靠。
下一站，我们可以聊聊 Helm 这个"Kubernetes 的包管理器"，看看怎么把今天这些 Ingress、Service、Deployment 打包成一个可复用的"应用安装包"。关注我，架构路上不迷路。
—— 本文是《100 篇架构实战》系列第 88 篇，前作可回看 Kong / APISIX 网关落地实战与灰度发布专题。
