“Ingress is not a Service type”. Why not? Is this just a historical accident?
An Ingress (in GKE) sets up a global HTTP Load Balancer. A K8s “LoadBalancer” Service sets up an internal network LB. Logically, in general you might want the one or the other, but not both, and so these seem functionally in the same category, not in two separate layers.
The Service API is designed to be an L4 API, and frankly it already does too much. To change it to add L7 would be to overload it way too much.
Please look at the upcoming work around a new Gateway API which presents a (hopefully) cleaner abstraction.
Thank you. Especially with the move from Ingress to Gateway, this suggests that the division between Service and Ingress is a historical accident. But that raises the question of why LoadBalancer is a Service type. After all, LoadBalancer triggers the creation (in GKE) of an internal TCP LB, while LoadBalancer should not be bundled with ClusterIP and NodePort that do not do that.
Thank you. Especially with the move from Ingress to Gateway, this suggests that the division between Service and Ingress is a historical accident.
More or less, but I’d put it in the other direction. The fact that
Service is a monolith of ideas is the mistake.
But that raises the question of why LoadBalancer is a Service type. After all, LoadBalancer triggers the creation (in GKE) of an internal TCP LB, while LoadBalancer should not be bundled with ClusterIP and NodePort that do not do that.
Because we used to strive for fewer kinds and chose to overload
Service. It was a mistake, and we’ve learned a lot about what works
in our APIs since then.
Thank you. That clarifies it.
Hi @thockin - Google is failing me. Do you have a link where I can read more about the upcoming Gateway API?
@tammersaleh I believe most of the work is being done in this repo: https://github.com/kubernetes-sigs/service-apis
It has links to the various meetings, slack channel etc as well.