揭开 K8s 流量大管家的面纱：彻底搞懂 nginx-ingress-controller！
🚀 揭开 K8s 流量大管家的面纱：彻底搞懂 nginx-ingress-controller！
容器服务ACK->集群列表->集群名称/ID->工作负载->无状态(Deployment)->全部命名空间->nginx
👋 大家好！
如果你在使用 Kubernetes（比如阿里云 ACK），当你在控制台的kube-system命名空间里闲逛时，大概率会撞见一个名为nginx-ingress-controller的工作负载（就像题图显示的那样 👆）。
它通常静静地运行在那里，状态是Running🟢。它究竟是干什么的？为什么我们需要它？今天，我们就来剥丝抽茧，一探究竟！🕵️♂️
⚠️ 首先纠正一个常见误区：它是谁装的？
很多人在kube-system（系统命名空间）看到它，会误以为这是 Kubernetes 或云厂商“强塞”给你的底层默认组件（就像 CoreDNS 一样）。
其实不然！严格来说，它是我们主动“聘请”来的！🙋♂️
在阿里云 ACK 中，nginx-ingress-controller是一个可选的核心组件（Add-on）。
- 它是怎么来的？通常是集群管理员在创建集群时主动勾选安装，或者后期在“组件管理”中手动一键安装的。之所以放在
kube-system下，是为了将这种“基础设施级”的网络组件与普通的业务代码隔离开来，方便统一管理。 - 💡 架构选型拓展：实际上，在如今的公有云环境中，Nginx 已经不是唯一的选择了。比如阿里云现在也提供了完全托管、性能更强悍的ALB Ingress（直接驱动云端负载均衡器，免去了在集群跑 Nginx Pod 的运维成本）。
- 那为什么还要用 Nginx？因为开源的力量！Nginx Ingress 拥有极其成熟的生态，支持海量的自定义配置（Annotation），甚至能嵌入 Lua 脚本。对于需要极高定制化路由策略的硬核技术团队来说，它依然是不可替代的“流量利器”！⚔️
🏢 一个生动的比喻：公司总前台
搞清楚了它的身世，我们来看看它是干嘛的。把你的Kubernetes 集群想象成一栋超级豪华的写字楼🏢：
- Pod（容器组）= 里面的员工👨💻（真正在干活的程序）。
- Service（服务）= 楼里的部门🏷️（比如：订单部、用户部，把员工组合在一起）。
现在，外部的客户（互联网用户 🌐）想要来拜访这栋楼里的某个部门（访问你的后端 API）。
- 如果没有 Ingress：客户得知道每一个部门的具体分机号（NodePort），或者给每一个部门单独配一个专线电话（LoadBalancer），这不仅超级费钱 💸，而且难以管理。
- 有了 Ingress Controller：相当于在写字楼一楼大厅设立了一个总前台兼安保中心👮♂️💁♀️。
nginx-ingress-controller就是这个总前台！
客户只需要统一走到前台，对前台说：“我要去api.xxx.com”，或者“我要去/login”。前台小本本上记着规则，核对之后，直接把客户精准地领到对应的部门去。
🛠️ 核心概念解析：Ingress vs Ingress Controller
要真正掌握它，必须分清两个长得很像的词：
1. 📜 Ingress（规则/配置单）
Ingress 在 K8s 里只是一份 YAML 格式的**“路由规则表”**。它里面写着：
- “访问
a.com-> 送到 A 服务。” - “访问
b.com/app-> 送到 B 服务。”
👉注意：Ingress 本身是个死物，它只是规则，自己是不干活的。
2. ⚙️ Ingress Controller（执行者/前台本人）
规则需要有人来执行，这个人就是Ingress Controller！
在你的截图里，这就是使用大名鼎鼎的Nginx作为核心引擎来实现的控制器。
它的日常工作流是这样的 🔄：
- 死盯 K8s API：它时刻监视着集群里有没有人创建、修改或删除了 Ingress 规则。👀
- 动态写配置：一旦发现新规则，它会立刻将 K8s 里的 YAML 规则，自动翻译成 Nginx 能够读懂的
nginx.conf配置文件。✍️ - 热重载转发：自动 Reload Nginx 进程生效，然后开始接收外部的 HTTP/HTTPS 请求，并将其转发给后端的 Pod。🚀
✨ 它的核心必杀技
为什么它能在 K8s 流量网关中占据半壁江山？因为它拥有以下强大能力：
- 🌐 统一流量入口，节约成本：整个集群只需要为这个 Controller 暴露一个公网入口（绑定一个云厂商的 SLB）。所有流量先进来再分发，极大节省了公网 IP 和负载均衡器的开销！💰
- 🔀 强大的七层路由：完美支持基于域名 (Domain)和路径 (Path)的精确/正则路由分发。
- 🔒 HTTPS/SSL 证书卸载：业务代码无需关心证书配置。只需把证书挂载到 Controller 上，外部访问是加密的 HTTPS，内部转发是轻量的 HTTP，安全又高效。🛡️
- ⚖️ 高阶流量治理：通过简单的 Annotation 注解，就能轻松实现灰度发布（金丝雀发布）、流量限流（Rate Limiting）、跨域配置（CORS）、重定向等高级玩法。
🕵️ 结合截图，再看一眼细节
再次审视你提供的截图，我们可以印证几个关键点：
- 📦 镜像组成：截图中显示其镜像包含了
nginx-ingress-controller。其实它内部就是 Nginx 进程加上一个 Go 写的控制器代码，两者协同工作。 - 💪 副本数 (Replicas)
1/1：截图显示当前只有 1 个 Pod 在运行。💡 生产环境小贴士：作为整个集群的唯一入口，为了防止“前台”单点故障导致整栋楼失联，在真正的生产环境（Prod）中，强烈建议将其扩容（Scale）到2 个或以上的 Pod，并配合反亲和性调度到不同的节点上，实现高可用。
🎯 总结
总而言之，nginx-ingress-controller就是你根据业务需求，主动为 K8s 集群配置的“大门”和“交通指挥官”🚦。
它巧妙地融合了 Nginx 强悍的反向代理性能与 Kubernetes 的自动化机制，让你能够优雅、高效地将微服务暴露给全世界。下次在控制台看到它，相信你已经对它的底细了如指掌啦！🍻
你在 K8s 网络配置中踩过哪些坑？平时更倾向于用 Nginx Ingress 还是云厂商的 ALB Ingress 呢？欢迎在评论区留言交流！👇