Clarifying L7 ALB and GKE Ingress Controller Interaction: Separate Units or Combined Functionality, in context of ALB's http/2 limitation

Question

In GKE, when we deploy an ingress resource with default GKE Ingress Controller, the documentation mentions that an external L7 Application Load Balancer (ALB) will be deployed.

Question-1: Are the L7 ALB and GKE Ingress Controller distinct physical computing units, or do they act as a logically combined unit?

Scenario 1 (Separate Units):

1. The initial request arrives at the L7 ALB.
2. L7 ALB terminates TLS, analyzes the request contents, and forwards it to the GKE Ingress Controller (assumed to be residing on separate Kubernetes pods).
3. L7 ALB then load balances requests across the GKE Ingress Controller pods, not directly to individual Kubernetes service pods.

Scenario 2 (Combined Unit):

1. The request reaches a single, logically combined unit encompassing the L7 ALB and GKE Ingress Controller functionalities. This combined unit analyzes the request content and routing rules before forwarding it to the appropriate Kubernetes service pods.

Why i want to understand this ?

Understanding this is crucial for interpreting the L7 ALB documentation's mention of limitations with gRPC (HTTP/2) :

"HTTP/2 between the load balancer and the instance can require significantly more TCP connections to the instance than HTTP(S). Connection pooling, an optimization that reduces the number of these connections with HTTP(S), is not currently available with HTTP/2. As a result, you might see high backend latencies because backend connections are made more frequently."

Question-2 : How does the identified L7 ALB limitation regarding HTTP/2 connections potentially affect the performance of the L7 ALB + GKE Ingress controller architecture?

Question-3: Are there any additional insights or considerations regarding this interaction model and its impact on deployment or performance?