Ingress controllers and cloud LoadBalancer Services solve different layers: the LB gives you one stable VIP per Service, while Ingress (or Gateway API) multiplexes many Hosts and paths onto a shared dataplane. For public HTTP, start with one LB in front of one Ingress/Gateway class, keep TLS on a single layer, and only add per-Service LoadBalancers for non-HTTP or sticky TCP that Ingress cannot express cleanly. Dual-publishing the same Host on both a raw LB Service and an Ingress rule is what usually produces intermittent 404/502 during cutovers.

Ops prove-out after choosing a path: list the LB address and the Ingress/Gateway programmed addresses, then request a canary Host and compare status codes to the pre-change baseline. If traffic vanishes after a controller upgrade, verify the IngressClass or GatewayClass name still matches and that Endpoints did not empty. When only one path breaks, check Service port names versus backend refs and NetworkPolicies — most entry-point outages are class mismatch or split TLS, not the YAML shape of the route.