我找到了解决方案。
使用下面的yml部署代理,并将部署作为服务公开。最重要的是,使代理监听0.0.0.0,而不是默认的127.0.0.1。所有的秘密,按照谷歌的Cloud SQL的文档
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mysql
spec:
replicas: 1
template:
metadata:
name: mysql
labels:
name: mysql
spec:
containers:
- image: b.gcr.io/cloudsql-docker/gce-proxy:1.05
name: cloudsql-proxy
command: ["/cloud_sql_proxy", "--dir=/cloudsql",
"-instances=MYSQL:ZONE:DATABASE_INSTANCE=tcp:0.0.0.0:3306",
"-credential_file=/secrets/cloudsql/credentials.json"]
volumeMounts:
- name: cloudsql-oauth-credentials
mountPath: /secrets/cloudsql
readOnly: true
- name: ssl-certs
mountPath: /etc/ssl/certs
ports:
- containerPort: 3306
name: mysql
volumes:
- name: cloudsql-oauth-credentials
secret:
secretName: cloudsql-oauth-credentials
- name: ssl-certs
hostPath:
path: /etc/ssl/certs
的解决方案比具有相同部署客户端软件的代理稍贵,因为有一个额外的TCP连接。
但是有很多好处:
- 更简单,不需要修改现有的K8S部署文件
- 允许切换执行到MySQL泊坞容器或使用谷歌云SQL代理无需做任何修改到客户端配置。
我很好奇@Hylton Peimer - 我面临同样的问题:我需要将SQL代理托管在一个单独的窗格中,但是如何让您的两个窗格彼此进行通信?我要么拒绝连接,要么找不到主机名 –
公开部署的Kubernetes服务。然后使用服务的名称。例如上面的“kubectl公开部署mysql”,然后让客户端使用“mysql”,就像您使用主机名一样。 –
虽然我与您分享同样的问题,但在同一个窗格中将代理作为边柜运行有一些很好的理由: - 通过将代理公开给集群,您将失去对哪些服务有权访问的控制权,除非您以其他方式保护它 - 不使用标签和选择器,您不能确定每个节点上运行的代理程序包都需要它,这可能会影响性能,具体取决于客户端需要与服务器交谈以及如果该客户端恰好与代理位于同一节点上。 – Khash