3 ms·
This isn't always true. On GKE for example, LoadBalancer is very expensive first of all. Second of all, if you use LetsEncrypt such as cert-manager, the GKE loa
by rcconf 7y ago
This isn't always true. On GKE for example, LoadBalancer is very expensive first of all. Second of all, if you use LetsEncrypt such as cert-manager, the GKE load balancer is awful to configure and takes forever to get a cert.
Also by using the GKE load balancer for ingress, you lose out on a lot of things, like password protection, or certain rules you want with nginx.
I've tried my best to stick with GKE LoadBalancer, but it's just an awful experience. Now I have GKE to load balance traffic to nginx-ingress, the level 3 load balancer is just not flexible enough and in general annoying to configure.
- q3k 7y agoI think you're conflating the GKE Ingress Controller (which you don't have to use, and yes, confusingly it's named the GCLB controller, but that's because it configures L7 GCP LB's, not because it's there for k8s LBs) with the GKE load balancer controller/provider for LoadBalancer services (which you do have to use, even if you run nginx-ingress-controller). And yes, I agree that both are extremely slow to reconfigure and the that Ingress controller is inflexible. I'm not saying that you need to always use a LoadBalancer for all payloads. But you do need one to ingress traffic in a sensible manner if you're running your own N-I-C (which you have to do on bare metal, and which, as you said, you end up using even on GKE).