Как мне разрешить мои эфемерные экземпляры контейнера Google в Cloud SQL?

Question

Я в настоящее время тестирую Google Container Engine (GKE) и Kubernetes как возможную замену развертыванию AWS/ElasticBeanstalk. По моему мнению, именно благодаря моим динамическим серверам, которые находятся в одном проекте с облачным sql-экземпляром, они, естественно, будут включены в правила брандмауэра этого проекта. Однако, похоже, это не так. Мои серверы приложений и SQL-сервер находятся в одной и той же зоне доступности, и у меня есть оба ipv4 и ipv6 включены на сервере sql.

Я не хочу статически назначать IP-адреса членам кластера, которые сами по себе являются эфемерными, поэтому я ищу руководство по тому, как я могу правильно включить SQL-доступ к моему приложению на докере, размещенному внутри GKE? Как секундомер, я добавил эфемерные IP-адреса узлов кластера кластера, и это позволило мне использовать CloudSQL, но я бы очень хотел иметь более простой способ обработки этого, если мои узлы каким-то образом получат новый IP-адрес.

Answer 1

К сожалению, в настоящее время это единственный способ сделать это. Лучшим вариантом было бы написать контроллер, который динамически изучал группу управляемых экземпляров, созданную GKE, и автоматически обновлял IP-адреса в Cloud SQL API. Но я согласен, что интеграция должна быть более плавной.

Answer 2

Текущие рекомендации (SSL или HAProxy) обсуждаются в [1]. Мы работаем над прокси-сервером клиента, который будет использовать учетные записи служб для аутентификации в Cloud SQL.

[1] Is it possible to connect to Google Cloud SQL from a Google Managed VM?