在Kubernetes集群中已有自建API-Gateway，还需Ingress Controller吗？

这个问题没有绝对答案，核心取决于你的流量管理需求和架构设计：

不需要单独部署的场景 #

如果你的API-Gateway已经覆盖了所有流量入口的核心需求，完全可以不用Ingress：

• API-Gateway本身自带路由、SSL终止、认证、日志记录等能力，外部流量通过负载均衡器直接转发给集群内的API-Gateway（ClusterIP类型），再由它完成到后端服务的路由，这时候Ingress的核心路由功能已经被替代。
• 这种架构相当于把Ingress的南北向流量入口角色，和API网关的高级流量管理能力合并，减少了组件层级，降低运维复杂度。

需要部署的场景 #

在以下特定需求下，保留Ingress会更合理：

• 集群内存在多组独立的服务体系，需要在API-Gateway之下再做一层集群内部的路由规则细分（比如不同命名空间的服务隔离、特定路径的补充路由策略）。不过这种场景比较少见，除非有明确的架构分层要求。
• 部分后端服务需要绕开API-Gateway直接对外暴露，这时候Ingress可以负责这部分流量的入口管理，和API-Gateway各司其职。
• 若你依赖K8s生态中对Ingress更成熟的配套工具（比如某些证书管理器、流量监控插件），而API-Gateway在这些方面的支持不够完善，也可以保留Ingress配合使用。

额外权衡点 #

• 运维成本：多一个Ingress组件就多一套配置、监控、升级的运维工作，非必要不增加冗余。
• 性能损耗：流量多经过一层转发（负载均衡→API-Gateway→Ingress→后端）会增加延迟，对性能敏感的业务要谨慎选择。

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