为什么要在Nginx Ingress前部署LoadBalancer类型的Service？

认知前提说明 #

首先明确一个常见误区：K8s的Ingress本身只是一套7层路由的API规范，真正处理请求的是跑在集群节点上的Ingress Controller实例（你示例中的Nginx Ingress Controller就是这类实现），它本身没有直接承接公网流量的能力，前端的LoadBalancer类型Service就是为了补全这层能力设计的。

LoadBalancer类型Service的核心作用 #

• 提供公网接入入口：公有云会为LoadBalancer类型的Service自动创建对应云厂商的负载均衡实例，绑定你配置的公网IP（即YAML中loadBalancerIP字段），公网用户的请求首先会到达这个云LB实例，再转发到集群内部的Nginx Ingress Controller Pod，没有这一层的话Ingress Controller没有公网访问入口，外部用户无法访问到集群内部的服务。
• 保障高可用：云LB本身具备多活高可用属性，会自动对后端的Ingress Controller Pod做健康检查，如果某台节点上的Ingress Controller异常，LB会自动把流量切到其他正常实例所在的节点，避免单点故障导致业务整体不可用。
• 提供基础网络能力兜底：云LB默认具备更高的流量承载能力，还可以直接对接云厂商原生的DDoS防护、带宽限速、访问控制等能力，不需要在Ingress Controller侧额外开发适配，大幅降低生产环境的运维成本。
• 提升集群安全性：不需要用NodePort方式暴露Ingress Controller，避免占用集群所有节点的固定端口，也不需要把集群节点的公网IP直接对外暴露，降低节点被攻击的风险。

是否可以直接删除该Service #

绝大多数公有云生产场景下不可以直接删除，删除后云负载均衡实例会被同步销毁，Ingress Controller失去公网接入入口，所有通过Ingress暴露的公网业务都会直接断流。
只有两种特殊场景可以考虑删除：

• 你已经改用NodePort、HostNetwork等其他方式暴露Ingress Controller，并且自行在前端部署了负载均衡承接公网流量，不过这种方案的可用性和安全性都远低于公有云原生LB方案，生产环境不推荐。
• 你的集群为纯内部部署，不需要对公网暴露任何Ingress服务，仅需要集群内部访问Ingress。

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