AFAIK an Ingress is just an abstraction layer to a LoadBalancer service targeting Nginx (or others)
That's only partially true; you can use hostNetworking: true and expose the Ingress controller directly off of the Nodes if you wish, skipping the SDN and the need for a Load Balancer (although with the disadvantage of exposing the ports of your Nodes directly to the Internet) -- and roughly the same idea with Service of type: NodePort just with extra port silliness
A lot of folks do use an Ingress controller behind a LoadBalancer in order to segregate the Nodes from the Internet, but its not a requirement
One should also be aware of the ALB Ingress Controller which goes the other way: asking the LB to do the host: and URI routing before it reaches the cluster, and having no(?) nginx component running in the cluster
Are there features only an ingress can provide?
Only? Unlikely. Convenient and cloud-portable? Extremely
I'm not sure if this is what you are asking, but the reason most folks use a single LB and an in-cluster Ingress controller is the massive cost savings of just paying for one LB with almost limitless Ingress resources. Without an Ingress, one would need to use Service of type: LoadBalaner, and then wait while kubernetes provisions a fresh LB for each Service, costing time and money
Are there any drawbacks of using LoadBalancer + Nginx?
Mostly around error and cost management:
there will be an extra network hop from the LB to the in-cluster httpd
most LBs have their own health checking scheme, and the LB can fail its health check independent from the ingress controller failing its health check, leading to an artificial outage
this is also true of routing issues, permissions, cloud quotas, all that jazz
there are potentially two different security mechanisms: the LB and the ingress controller's, and if they don't line up, that can lead to an outage
if one has access logging turned on, it will log twice, once at the LB and once in the ingress
one needs to be aware of the fact that there is in-cluster routing going on, else it will be non-obvious why everything is using just one LB
That's only partially true; you can use
hostNetworking: trueand expose the Ingress controller directly off of the Nodes if you wish, skipping the SDN and the need for a Load Balancer (although with the disadvantage of exposing the ports of your Nodes directly to the Internet) -- and roughly the same idea withServiceoftype: NodePortjust with extra port sillinessA lot of folks do use an Ingress controller behind a LoadBalancer in order to segregate the Nodes from the Internet, but its not a requirement
One should also be aware of the ALB Ingress Controller which goes the other way: asking the LB to do the
host:and URI routing before it reaches the cluster, and having no(?) nginx component running in the clusterOnly? Unlikely. Convenient and cloud-portable? Extremely
I'm not sure if this is what you are asking, but the reason most folks use a single LB and an in-cluster Ingress controller is the massive cost savings of just paying for one LB with almost limitless Ingress resources. Without an Ingress, one would need to use
Serviceoftype: LoadBalaner, and then wait while kubernetes provisions a fresh LB for each Service, costing time and moneyMostly around error and cost management:
most LBs have their own health checking scheme, and the LB can fail its health check independent from the ingress controller failing its health check, leading to an artificial outage
this is also true of routing issues, permissions, cloud quotas, all that jazz