无法通过CloudSqlProxy Sidecar从Kubernetes集群连接CloudSql，报ETIMEDOUT错误

从你给出的日志和代码来看，Cloud SQL Proxy已经正常启动并监听了127.0.0.1:3306，但你的Node.js应用却连不上，报超时错误。这种情况大概率是网络访问的隔离问题，下面分场景给你具体的解决方法：

常见原因及解决方案 #

1. Node.js应用和Cloud SQL Proxy不在同一个容器/环境 #

如果你的应用和Proxy是分开部署的（比如两个Docker容器，或者Proxy在容器里、应用在宿主机），那Proxy默认监听的127.0.0.1只允许容器内部访问，外部根本连不上。

解决步骤：

• 修改Cloud SQL Proxy的监听地址：启动Proxy时，把监听地址改成0.0.0.0:3306，让它接受来自所有网卡的连接。启动命令示例：

  cloud_sql_proxy -instances=estatelion-test-275318:us-central1:estatelion=tcp:0.0.0.0:3306 -credential_file=/path/to/your/credential.json
  

• 调整Node.js的连接host：
  • 如果是Docker Compose部署，把host改成Proxy容器的服务名（比如你的Proxy服务叫cloudsql-proxy，就设host: "cloudsql-proxy"）；
  • 如果是本地Docker+宿主机应用，确保启动Proxy时加了端口映射-p 3306:3306，然后应用的host保持localhost即可；
  • 如果是Kubernetes，用Proxy的Service名称作为host。

2. 端口映射未配置（本地Docker场景） #

如果你在本地用Docker跑Proxy，但没做端口映射，宿主机的localhost:3306根本不会转发到容器内部。启动Proxy时一定要加上端口映射参数：

docker run -d -p 3306:3306 -v /local/path/to/credential.json:/tmp/cred.json gcr.io/cloudsql-docker/gce-proxy:latest /cloud_sql_proxy -instances=estatelion-test-275318:us-central1:estatelion=tcp:0.0.0.0:3306 -credential_file=/tmp/cred.json

3. 同一容器内的特殊情况（少见） #

如果应用和Proxy在同一个容器里还是连不上，检查下是不是容器内的网络限制，或者尝试把host改成127.0.0.1而不是localhost（有些环境下localhost解析可能有问题）。

验证方法 #

修改配置后，你可以先在应用所在的环境里用telnet或者nc测试连接：

telnet <your-proxy-host> 3306
# 或者
nc -zv <your-proxy-host> 3306

如果能通，说明网络没问题，再重启Node.js应用应该就能正常连接了。

内容的提问来源于stack exchange，提问作者Amit Sharma