I am trying to connect a VPC with GKE to a Cloud SQL database.
I have specified a VPC with the following details:
IP ranges gateway
10.240.0.0/24 10.240.0.1
I see that all my GKE services are in 10.39.xxx.xx
NAME CLUSTER_IP
service/kubernetes 10.39.240.1 ....
service/api 10.39.xxx.xx
service/web 10.39.xxx.xx
I don't actually understand the connection with the VPC here. I want to have the GKE cluster able to communicate with a Cloud SQL database without exposing it over the public internet.
I have a Cloud SQL db on public IP, say, 36.241.123.123 with a private IP equal to 10.7.224.3.
In SQL - Connections I check the private IP box and given the choice between default and dev-vpc which is the name of my VPC, I select dev-vpc.
According to https://cloud.google.com/sql/docs/mysql/configure-private-ip I should be done now, but I am unable to connect to the Cloud SQL from my GKE cluster.
I do see the following message when selecting the private IP.
Private IP connectivity requires additional APIs and permissions. You may need to contact your organisation's administrator for help enabling or using this feature. Currently, Private IP cannot be disabled once it has been enabled.
I also have a VPC peering connection
Peering connection details
imported routes
10.7.224.0/24 [ the Cloud SQL internal IP is in this ]
exported routes
10.240.0.0/24 [ the VPC subrange ]
What am I missing?
The GKE cluster needs to be on the same VPC in order to have access to other services on that Private IP. This means you have to create a VPC-native cluster.
If you created your cluster before Cloud SQL had support for private IP, you need to recreate your cluster, I'm not sure why but most of the changes involving networking in GCP you have to recreate your cluster.
Related
I have an architectural issue with Cloud SQL.
We have an API that is running in a GKE cluster in a network A and a cloud SQL instance in a network B. The current network config doesn't allow peering between these 2 networks. Is there any possibility to connect the API to the instance.
As # Ferregina suggested:
The bastion hosts provide secure access to Linux instances located in the private and public subnets of your virtual private cloud (VPC). The solution sets up a Multi-AZ environment and deploys Linux bastion host instances into the public subnets.
As mentioned in the document:
To connect to a Cloud SQL instance using private IP, the Cloud SQL
Auth proxy must be on a resource with access to the same VPC network
as the instance.
Refer to this link for more information.
I'm looking for a solution (maybe this isn't the best way) to get an app running on one of our GKE clusters in Project-A, to access a Cloud SQL instance in Project-B, over it's an internal IP and ideally via cloud SQL proxy. Some more info:
We have VPC peering in between project-A and Project-B, traffic from both VPC's definitely flows fine
We have Cloud SQL proxy running in GKE cluster in project-A with the SQL instance in Project-B defined
The cloud SQL instance only has an internal Private IP
Pods from GKE cluster in Project-B can access Cloud SQL in the same project (Project-B) so I know the internal connectivity is definitely there
Only when we briefly add a public IP to the cloud SQL instance in project B, does the connection work from project A via Cloud SQL Proxy
When I try from Project-A to project-B, we get connection time outs.
I understand that when creating a cloud sql instance with an internal IP, that there is another separate VPC peering connection created called servicenetworking-googleapis.com from the VPC in that same project.
My thoughts here, being from a networking background, is that there is no IP route in project-A, to tell pod traffic to go over the VPC peering connection between the 2 projects if it wants to get to the private IP of the cloud SQL instance.
But I wondered if anyone else has tried to same thing.
I've found in documentation, that transitive peering is not supported. Haven't tried it myself, but it seems that recommended way is to use shared VPC for accessing CloudSQL from multiple projects.
In this section:
https://cloud.google.com/sql/docs/mysql/private-ip#quick-reference
Transitive peering
Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
Clients in one project can connect to Cloud SQL instances in multiple projects using Shared VPC networks.
You can use the following guide to set up a Shared VPC between your projects. In summary, it involves the following steps:
Set the project that hosts your Cloud SQL instance as a host project, since it is the one sharing the resources which in this case includes your Cloud SQL instance.
Select the subnets you would like to share to other projects
Set the project where your GKE cluster is hosted as the service project. This service project can then be attached to the host project set up previously.
Attach the service project to the host project and set up the appropriate VPC administrator roles so that users from the service project are allowed access to the shared resources.
As mentioned in another answer, VPC peering is not transitive. So even though there's a VPC peering between Project A and Project B, that does not mean Project A can communicate with the private IP Cloud SQL instance (which is deployed inside another VPC peered within Project B).
As a workaround, you can deploy a SOCKS5 proxy in Project B and have Project A connect to it using the Cloud SQL Proxy.
ALL_PROXY=socks5://localhost:8000 cloud_sql_proxy \
-instances=$INSTANCE_CONNECTION_NAME=tcp:5432
Problem:
Hello, I have recently started using GCP. For a task, it is requied to connect my cloud sql instance with only private-ip present in my 'prod' project in 'vpc2' to an vm launched in diff project 'dev' in 'vpc1'.
Solution attempt:
I have made a private service connection from 'vpc2' for providing private-ip to my sql instance. and also i have done vpc peering b/w vpc1 & vpc2 with import/export of custom routes enabled.
But i am unable to access sql from vm.Curently i dont want to use shared vpc or sql proxy feature.
Thanks.
Actually, when you create a private IP for your Cloud SQL database, you create a peering between your VPC network and the Google Managed Network for your Cloud SQL instances. Therefore, you can't create another peering because you break the peering transitivity rule
Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
There is several solution for this:
Set a public IP on the Cloud SQL instance, without any allowed network (for security reason) and use Cloud SQL proxy in your Dev project. It will be able to connect to the CLoud SQL instance through the public IP and with an encrypted protocol. But you don't want to use Cloud SQL proxy; and in addition you need to add a public IP on your prod Cloud SQL instance, you might be not authorized to do this!
Set up a Shared VPC. But it's not very easy to manage with lot of service limitation. And you don't want to use this solution
My latest bullet is to set up a Cloud VPN between your projects. It's a workaround but it works fine.
I had a similar problem, I have 2 projects A and B, and I needed to access the cloud sql instance in project B from project A I created a simple VPN instance with pritunl,configured the routes inside pritunl, after that I just created a VPN Ipsec between project A and B, with custom routes to the cloud sql, and it worked, now I can access the database using internal IP from my laptop locally.
I have an AWS account with an EC2 in it that I am trying to connect to a Cloud SQL Server (MySQL 5.6) inside of Google Cloud Platform.
I have successfully set up a VPN between AWS and GCP and can echo a message over nc between an ec2 on AWS and a vm on GCP.
As GCP managed DB's are not placed inside of a VPC of my choosing I followed this guide to give the DB a private IP and to then peer that with my google VPC. I tested this works by accessing the DB via pymsql from an VM in GCP using the private IP of the DB.
However my issues come from connecting the EC2 inside of AWS to the Cloud SQL DB in the same way, I have followed this guide to allow the use of the DB's private IP from an external source but I seem to be getting stuck with how to set the routing up to the peered network the DB is sitting in using AWS Routing.
The problem has been sorted!
In the Advertised routes Settings of my Cloud Router, I had misunderstood the function of Advertise all subnets visible to the Cloud Router (Default)
I needed to instead choose Create custom routes" And then the sub-option Advertise all subnets visible to the Cloud Router.
This then allowed me to add the Cloud SQL subnet to my router to that IP block propagate over to AWS.
I have a postgreSQL CLoud SQL instance which I am connecting to via UNIX socket and the instance name from a Cloud Run container as per the documentation. With a public IP, this connection works fine. I was looking to turn off the public IP and only have a private IP, so I would not be charged for the public IP going forward.
When I first created the Cloud SQL instance, I only enabled the public IP. A couple of days later I enabled the private IP. For the assocaited network for the private IP, I accepted the default as the Cloud Run instance is in the same project.
When I turn off the public IP, my application can no longer connect to the Cloud SQL instance. I get a connection refused error:
sqlalchemy.exc.InterfaceError: (pg8000.core.InterfaceError) ('communication error', ConnectionRefusedError(111, 'Connection refused'))
As stated above, I did follow the instruaction on the Connecting to Cloud SQL from Cloud Run page:
https://cloud.google.com/sql/docs/postgres/connect-run
I even ran the gcloud command to update an the exsiting deployed revision after turning off the public IP and only having the private IP available but it made no difference.
Is a public IP required for a connection from Cloud Run to Cloud SQL? I do not see that in the connection documentation page. Or is there something else I missed when trying to switch over to only having a private IP? Or do I need to create a new Cloud Instance without a public IP and go through the instructions for connecting Cloud Run via an instance anme again?
Is a public IP required for a connection from Cloud Run to Cloud SQL? I do not see that in the connection documentation page.
On the Connecting to Cloud SQL from Cloud Run page, it says "Note: These instructions require your Cloud SQL instance to have a public IP address configured."
Private IP access is access from a Virtual Private Cloud (VPC). In order to access your instance through a VPC, the resource you are connecting to needs to be a part of the VPC. Cloud Run doesn't currently support VPC access, so you'll need to use have a public IP for now.
TL;DR: Open a case to the Google support
Your case is interesting because, by design, I think it's not yet supported.
In fact, when you create a Cloud SQL database with a private IP, a network peering is done between your VPC and the Cloud SQL VPC (or something equivalent).
In addition, today, it's not possible to plug your Cloud Run instance to your VPC. With function and App Engine, you have a serverless VPC connector, and not yet with Cloud Run (it's coming!).
The serverless VPC connector perform the same things as the Cloud SQL private IP, I mean a peering between your VPC and the Cloud Functions (or App Engine) VPC (or something equivalent).
And even if the serverless VPC connector is available on Cloud Run, it's not sure that it work because of network peering transitivity. In short, If you have a peering between VPC A -> VPC B and between VPC B -> VPC C, you can't reach VPC C from VPC A by performing an hop in VPC B. Replace A by VPC Cloud Run, B by VPC of your project, and C by VPC Cloud SQL.
Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering.
I didn't check with AppEngine or Cloud Function, but this design shouldn't work.
But I'm not sure, that's why a case to the Google support will allow you to have a clear answer and maybe inputs on the roadmap. Any valuable information from Google Support are welcomed here!
I was also getting the following error when I was trying to connect to postgres using the following command from cloud shell:
gcloud sql connect
it seems your client does not have ipv6 connectivity...
What I do is that I login to one of the pods deployed using Google cloud Kubernetes using the following command:
kubectl exec --stdin --tty java-hello-world-7fdecb9894-smql4 -- /bin/bash
Then for 1st time I ran:
apt-get update
apt install postgresql-client
And now I can connect using:
psql -h postgres-private-ip -U username