Home

Ingress 与 NodePort 的区别

这篇文章整理 Kubernetes 中 NodePortIngress 两种对外暴露方式的差异。它们都能让集群里的服务被外部访问,但解决的问题层次并不一样。

核心区别

NodePort

用户 -> 节点 IP:端口 -> Service -> Pod

它的特点很直接:

  • 每个服务通常都要占用一个独立端口
  • 端口一般来自 30000-32767
  • 访问入口主要靠 IP + 端口

Ingress

用户 -> Ingress Controller -> Service -> Pod

它的重点不在“多开一个端口”,而在于通过一个统一入口做七层转发:

  • 多个服务可以共用 80/443
  • 可以按域名或路径分流
  • 通常还会顺手接管 HTTPS、认证和限流等能力

对比表

维度NodePortIngress
访问入口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 -> 后端 Pod

Ingress 模式

用户 -> Ingress Controller -> 按域名/路径转发 -> Service -> Pod

从本质上说,Ingress 比 NodePort 多了一层“统一入口和路由决策”。

怎么选

更适合用 NodePort 的情况

  • 只有少量服务
  • 内部测试环境
  • 想要快速验证,不想额外部署 Ingress Controller

更适合用 Ingress 的情况

  • 有多个服务要统一发布
  • 需要域名访问
  • 需要 HTTPS
  • 需要认证、限流、灰度等高级能力
  • 生产环境长期使用

总结

如果只用一句话总结:

  • NodePort 解决的是“让一个服务能被外面访问”
  • Ingress 解决的是“让很多服务以统一方式被外面访问”

所以它们不是简单的谁替代谁,而是复杂度和能力层级不同。服务少、环境简单时用 NodePort 很合适;一旦进入多服务和长期运维场景,Ingress 往往会更顺手。

Kubernetes 网络