第四部分：Ingress 资源介绍

type

status

date

slug

summary

📝 前言

在 Kubernetes 集群中，Service 资源可以暴露应用到集群内部或外部，但如果我们希望通过 域名、路径等规则更灵活统一管理外部访问，就需要用到 Ingress。

Ingress 是 Kubernetes 中的重要网络资源，它结合了反向代理和负载均衡能力，为微服务架构中的流量管理提供了强大支持。

🧭 背景介绍

随着微服务数量的增长，企业通常需要：

使用统一的域名接入不同的服务

不同的域名路由到不同的服务

根据路径（如 /api、/web）或主机名（如 api.example.com）转发请求。

集中处理 HTTPS/TLS 证书，减少单个服务的维护负担。

Ingress 的出现正是为了解决上述痛点，通过 Ingress Controller（如 Nginx Ingress Controller、Traefik、ALB Ingress Controller 等），实现对外部流量的灵活调度和安全管理。

📋 前提条件

已在集群中部署 Ingress Controller（如 Nginx、Traefik 或云厂商的负载均衡 Controller）。

Service 和 Pod 已经正常运行，确保有后端可供转发。

域名已正确解析到集群 Ingress Controller 的外部地址。

PS：可参考之前部署集群的文章《第四部分：使用 sealos 部署集群》，通过一行命令可快速部署 Nginx Ingress Controller。

🧠 本章知识卡片

🚀 本章小节

1️⃣ 什么是Ingress?

在 Kubernetes 中，Ingress 是一种 API 对象，用于管理集群中服务（Service）的外部访问。

它的作用是：

提供 HTTP/HTTPS 路由规则，把外部请求映射到集群内的 Service。

支持基于域名、路径的流量转发。

支持 TLS 证书管理，统一提供安全访问。

简单理解：

Service 可以把应用暴露出来，但它无法做复杂的流量规则。

Ingress 就像一座“桥梁”，把互联网的访问请求引导到正确的应用，并附带路由 + 安全 + 负载均衡能力。

Ingress 本身只是规则定义，它需要 Ingress Controller 来实际处理流量。

2️⃣ Nginx Ingress 的工作原理

在实际生产中，最常见的 Ingress Controller 就是 Nginx Ingress Controller。

它的核心流程如下：

Ingress 规则存储

用户编写 Ingress YAML，提交到 Kubernetes API Server。

Ingress 资源会存储在 Etcd 中。

Controller 监听规则

Nginx Ingress Controller 持续监听 Kubernetes API。

一旦发现 Ingress 资源更新（新增、修改、删除），就会动态生成对应的 Nginx 配置。

Nginx 配置热更新

Controller 将规则转化为标准的 Nginx 配置文件（nginx.conf）。

通过无缝 reload（热更新）机制应用配置，而不会中断现有连接。

流量处理

外部请求通过 Service + LoadBalancer/NodePort 暴露出 Ingress Controller Pod 的访问入口。

Nginx 根据 Ingress 规则，匹配域名和路径，把请求转发到对应的 Service，再路由到 Pod。

大致流程图如下：

3️⃣ 最简单的Ingress配置

当你希望通过不同域名访问不同的 Service 时，可以使用 host 配置：

说明：api.example.com 请求会转发到 api-service 服务的 80 端口。

我们如果是在测试环境中如何通过 Ingress 进行访问呢，这里有2个方法：

配置本地 hosts 映射，将上述的 host 域名解析到集群的任意节点+ingress controller 绑定的 NodePort 端口，例如：api.example.com:35684

使用 .nip.io host ，不使用自定义的域名，改用集群节点IP+.nip.io 域名，该域名是一种测试的域名会直接解析到IP前面的，例如：api.192.168.10.2.nip.io , 如此也就不用配置 hosts 映射了。

PS: 这里也可以把 nginx ingress 设置为默认的，这样就不用每次都配置 ingressClassName 了，参考命令如下：

另外默认安装的 Nginx Controller 可能还添加了参数只接收有明确 ingresClassName 的请求，我们也可以去掉。

4️⃣ 基于多域名的路由

当你希望通过不同域名访问不同的 Service 时，可添加多个 rule，并设置不同的 host ，配置参考如下：

说明：api.example.com 请求会转发到 api-service，而 web.example.com 请求会转发到 web-service。

5️⃣ 基于路径的路由

同一个域名下，不同路径转发到不同服务：

说明：访问 app.example.com/api → API 服务；访问 app.example.com/web → Web 服务。

6️⃣ 启用 TLS（HTTPS）

为域名配置 HTTPS 证书（Secret 需事先创建好）：

说明：Ingress 会加载 tls-secret 中的证书，为 secure.example.com 提供 HTTPS 访问。

7️⃣ 配置请求重写（Rewrite）

有时后端服务需要路径重写，可以通过 Annotation 实现：

说明：访问 app.example.com/oldpath 时，Ingress 会将请求转发到 /，即重写路径。

8️⃣ 与云负载均衡器集成（以阿里云 ALB 为例）

如果使用云厂商的 Ingress Controller，可以通过特定 Annotation 集成：

说明：该 Ingress 绑定到指定的阿里云 ALB 负载均衡器，并通过域名 cloud.example.com 提供服务。

之前也有一篇文章介绍过阿里云 ACS 集群通过 ALB 暴露访问服务，可参看：《使用阿里云ACS部署XXL-JOB指南（实战三）》

✅ 总结

Ingress 是 Kubernetes 中用于管理 外部访问流量 的关键资源。

它的核心价值在于：

提供统一的域名/路径路由规则，让多个服务可以通过单一入口暴露给外部。

集中管理 TLS 证书，提升安全性，避免重复维护。

配合 Ingress Controller（如 Nginx、Traefik、ALB 等）实现反向代理 + 负载均衡，提高应用的可用性与伸缩性。

在实际生产中，Ingress 的优势主要体现在：

解耦：应用开发者只需关注 Service 定义，不必关心外部访问的复杂配置。

灵活：支持基于主机名、路径、正则等多种规则，适应不同业务场景。

可扩展：通过注解（Annotation）扩展高级功能，例如限流、灰度发布、重写规则、跨域支持等。

与云原生生态融合：可与各大云厂商的负载均衡无缝对接，满足弹性扩展和高可用需求。

一句话总结： Ingress 就是 Kubernetes 的“流量入口网关”，配合 Ingress Controller，可以实现从简单的 HTTP 路由到复杂的企业级流量治理，是微服务架构下不可或缺的流量管理核心组件。

💡

有关文章的任何疑问，欢迎您在底部评论区留言，一起交流~