Fixed
Status Update
No update yet.
Comments
pa...@google.com
Hello Kévin
Thank you for contacting Google Cloud Platform Support. I understand you are having an issue with internal load balancing and I will do my best to advise you.
Internal load balancers are regional resources, the scope of an internal TCP/UDP load balancer is regional, not global. This means that an internal TCP/UDP load balancer cannot span multiple regions. Within a single region, the load balancer services all zones. [1]
A feature request exists to enable an internal load balancer which can handle requests from multiple regions[2]. But I can neither provide you with an ETA for its implementation, nor a guarantee that it will ever be supported. If you would like to create your own feature request, follow the link to Google issue tracker to search or create feature request [3].
Your VMs are able to talk to each other from one region to another as they are connected through the same VPC. Resources within a VPC network can communicate with one another using internal (private) IPv4 addresses, subject to applicable network firewall rules.[4] However, for ILB the behaviour is handled differently due to the regional nature of the ILB(s).
The reason VM instances attached to a network with a specific address mask getting assigned IP with /32 mask is a design requirement of GCP. However, let me explain why VM instances are assigned with the /32 mask on Google Compute Engine (GCE). Please note that the /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communication is established, and everything works.
In addition to that, network masks are enforced at the network layer, not the host layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway), this might further clarify why VM instances are assigned with a /32 netmask, when they are attached to a subnet, for example, /24 mask.
I hope that makes things clearer for you. If you have any other questions or concerns about your issue, please do not hesitate to contact me by replying to this message. I will be more than happy to help at that time.
[1]ILB Scope:https://cloud.google.com/load-balancing/docs/internal/#protocols_scheme_and_scope
[2]Feature Request for multi-region ILB:https://issuetracker.google.com/111021512
[3]Create and Search feature requests:https://cloud.google.com/support/docs/issue-trackers#search_and_create_feature_requests_by_product
[4]VPC Specifications:https://cloud.google.com/vpc/docs/vpc#specifications
Thank you for contacting Google Cloud Platform Support. I understand you are having an issue with internal load balancing and I will do my best to advise you.
Internal load balancers are regional resources, the scope of an internal TCP/UDP load balancer is regional, not global. This means that an internal TCP/UDP load balancer cannot span multiple regions. Within a single region, the load balancer services all zones. [1]
A feature request exists to enable an internal load balancer which can handle requests from multiple regions[2]. But I can neither provide you with an ETA for its implementation, nor a guarantee that it will ever be supported. If you would like to create your own feature request, follow the link to Google issue tracker to search or create feature request [3].
Your VMs are able to talk to each other from one region to another as they are connected through the same VPC. Resources within a VPC network can communicate with one another using internal (private) IPv4 addresses, subject to applicable network firewall rules.[4] However, for ILB the behaviour is handled differently due to the regional nature of the ILB(s).
The reason VM instances attached to a network with a specific address mask getting assigned IP with /32 mask is a design requirement of GCP. However, let me explain why VM instances are assigned with the /32 mask on Google Compute Engine (GCE). Please note that the /32 is an artificial construct. The instance talks to the software defined network, which creates and manages the "real" subnets. So, it is really a link between the single address and the gateway for the subnet. As long as the link layer is there, communication is established, and everything works.
In addition to that, network masks are enforced at the network layer, not the host layer. This helps avoid generation of unnecessary broadcast traffic (which underlying network wouldn't distribute anyway), this might further clarify why VM instances are assigned with a /32 netmask, when they are attached to a subnet, for example, /24 mask.
I hope that makes things clearer for you. If you have any other questions or concerns about your issue, please do not hesitate to contact me by replying to this message. I will be more than happy to help at that time.
[1]ILB Scope:
[2]Feature Request for multi-region ILB:
[3]Create and Search feature requests:
[4]VPC Specifications:
k....@gmail.com
Thanks for your quick reply on ILB and thank you also for details on networking on gcp.
I hope that this feature requesthttps://issuetracker.google.com/111021512 will be considered :).
I am surprised that it has been designed like this because it's a pretty big drawbacks compared to AWS for example.
Do you know if there is another solution for me to interconnect local service to another region except create loadbalancer in a dedicated instance ?
Thanks in advance,
Kévin
I hope that this feature request
I am surprised that it has been designed like this because it's a pretty big drawbacks compared to AWS for example.
Do you know if there is another solution for me to interconnect local service to another region except create loadbalancer in a dedicated instance ?
Thanks in advance,
Kévin
pa...@google.com
At the time of writing this, creating a dedicated instance which will serve as a load balancer between regions, is the best workable option for this type of scenario.
ji...@nuro.ai
I have the exact same feature request to access ILB from multi regions. It would be great if Google can prioritize this feature. Thanks.
el...@google.com
at...@google.com
ge...@google.com
Hi, please take a look at my update to the public feature request:
https://b.corp.google.com/issues/111021512#comment37
You'll be pleased to note that GKE 1.16 allows you to annotate a service of type LoadBalancer such that it is both internal and globally accessible. We can close out this issue now.
You'll be pleased to note that GKE 1.16 allows you to annotate a service of type LoadBalancer such that it is both internal and globally accessible. We can close out this issue now.
Description
Problem you have encountered:
I use subnet for regions on gcp inside a global vpc network, europe-west1 and asia-south1
I have created a local loadbalancer tcp on one of the region on europe-west1, and i can't access it on asia-south1
i.e :
VPC -> production-network with 2 subnets
subnet-1 in europe-west1 with
subnet-2 in asia-south1 with
From asia-south1 i can access all vm on europe-west1, so no routing issue, firewall on internal loadbalancer is correctly set with allow
I am able to access the service directly on intances so it's clearly that i don't reach the loadbalancer ip in the subnet
So my guess is as routing on gcp network is pretty awkward : all vm are with /32 addressing instead of classical networking and all networking routes are handle by upper layer on gcp side, allowing to insure filtering and all. And this case doesn't handle request comming from other subnet than the subnet where the internal loadbalancer is declared.
There is no technical reason that access a internal loadbalancer should be only one region while regions subnet are in same VPC.
I checked on interface and i am not able to create an internal loadbalancer with mutli-regions only internet one are allowed. It feels not right to cross the internet to access a local service.
What you expected to happen:
A internal loadbalancer should be like a vm in our vpc and in our subnet so should be accessible from every regions and subnet inside the VPC.
Steps to reproduce:
Create one network with 2 subnetwork one 2 regions, create one http service with and internal loadbalancer pointing to it.
Allow
Other information (workarounds you have tried, documentation consulted, etc):
I have checked if internal loadbalancer ip is routed through a specific route allowing only the specific subnet to be routed but there is no.
I have checked to connect directly to the endpoint service directly and it's working.
Connection to the service from the local subnet is also working correctly.
I have added firewalling to allow all in both subnets.
Nothing changed.
Thanks in advance,
Kévin