在Kubernetes中使用Nginx Ingress Controller是否必须创建Service？

结论先行：Nginx Ingress Controller支持直接通过Endpoints访问Pod，但这不代表你完全不需要创建Service，具体要根据业务场景判断

1. 两种流量转发逻辑的差异 #

• 传统组合（Service + Ingress）：Ingress Controller把外部流量转发到ClusterIP Service，再由Service通过iptables/IPVS规则将流量分发到后端Pod。Service的核心作用是Pod发现、负载均衡，同时提供稳定的集群内访问入口。
• 直接用Endpoints：Ingress Controller绕过Service，直接通过Kubernetes Endpoints API获取Pod的IP列表，把流量直接打给Pod。这种方式少了一层转发开销，也能规避Service带来的一些潜在问题（比如iptables规则冲突、特定场景下的会话保持限制）。

2. 可以去掉Service的场景 #

如果你的业务只需要通过Ingress对外暴露，且集群内部没有其他Pod需要访问这些后端Pod，那么可以尝试不创建ClusterIP Service，直接让Ingress关联Endpoints（通常通过Ingress配置中指定后端的endpoints而非serviceName实现）。

但要注意：Endpoints的维护依赖于Pod的标签匹配，若手动管理Endpoints会非常繁琐，一般还是要靠Deployment的标签选择器自动同步。

3. 建议保留Service的常见场景 #

• 集群内部访问需求：如果集群内其他服务需要调用你的后端，Service提供的稳定DNS名称和负载均衡能力是Endpoints无法替代的（Endpoints没有DNS解析能力，只能通过IP访问）。
• 配置简化：Service会自动同步Pod的扩缩容、重启状态，自动更新Endpoints列表，不需要你手动维护关联关系。
• 生态兼容性：大多数Kubernetes工具（监控、服务网格、日志系统等）都是基于Service设计的，保留Service能更好地适配整个生态的最佳实践。

实操建议 #

如果你当前的Service+Ingress运行稳定，且没有明确的性能瓶颈或特殊需求，没必要贸然调整。若想尝试去掉Service，可以先在测试环境验证，确认集群内没有其他依赖该Service的流量后再在生产环境调整。

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