На основании своего страница github, рекомендуется настроить как дополнительный контейнер, а не как кластерную службу. Мой вопрос: есть ли какие-либо возможные проблемы (например, производительность, количество подключений), если у меня много модулей с облачным прокси-сервером sql в качестве контейнера sidecar? Вместо этого кажется разумным создать сервис.
Дайте мне знать, если я что-нибудь упустил.
Публикация этого ответа как вики сообщества, поскольку ответ на этот вопрос может быть самоуверенным.
На основании своего страница github, рекомендуется настроить как дополнительный контейнер, а не как кластерную службу.
Не только упомянутый вами сайт, но и официальная документация CloudSQL:
Чтобы получить доступ к экземпляру Cloud SQL из приложения, работающего в Google Kubernetes Engine, вы можете использовать прокси-сервер Cloud SQL (с общедоступным или частным IP-адресом) или подключиться напрямую с помощью частного IP-адреса.
Прокси-сервер Cloud SQL - рекомендуемый способ подключения к Cloud SQL., даже при использовании частного IP. Это связано с тем, что прокси-сервер обеспечивает надежное шифрование и аутентификацию с использованием IAM, что может помочь защитить вашу базу данных.
Cloud.google.com: SQL: Документы: MySQL: Подключение Kubernetes Engine: Введение
Вместо этого кажется разумным создать сервис.
Вы можете прочитать, почему использование прокси-сервера более рекомендуется вместо создания службы:
Мы рекомендуем использовать эту услугу как отдельную по нескольким причинам:
- Предотвращает локальный доступ к вашему SQL-трафику; прокси-сервер обеспечивает шифрование исходящих подключений, но вам необходимо ограничить уязвимость для входящих подключений
- Предотвращает единую точку отказа; доступ каждого приложения к вашей базе данных независим от других, что делает его более устойчивым.
- Ограничивает доступ к прокси-серверу, позволяя использовать разрешения IAM для каждого приложения, а не раскрывать базу данных для всего кластера.
- Позволяет более точно определять область запросов ресурсов; поскольку прокси-сервер потребляет ресурсы линейно по мере использования, этот шаблон позволяет более точно определять и запрашивать ресурсы в соответствии с вашими приложениями по мере его масштабирования.
Что касается количества активных подключений (оно зависит от используемого решения):
Также может быть выгодно добавить (эффективное управление подключениями к базе данных):
Дополнительные ресурсы: