自建API Gateway后是否仍需Kubernetes Ingress？

是否仍需Ingress？ #

不需要。你的自研API Gateway已经承担了Ingress的核心职责——作为集群统一入口处理路由转发、流量管控等工作，Ingress本身只是实现集群入口的一种标准化方案，既然已有定制化的替代实现，完全无需再部署Ingress。

能否将API Gateway的Service设为LoadBalancer类型作为集群入口？ #

完全可以。LoadBalancer类型的Service会借助云厂商负载均衡器（或本地集群的MetalLB等方案）获取外部可访问的IP，直接将外部流量导向自研API Gateway，刚好满足集群入口的需求。

该方案的利弊分析 #

优势 #

• 架构更简洁：减少Ingress这一层组件，降低运维复杂度和潜在故障点
• 自主可控性强：所有入口流量规则、扩展功能都由自研网关实现，不受Ingress Controller的规则限制，能更好匹配内部定制需求
• 性能损耗更低：减少一层转发环节，流量路径更短，理论上能提升部分性能

劣势 #

• 缺失Ingress生态集成：若后续需要使用K8s生态中依赖Ingress的工具（如cert-manager的Ingress证书自动管理、部分流量监控工具），需自行开发适配逻辑
• 负载均衡成本增加：云厂商的LoadBalancer实例通常按资源计费，每个LoadBalancer都会产生额外成本；而Ingress可通过同一个Ingress Controller共享一个LoadBalancer，成本更低
• 多入口场景复杂度高：若后续需要多入口（如不同域名、不同流量分组），直接使用LoadBalancer需创建多个实例，而Ingress可通过配置规则统一管理

是否属于不良实践？ #

不算。这是完全合理的架构选择，不少有定制化需求的团队或大厂都会采用这种方案。只要你的自研API Gateway能稳定承担入口的核心职责（如路由转发、SSL终止、限流熔断、日志监控等），且做好高可用配置（如副本扩容、健康检查、故障转移），就不存在问题。

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