Облачный SQL-прокси в GKE — полное руководство

Здравствуйте, читатели! В этой статье рассказывается о настройке Cloud SQL Proxy в GKE с практической демонстрацией.

Итак, начнем! 😊

Преимущества облачного SQL-прокси

Поскольку приложения переходят на проложенный путь модернизации, компоненты приложений теперь перемещаются для размещения ресурсов в общедоступных облачных средах, таких как Google, Azure, Amazon и т. д.

Важнейшие компоненты, такие как базы данных, кэш-память, теперь проложили путь к модернизации.

Большинство приложений в настоящее время помещаются в контейнеры для оптимизации и сокращения углеродного следа.

Глядя на этот сценарий, должен быть способ или путь для установления соединения между приложениями, размещенными в виде контейнеров, и экземплярами облачной базы данных.

Для этого в игру вступает Cloud SQL Proxy.

С помощью Cloud SQL Proxy мы можем инициировать соединение между контейнерным приложением и экземпляром облачной базы данных.

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

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

Практическая реализация — настройка Cloud SQL Proxy в качестве контейнера/модуля в GKE

Ниже приведен список предварительных условий для создания модуля облачного прокси-сервера SQL.

Полноценный кластер Google Kubernetes Engine с установленным инструментом kubectl.
Если мы хотим использовать подключения через частный IP-адрес, нам необходимо убедиться, что прокси-сервер Cloud SQL и экземпляр базы данных используют одну и ту же сеть VPC.
Облачный экземпляр SQL (MYSQL, PostgreSQL, SQL Server)
Учетная запись в экземпляре PostgreSQL. Приложение, работающее в кластере GKE, будет использовать эти учетные данные для подключения к базе данных.

Шаг 1: Создайте секрет с конфигурациями базы данных

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

Таким образом, нам необходимо заполнить значения конфигурации базы данных в контейнере приложения, чтобы он мог подключиться к настраиваемой базе данных.

Для этого нам нужно создать секрет в том же пространстве имен, которое используется контейнером приложения, как показано ниже:

kubectl create secret generic <YOUR-DB-SECRET> \
  --from-literal=username=<YOUR-DATABASE-USER> \
  --from-literal=password=<YOUR-DATABASE-PASSWORD> \
  --from-literal=database=<YOUR-DATABASE-NAME>

Шаг 2. Получите значения конфигурации экземпляра Cloud SQL

Чтобы подключить приложение к экземпляру базы данных, нам нужно настроить прокси-сервер Cloud SQL либо как виртуальную машину, либо как контейнер (сайдкар). Для этого нам потребуется следующая информация об экземпляре Cloud SQL:

Имя подключения к экземпляру
Включите Cloud SQL Admin API в проекте, который содержит ваш кластер GKE.
Файл ключа JSON (учетных данных) сервисного аккаунта, у которого есть необходимые разрешения для проекта Google, содержащего ресурс Cloud SQL Instance.

Шаг 3. Создайте учетную запись службы, используемую для прокси-сервера Cloud SQL, чтобы иметь ее в GKE.

Чтобы запустить экземпляр Cloud SQL Proxy в кластере GKE, нам нужно создать учетную запись службы и предоставить ей необходимые разрешения.

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

Требования сервисного аккаунта-

Он должен быть создан в том же проекте, в котором запущен экземпляр Cloud SQL.
Ему должна быть назначена как минимум роль IAM клиента Cloud SQL.
В случае использования частного IP-адреса для подключения экземпляр Cloud SQL и GKE должны использовать одну и ту же сеть VPC.

После создания учетной записи службы нам необходимо смонтировать ключ учетной записи службы в контейнер прокси-сервера Cloud SQL в качестве тома из секрета.

Давайте поймем это на примере ниже!

Создайте файл ключа учетных данных с помощью команды gcloud —

gcloud iam service-accounts keys create ~/key.json \

--iam-account=YOUR-SA-NAME@project-id.iam.gserviceaccount.com

Создайте секрет k8 из файла учетных данных -

kubectl create secret generic YOUR-SA-SECRET \

--from-file=service_account.json=~/key.json

Используйте указанный выше секрет как том в прокси-контейнере —

volumes:

- name: <YOUR-SA-SECRET-VOLUME>

  secret:

    secretName: <YOUR-SA-SECRET>

Шаг 4. Запустите прокси-сервер Cloud SQL в качестве вспомогательного компонента или модуля.

Как только мы достигнем шага 4, нам нужно создать контейнер прокси-сервера внутри модуля приложения из-за следующих преимуществ:

Из-за разрешений базы данных IAM использование побочного компонента снижает доступность экземпляра для всего кластера.
Это уменьшает и предотвращает локальное воздействие исходящего трафика SQL за счет его шифрования.

Код -


apiVersion: apps/v1
kind: Deployment
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      containers:
      - name: <YOUR-APPLICATION-NAME>
        # ... other container configuration
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: database
      - name: cloud-sql-proxy
        
        image: gcr.io/cloudsql-docker/gce-proxy:1.28.0 # make sure the use the latest version
        command:
          - "/cloud_sql_proxy"
          - "-ip_address_types=PRIVATE"

          # Replace DB_PORT with the port the proxy should listen on
          # Defaults: MySQL: 3306, Postgres: 5432, SQLServer: 1433
          - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"

          
          - "-credential_file=/secrets/service_account.json"
        securityContext:
          
          runAsNonRoot: true
        volumeMounts:
        - name: <YOUR-SA-SECRET-VOLUME>
          mountPath: /secrets/
          readOnly: true
        resources:
          requests:
            
            memory: "2Gi"
          
            cpu:    "1"
      volumes:
      - name: <YOUR-SA-SECRET-VOLUME>
        secret:
          secretName: <YOUR-SA-SECRET>

Заключение

На этом мы подошли к концу данной темы. Не стесняйтесь комментировать ниже, если у вас возникнут какие-либо вопросы.

Чтобы узнать больше о таких публикациях, связанных с облачными базами данных и родной информацией Kubernetes, оставайтесь с нами.

А пока удачного обучения!! 😊