ingress 仅处理 http/https 流量（l7），依赖 ingress controller 监听 80/443 端口，路由规则基于 host 头和 url 路径匹配，不感知物理端口；非 http 协议需绕过 ingress 使用 nodeport 或 loadbalancer service。
Ingress 本身不支持基于端口的监听规则，它只处理 HTTP/HTTPS 流量（L7），且必须通过 80 或 443 端口 进入集群。所谓“基于端口的复杂监听”，实际是误解——Ingress 的路由逻辑只看请求中的 Host 头和 path，不感知客户端连接的是哪个端口（只要流量已由 Ingress Controller 接收并解包为 HTTP 请求）。
真正起作用的是 Host 和 Path 组合
Ingress 规则的核心是匹配 host（域名）和 http.paths.path（URL 路径），不是物理端口。例如：
-
host: api.example.com+path: /v1/users→ 转发到user-svc:8080 -
host: admin.example.com+path: /→ 转发到admin-svc:9000 - 同一域名下不同路径：
web.example.com/api/和web.example.com/static/可指向不同服务
Ingress Controller 必须监听 80/443 才能生效
无论你定义多少个 host，Ingress Controller（如 nginx-ingress、Traefik）都必须在宿主机或 Service 上暴露 80（HTTP）和/或 443（HTTPS）端口。其他端口（如 8080、3000）无法被 Ingress 规则识别：
- 用
NodePort方式部署时，需将 Controller 的 80/443 映射到 NodePort 范围（如 30080/30443），但客户端仍要访问http://ip:30080—— 此时 Ingress 规则依然只看Host头，不是看 30080 这个数字 - 用
hostNetwork: true时，Controller 直接绑定宿主机 80/443，客户端可直接用http://api.example.com访问，无需端口号 - 云环境用
LoadBalancer类型，云厂商会自动把 LB 的 80/443 转发给后端 Controller Pod
想实现“多端口语义”，得靠反向代理层前置或重写
如果业务上需要类似 :8080 表示 API、:8000 表示 Web 的区分，有两类可行做法：
-
前置统一入口 + Host 区分：所有流量走 80/443，靠不同域名隔离，比如
api.example.com和web.example.com，这是标准且推荐的做法 -
用 rewrite 或 redirect 模拟端口语义：例如用户访问
http://example.com:8080/v1实际不可达，但你可在前端 Nginx 或 CDN 层把8080请求重写为带特定Host头的请求，再转发到 Ingress Controller 的 80 端口 -
非 HTTP 协议走 Service 直连：若真需监听其他端口（如 gRPC 9000、MySQL 3306），应使用
NodePort或LoadBalancer类型 Service，绕过 Ingress（因 Ingress 不支持 TCP/UDP）
TLS 和 SNI 是 HTTPS 下的“主机名增强版”
当启用 HTTPS 时，Ingress Controller 通过 TLS SNI 扩展获取客户端请求的域名，这比纯 HTTP 的 Host 头更早、更可靠。配置方式是在 Ingress 中添加 tls 字段并引用 Secret：
tls: - hosts: - api.example.com - web.example.com secretName: example-tls
这样，同一个 443 端口就能根据 SNI 域名分流，无需多个 IP 或端口。
