K8s仅配置Ingress与Ingress搭配NodePort Service的差异及选型对比

两种配置方案的核心差异 #

Ingress Controller 本身是运行在 Kubernetes 集群内的 Pod，具备集群内部网络访问权限，因此无论后端 Service 是 ClusterIP 还是 NodePort 类型，Ingress 都可以正常转发流量到 Service 再到后端 Pod，两种配置下 Ingress 的服务访问能力没有任何区别，差异主要体现在集群外对 Service 本身的访问权限上。

方案1：Ingress + 默认ClusterIP类型Service #

优势 #

• 安全性更高：服务仅在集群内部可见，外部流量只能通过 Ingress 统一入口访问，不会出现绕过 Ingress 管控的流量，方便在 Ingress 层统一实现 SSL 卸载、鉴权、限流、访问日志采集等全局策略
• 资源消耗更低：不需要占用集群的 NodePort 端口资源（K8S 默认 NodePort 端口范围为 30000-32767，总数量有限），适合服务数量多的集群
• 配置更简洁：Service 不需要额外指定类型，默认即为 ClusterIP，减少冗余配置

劣势 #

• 调试成本高：集群外用户无法直接访问 Service，开发调试时需要额外使用 kubectl port-forward 命令端口转发、或者进入集群内的 Pod 调用服务，无法直接通过节点IP访问
• 本地开发体验差：minikube 等本地集群工具无法通过 minikube service 命令快速拉起服务页面，需要手动配置 Ingress 域名或者端口转发规则

适用场景 #

生产环境、对外提供服务的业务、对安全管控要求高的集群、服务数量较多的集群，是绝大多数场景下的首选方案。

方案2：Ingress + NodePort类型Service #

优势 #

• 调试便捷：开发环境下可以直接通过节点IP+NodePort跳过Ingress直接访问服务，适合排查 Ingress 规则故障、直接测试服务本身功能的场景，比如你当前本地环境可以直接用 minikube service 快速打开 Swagger 页面
• 可作为应急访问入口：极端场景下 Ingress Controller 故障时，可以临时通过 NodePort 访问业务，作为备用访问通道

劣势 #

• 存在安全隐患：服务直接暴露在所有集群节点的端口上，如果节点有公网IP，外部用户可以绕过 Ingress 层的所有管控策略直接访问服务，带来安全风险
• 端口资源占用：每个 NodePort 类型的 Service 会占用一个集群全局唯一的端口，服务数量较多时可能出现端口冲突
• 运维复杂度更高：多节点集群下需要额外维护 NodePort 与服务的对应关系，访问时需要确认节点IP的可达性，远不如统一用 Ingress 域名访问便捷

适用场景 #

本地开发测试环境、内部私有集群且不需要严格管控访问入口的场景，生产环境除非有特殊需求否则不建议使用。

最佳实践建议 #

如果同时有开发环境和生产环境的部署需求，可以通过 Helm 模板做差异化配置：开发环境渲染 Service 为 NodePort 类型方便调试，生产环境渲染为默认的 ClusterIP 类型保障安全，兼顾两种场景的需求。

内容的提问来源于stack exchange，提问作者dabljues