Ingress 与 NodePort 的区别
这篇文章整理 Kubernetes 中 NodePort 和 Ingress 两种对外暴露方式的差异。它们都能让集群里的服务被外部访问,但解决的问题层次并不一样。
核心区别
NodePort
用户 -> 节点 IP:端口 -> Service -> Pod它的特点很直接:
- 每个服务通常都要占用一个独立端口
- 端口一般来自
30000-32767 - 访问入口主要靠
IP + 端口
Ingress
用户 -> Ingress Controller -> Service -> Pod它的重点不在“多开一个端口”,而在于通过一个统一入口做七层转发:
- 多个服务可以共用
80/443 - 可以按域名或路径分流
- 通常还会顺手接管 HTTPS、认证和限流等能力
对比表
| 维度 | NodePort | Ingress |
|---|---|---|
| 访问入口 | IP:端口 | 域名或路径 |
| 端口占用 | 每个服务一个端口 | 多个服务共享统一入口 |
| 路由能力 | 四层暴露为主 | 七层路由 |
| HTTPS 管理 | 分散处理 | 适合统一处理 |
| 复杂度 | 简单 | 中等 |
| 适用场景 | 测试、小规模暴露 | 多服务、生产环境 |
典型场景
只有 1 到 2 个服务
如果只是临时测试,或者只有少量服务需要对外暴露,NodePort 往往更省事。
例如:
http://10.0.5.1:31999这种场景下,引入 Ingress Controller 反而会增加一层复杂度。
有多个服务要统一发布
如果集群里要对外暴露很多服务,NodePort 很快就会变得难维护:
k8m -> 10.0.5.1:31999
prometheus -> 10.0.5.1:31998
grafana -> 10.0.5.1:31997
jenkins -> 10.0.5.1:31996问题会越来越明显:
- 端口难记
- 配置分散
- 端口冲突风险更高
而 Ingress 的表达方式通常会更自然:
k8m.local -> k8m
prom.local -> prometheus
grafana.local -> grafana
jenkins.local -> jenkins或者按路径:
/k8m
/prom
/grafana架构差异
NodePort 模式
用户 -> 节点端口 -> 对应 Service -> 后端 PodIngress 模式
用户 -> Ingress Controller -> 按域名/路径转发 -> Service -> Pod从本质上说,Ingress 比 NodePort 多了一层“统一入口和路由决策”。
怎么选
更适合用 NodePort 的情况
- 只有少量服务
- 内部测试环境
- 想要快速验证,不想额外部署 Ingress Controller
更适合用 Ingress 的情况
- 有多个服务要统一发布
- 需要域名访问
- 需要 HTTPS
- 需要认证、限流、灰度等高级能力
- 生产环境长期使用
总结
如果只用一句话总结:
NodePort解决的是“让一个服务能被外面访问”Ingress解决的是“让很多服务以统一方式被外面访问”
所以它们不是简单的谁替代谁,而是复杂度和能力层级不同。服务少、环境简单时用 NodePort 很合适;一旦进入多服务和长期运维场景,Ingress 往往会更顺手。