Блог

У меня есть 2 кластера GKE, как частных, так и общедоступных, и я использую cloudproxy в качестве контейнера sidecar для приложения gke для доступа к экземпляру cloudsql.

настройка общедоступного кластера для разработки / тестирования

Облачный SQL включен как с частным, так и с общедоступным IP. Приложение GKE использует cloudproxy с опцией типов IP по умолчанию (общедоступный, частный), как показано ниже, у Cloud SQL нет авторизованной сети.

В этом случае мое приложение может подключать CloudSQL и работает бесперебойно. Насколько я понимаю, здесь подключение к cloudsql должно происходить с помощью private, поскольку авторизованная сеть не настроена.

настройка частного кластера для производства

Облачный SQL включен как с частным, так и с общедоступным IP. Приложение GKE использует cloudproxy с параметрами типов IP по умолчанию (общедоступный, частный)

cloudsql- настройка прокси-сервера в файле развертывания

   - name: cloudsql-proxy
    image: gcr.io/cloudsql-docker/gce-proxy:1.11
    command: ["/cloud_sql_proxy"]
    args: ["-instances=$(REAL_DB_HOST)=tcp:$(REAL_DB_PORT)","-credential_file=/secrets/cloudsql/credentials.json"]
  

случай 1
У Cloud SQL нет авторизованной сети.
Результат: приложение не может подключиться к Cloud SQL

случай 2 Облачный SQL имеет частный шлюз GKE NAT в качестве авторизованной сети Результат: приложение не может подключиться к Cloud SQL

Возможно, удаление cloudproxy из приложения будет работать (мне еще предстоит протестировать), но это препятствует использованию прокси во время разработки, поскольку для этого потребуются изменения в файле развертывания во время производственного развертывания.

Я не могу понять, что вызывает сбой соединения с cloudproxy в частном кластере gke. Не следует ли нам использовать cloudproxy в частном кластере?

Обновить Причину, по которой облачный прокси-сервер не может подключиться к cloud sql, был отключен Cloud SQL Admin API. Я обновил свой ответ в разделе ответов.

Похоже, что вопрос здесь звучит так: «Должны ли мы использовать прокси-сервер Cloud SQL в частном кластере?» и этот ответ «это зависит». Подключение не требуется, но оно обеспечивает большую безопасность, поскольку вы можете ограничить ненужный доступ к вашему облачному серверу SQL.

Прокси-сервер Cloud SQL не обеспечивает подключение вашего приложения — он обеспечивает только аутентификацию. Он должен иметь возможность подключаться по существующему пути, но затем использует роли IAM учетной записи службы для аутентификации соединения. Это также означает, что оно не обязательно должно поступать из сети, внесенной в белый список, поскольку оно было аутентифицировано другим способом.

Если вы хотите использовать прокси для подключения через частный IP (вместо общедоступного по умолчанию), используйте -ip_address_types=PRIVATE — это укажет прокси-серверу вместо этого подключиться к частному IP экземпляра. (Пожалуйста, обратите внимание, что если прокси-серверу не хватает сетевого пути (например, не на VPC), этот прокси-сервер все равно не сможет подключиться.)

@kurtisvg предоставил на него информативный ответ.

Однако реальной проблемой был SQL Admin API, и его включение устранило проблему. После просмотра журналов я нашел запись ниже.

Ошибка 403: доступ не настроен. API администратора Cloud SQL ранее не использовался в project XXXXXX или он отключен. Включите его, посетивhttps://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?

Проблема для меня заключалась в включении Private cluster в кластере GKE:(

Из-за частного кластера GKE у него не было доступа к внешним IP-адресам, и исправление заключалось в создании шлюза NAT с облачным маршрутизатором в соответствии с https://cloud.google.com/nat/docs/gke-example.

Подсказка, если проблема в том, что вы не сможете выполнить пинг к google.com и т.д. из контейнера после входа в него.