Fixed
Status Update
Comments
al...@google.com <al...@google.com> #2
I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.
br...@gmail.com <br...@gmail.com> #3
It will give faster access but also allow for encrypted connections since it will be on the private network.
je...@gmail.com <je...@gmail.com> #4
This would also allow us to whitelist an internal network range which is important for allowing access from an instance-group where we don't know what the IPs will be until the instances are generated. Right now we have to manually authorize each IP when a new instance comes online in our instance group.
Also, with the external IP it looks like we incur data charges for going through an external IP:https://cloud.google.com/compute/pricing#network
Also, with the external IP it looks like we incur data charges for going through an external IP:
ke...@king.com <ke...@king.com> #5
Any update on this? AWS allows you to add RDS instances to VPCs. This seems like quite a major feature gap.
[Deleted User] <[Deleted User]> #6
This is a big feature we wish we weren't losing in our migration from RDS as well.
[Deleted User] <[Deleted User]> #7
Yeah we also want this feature, AWS would allow us to do this
ru...@gmail.com <ru...@gmail.com> #8
Please update status when it come live i am also waiting for it.Thanks
im...@auph.me <im...@auph.me> #9
May I know which region are you guys hosting CloudSQL with? I've tried Taiwan, Mumbai and Tokyo, and the latency is really bad for Singapore.
[Deleted User] <[Deleted User]> #10
Same as above, is there an ETA for this?
[Deleted User] <[Deleted User]> #11
"Right now we have to manually authorize each IP when a new instance comes online in our instance group. ".
This is the wrong way, you need to use this :https://cloud.google.com/sql/docs/postgres/sql-proxy
We are using it with autoscaling Kubernetes cluster without setting ACL as it's impossible and it's working fine like this.
This is the wrong way, you need to use this :
We are using it with autoscaling Kubernetes cluster without setting ACL as it's impossible and it's working fine like this.
ke...@gmail.com <ke...@gmail.com> #12
Any update on this Google? It's the #3 issue on the Cloud SQL issue tracker.
Mi...@peopleconnect.us <Mi...@peopleconnect.us> #13
It's pretty great to see private IP addresses in beta on CloudSQL instance. Unfortunately, it doesn't seem that connecting a shared network works at this time. We also did not find a way to select a subnet within that shared network.
This is a pretty key feature that we need with our migration to Google Cloud so that our applications not yet hosted on GCP can connect to our CloudSQL instances over VPN. Any update as to when we'll see the subnet selection support occur?
This is a pretty key feature that we need with our migration to Google Cloud so that our applications not yet hosted on GCP can connect to our CloudSQL instances over VPN. Any update as to when we'll see the subnet selection support occur?
jo...@hellolucy.io <jo...@hellolucy.io> #14
I can't seem to connect to my kubernetes cluster using the private IP generated from SQL.
I tried pinging, telnet, and mysql clients and it just doesn't connect at all. Not sure what I'm doing wrong because I'm following all the documentation on this.
I really would like to avoid the sql-proxy containers because the latency on those were very high.
Has anyone had any success with hitting sql with private IP's?
I tried pinging, telnet, and mysql clients and it just doesn't connect at all. Not sure what I'm doing wrong because I'm following all the documentation on this.
I really would like to avoid the sql-proxy containers because the latency on those were very high.
Has anyone had any success with hitting sql with private IP's?
gy...@tripcreator.com <gy...@tripcreator.com> #15
According to Slack chat "VPC-native (alias IP)" must be enabled on GKE in order to access Postgresql via IP address from GKE pods. Sadly this option cannot be turned only for existing clusters.
[Deleted User] <[Deleted User]> #17
Using the alpha OR beta gcloud, connecting a shared network still does not work.
I get the following error:
"ERROR: (gcloud.beta.sql.instances.create) INTERNAL_ERROR"
I get the following error:
"ERROR: (gcloud.beta.sql.instances.create) INTERNAL_ERROR"
ts...@omr.com <ts...@omr.com> #18
Is there any workaround to turn it on for existing clusters? I heard that creating a route might work?
do...@lextira.ch <do...@lextira.ch> #19
Tried today to connect a new K8s Cluster via private IP address - but there's no answer from the CloudSQL Instance (ping gets lost)
Also tried with a simple ComputeEngine, but also no anser from the CloudSQL Instance.
However, using VPC Peering manually (two VPCs in the same project for test reason), it works fine. So i'd assume, I'm not doing it wrong and neither is VPC Peering in general broken. But there might be some Routing/Firewall/CloudSQL-Instance missconfiguration within the setup process?
Also tried with a simple ComputeEngine, but also no anser from the CloudSQL Instance.
However, using VPC Peering manually (two VPCs in the same project for test reason), it works fine. So i'd assume, I'm not doing it wrong and neither is VPC Peering in general broken. But there might be some Routing/Firewall/CloudSQL-Instance missconfiguration within the setup process?
go...@kedare.net <go...@kedare.net> #20
Afaik you cannot cross VPC boundaries from a Kubernetes Cluster until you deploy it with IP aliases enabled (That require creating a new cluster from scratch)
al...@google.com <al...@google.com>
wl...@fuelmedical.com <wl...@fuelmedical.com> #21
As this feature request was originally written, it appears complete, can we mark this as resolved now?
Description