Kubernetes Difference between ingress & load balancer

Links: 110 Kubernetes Index

Load Balancer¶

If you want to directly expose a service, this is the default method.
All traffic on the port you specify will be forwarded to the service.
There is no filtering, no routing, etc.
This means you can send almost any kind of traffic to it, like HTTP, TCP, UDP, Websockets, gRPC, or whatever.
The big downside is that each service you expose with a LoadBalancer will get its own IP address, and you have to pay for a LoadBalancer per exposed service, which can get expensive!

Ingress is NOT a type of service it is of kind: Ingress.
Instead, it sits in front of multiple services and act as a "smart router" or entrypoint into your cluster.
You can do a lot of different things with an Ingress, and there are many types of Ingress controllers that have different capabilities.
The default GKE (Google Kubernetes Engine) ingress controller will spin up a HTTP(S) Load Balancer for you.
- This will let you do both path based and subdomain based routing to backend services.
- For example, you can send everything on foo.yourdomain.com to the foo service, and everything under the yourdomain.com/bar/ path to the bar service.
Ingress example

Ingress is probably the most powerful way to expose your services, but can also be the most complicated.
There are many types of Ingress controllers, from the Google Cloud Load Balancer, Nginx, Contour, Istio, and more.
There are also plugins for Ingress controllers, like the cert-manager, that can automatically provision SSL certificates for your services.
Ingress is the most useful if you want to expose multiple services under the same IP address, and these services all use the same L7 protocol (typically HTTP).
You only pay for one load balancer if you are using the native GCP integration, and because Ingress is “smart” you can get a lot of features out of the box (like SSL, Auth, Routing, etc)

Last updated: 2022-09-09