Сбой облачного прокси-сервера sql в kubernetes

Мой облачный прокси-сервер sql ранее работал в шаблоне sidecar, но обнаружил Cloud SQL Proxy в кластере Kubernetes в репозитории 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 protected]
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 protected]
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

Что мне не хватает? Где я должен искать, чтобы найти причину сбоя? У меня ошибка конфигурации?


kubernetes google-kubernetes-engine cloud-sql-proxy
person kross    schedule 09.10.2017    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Похоже, в моей среде возникла проблема с разрешениями и ошибка? с ошибкой, которая не регистрируется. Я смог получить журнал только при развертывании в качестве коляски.

2017/10/09 15:34:10 using credential file for authentication; [email protected]
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, а затем вернусь к изолированному развертыванию.

person kross    schedule 09.10.2017

arrow_upward
0
arrow_downward

Я думаю, вам следует заменить -instances=foo:us-central1:db=tcp:3306 в вашей конфигурации на -instances=foo:us-central1:db=tcp:0.0.0.0:3306

person Katerina Mpagouli    schedule 17.12.2020