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

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

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


person Peter Grace    schedule 29.09.2015    source источник


Ответы (2)


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

[1] Можно ли подключиться к Google Cloud SQL с виртуальной машины, управляемой Google?

person Razvan Musaloiu-E.    schedule 30.09.2015
comment
Спасибо, буду следить за клиентским прокси. - person Peter Grace; 30.09.2015
comment
Некоторая документация по использованию прокси от Kubernetes теперь доступна здесь: github. ru / GoogleCloudPlatform / cloudsql-proxy / - person dlorenc; 14.03.2016

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

person Brendan Burns    schedule 30.09.2015