Assigned
Status Update
No update yet.
Comments
ch...@google.com
Hello,
Thanks for reaching out to us!
The feature request has been created and the Product Engineering Team is working on this request. At this moment, there is no ETA to this request. Thank you for your trust and continued support to improve Google Cloud Platform products . In case you want to report a new issue, please do not hesitate to create a new Issue Tracker thread describing your issue.
se...@gmail.com
This is a very much needed feature.
Tried to find a solution for this for the last couple of days and all I can find refers to proxies which I would like to avoid as much as possible.
In my case I have a "Network" Project with its own VPC - used mainly as the entry point ("VPN") - and VPC Peering in place between this and other individual Projects (Dev, QA, Stage, Prod etc.).
I am not able to access the "Dev" GKE API / endpoint from any other non-"Dev" VPCs and the is a show stopper.
Tried to find a solution for this for the last couple of days and all I can find refers to proxies which I would like to avoid as much as possible.
In my case I have a "Network" Project with its own VPC - used mainly as the entry point ("VPN") - and VPC Peering in place between this and other individual Projects (Dev, QA, Stage, Prod etc.).
I am not able to access the "Dev" GKE API / endpoint from any other non-"Dev" VPCs and the is a show stopper.
[Deleted User] <[Deleted User]>
I am facing the same issue.
Hoping this "feature" / issue get solve soon.
Hoping this "feature" / issue get solve soon.
et...@accenture.com
Users are forced to use very hacky workarounds
e.g.:
Plus this issue is bigger : It is related to how peering with google projects works. All managed services using peering are impacted (e.g. postgreSQL)
IMO there should be an option to either
- peer with multiple VPC
- or make routing easy by allowing route exporting to other VPC
fa...@arkea.com
I am also facing the same issue, and I also share the idea that routing should be made easier by allowing routes to other VPC.
as...@orca.security
I am facing the same issue, any update regarding this issue?
a....@team.bumble.com
I have a similar situation, but VPC A and VPC B are shared from another project.
I have a workaround for this issue:
There is a special natgateway VM that has 2 interfaces, one in VPC A and another in VPC B. There are NAT rules to forward traffic from VPC A to VPC B
There is a custom route to GKE-control-plane-ip in VPC A that point to this VM to IP address from VPC A.
Exchanging custom routes is enabled in peering between VPC B and GKE-controlplane-VPC.
It looks like proxy VM, but not needed to disable cert validation, because GKE-control-plane-ip is the same.
I think this workaround could be adjusted if you can't create natgateway VM with interfaces in 2 VPC by creating 2 natgateway VM in both VPCs and forward traffic from VM in VPC A to VM in VPC B
I have a workaround for this issue:
There is a special natgateway VM that has 2 interfaces, one in VPC A and another in VPC B. There are NAT rules to forward traffic from VPC A to VPC B
There is a custom route to GKE-control-plane-ip in VPC A that point to this VM to IP address from VPC A.
Exchanging custom routes is enabled in peering between VPC B and GKE-controlplane-VPC.
It looks like proxy VM, but not needed to disable cert validation, because GKE-control-plane-ip is the same.
I think this workaround could be adjusted if you can't create natgateway VM with interfaces in 2 VPC by creating 2 natgateway VM in both VPCs and forward traffic from VM in VPC A to VM in VPC B
ru...@timbrasil.com.br
So, public GKE endpoint idea is too dangerous to me. Even if I set VPC-Service-Controls.
I found this to deploy a Proxy but many people said we lost TLS:
ch...@google.com
ch...@google.com
ch...@google.com
ch...@google.com
ob...@ordaos.bio
Any ETA on this? do we have to implement workarounds even to be able to use cloud build with private clusters?!!
fa...@celfocus.com
Any update on this @Google?
mo...@gmail.com
Any update on this @google?
di...@gmail.com
We are experiencing the same problem. GKE cluster is peered with a spoke VPC, which is peered with the hub one. Transitive Peering does not work, and we cannot setup a new vpc peering connection from the GKE control plane to the hub VPC, thus it is unreachable. The only feasible way we think would work is to have some sort of a VM as a proxy which would leverage multiple network interfaces in each different VPC that has access to the various GKE control plane address ranges https://www.youtube.com/watch?v=iq2lPkev3NA
Would be super great if we could simply create another peering connection, directly towards the GCP-managed control plane GKE cidr 👍
Would be super great if we could simply create another peering connection, directly towards the GCP-managed control plane GKE cidr 👍
ms...@google.com
Comment has been deleted.
ms...@google.com
Comment has been deleted.
ts...@google.com
Hello, VPC peering is not transitive between VPCs connected via private peering. However when GKE is used with Private Service Connect (PSC) to the customer's VPCs in their project, this VPC can be connected to other VPCs via Network Connectivity Center (NCC) with PSC propagation enabled, at which point the GKE service can be reached transitively by other VPCs connected via NCC on the same NCC hub. This feature was recently launched in public preview and additional details can be had here.
https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/psc-propagated-connection-overview
Description
Please provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible please provide a summary of what steps or workarounds you have already tried, and any docs or articles you found (un)helpful.
Problem you have encountered:
According to google: "transitive VPC is not supported by GKE with private IP.
This means GKE with a private IP can only communicate with directly attached VPC networks and no one else.
GKE defaults to public IP for k8s API, so many customers are not aware of this aspect.
Many common use cases are not supported due to this limitation, like:
1. VM in peering VPC wants to communicate with GKE in other VPC
2. VPN clients on other VPC wants to communicate with GKE in other VPC.
3. CI/CD systems on other VPC wants to communicate with GKE in other VPC.
this limitation exists only in google's kubernetes service, not on amazon's EKS nor on microsoft's AKS.
the industry has been working around this limitation by expensive solution:
1. Proxy VM on each VPC where GKE is, with disabled certificate validations.
2. Migrating from "VPC peering" (on google backcone) to lower performance "VPN between VPCs" (on public internet).
3. GKE with public IP (for k8s API).
4, VPN access to each individual VPC and VPN clients forced to jump between VPNs.
How hard is it to develop a feature to allow GKE private endpoints to communicate with any customer VPC ?
What you expected to happen:
GKE private endpoints to communicate with any customer VPC.
Steps to reproduce:
1. Create 2 VPCs in 2 projects (or in same project)
2. Create VPC peering between the 2 VPC.
3. Create private GKE on one of the VPC.
4. Make sure all configurations per good documentation, include authorised networks for GKE.
5. Export/Import networks with the GKE.
6. Place VM on each of the 2 VPC.
7. VM in the same VPC where GKE is can communicate , VM on other VPC can not communicate
Other information (workarounds you have tried, documentation consulted, etc):
Opened a case with google support, confirmed this limitation exists in GCP as of Sep 2022.