0

我的云 sql 代理以前在 sidecar 模式下工作，但在repo的 Kubernetes 集群中找到了 Cloud SQL 代理cloudsql-proxy，所以我决定自己打破它。

我立即遇到了问题，第一次连接时容器会崩溃。我决定回到尽可能纯粹的测试用例，并添加一个livenessProbe.

我发现这个推荐的配置会自行崩溃：

❯❯❯ kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
cloudsqlproxy-109958711-ks4bf   1/1       Running   5          2m

部署：

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: cloudsqlproxy
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: cloudsqlproxy
    spec:
      containers:
      - image: gcr.io/cloudsql-docker/gce-proxy:1.09
        name: cloudsqlproxy
        command: "/cloud_sql_proxy", "--dir=/cloudsql",
                  "-instances=foo:us-central1:db=tcp:3306",
                  "-credential_file=/secrets/cloudsql/credentials.json"]
        ports:
        - name: port-db
          containerPort: 3306

        livenessProbe:
          exec:
            command: ["netcat", "-U", "/cloudsql/foo:us-central1:db=tcp:3306"]
          initialDelaySeconds: 5
          timeoutSeconds: 10

        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: ssl-certs
            mountPath: /etc/ssl/certs
          - name: cloudsql
            mountPath: /cloudsql
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: ssl-certs
          hostPath:
            path: /etc/ssl/certs
        - name: cloudsql
          emptyDir:

服务：

apiVersion: v1
kind: Service
metadata:
  name: cloudsqlproxy-service
spec:
  ports:
  - port: 3306
    targetPort: port-db
  selector:
    app: cloudsqlproxy

除了启动和收听之外，日志什么也没有显示：

E  2017/10/09 13:51:35 Listening on 127.0.0.1:3306 for foo:us-central1:db
E  2017/10/09 13:51:35 Ready for new connections
E  2017/10/09 13:52:38 using credential file for authentication; email=cloud-sql-client@foo.iam.gserviceaccount.com
E  2017/10/09 13:52:38 Listening on 127.0.0.1:3306 for foo:us-central1:db
E  2017/10/09 13:52:38 Ready for new connections
E  2017/10/09 13:54:26 using credential file for authentication; email=cloud-sql-client@foo.iam.gserviceaccount.com
E  2017/10/09 13:54:26 Listening on 127.0.0.1:3306 for foo:us-central1:db
E  2017/10/09 13:54:26 Ready for new connections

我错过了什么？我应该在哪里寻找崩溃的原因？我有配置错误吗？

4

2 回答 2

0

我的环境中似乎存在权限问题和错误？失败没有被记录。我只能在部署为 sidecar 时获取日志。

2017/10/09 15:34:10 using credential file for authentication; email=cloud-sql-client@foo.iam.gserviceaccount.com
2017/10/09 15:34:10 Listening on 127.0.0.1:3306 for foo:us-central1:db
2017/10/09 15:34:10 Ready for new connections
2017/10/09 15:34:30 New connection for "foo:us-central1:db"
2017/10/09 15:34:30 couldn't connect to "foo:us-central1:db": ensure that the account has access to "foo:us-central1:db" (and make sure there's no typo in that name). Error during createEphemeral for foo:us-central1:db: googleapi: Error 403: The client is not authorized to make this request., notAuthorized
2017/10/09 15:34:30 New connection for "foo:us-central1:db"

此时我将重新创建权限并从我的 Sidecar 原型重试，然后返回到隔离部署。

于 2017-10-09T17:23:48.573 回答
0

我认为您应该-instances=foo:us-central1:db=tcp:3306在配置中替换为-instances=foo:us-central1:db=tcp:0.0.0.0:3306

于 2020-12-17T07:54:02.820 回答