Доступ из кластера Managed Kubernetes к облачным базам данных и VPS по приватной сети

Приложения в кластере Managed Kubernetes могут обращаться к облачным базам данных и виртуальным серверам (VPS) по приватной сети, без выхода в интернет. Для такого подключения не требуются публичный IP-адрес у базы данных или VPS. 

Как устроено подключение

Кластер, облачные базы данных и VPS аккаунта находятся в одной приватной сети. Ноды кластера подключаются к ней автоматически при создании кластера, и отключить это подключение нельзя. Облачные базы данных доступны в приватной сети без дополнительной настройки, а VPS необходимо подключить к ней вручную.

У каждой ноды кластера два адреса: 

• INTERNAL-IP – адрес в приватной сети;
• EXTERNAL-IP – публичный адрес. 

Посмотреть их можно командой:

kubectl get nodes -o wide

NAME                               STATUS   ROLES    VERSION   INTERNAL-IP   EXTERNAL-IP
xxxxxx-client-xxxxxx-xxxxx-xxxxx   Ready    <none>   v1.36.4   10.16.0.4     203.0.113.10
xxxxxx-client-xxxxxx-xxxxx-xxxxx   Ready    <none>   v1.36.4   10.16.0.28    203.0.113.11

Поды получают доступ к тем же ресурсам приватной сети, что и нода, на которой они запущены, поэтому дополнительная настройка кластера не требуется. При этом трафик из пода поступает к базе данных или VPS с приватного адреса ноды (INTERNAL-IP), а не с адреса пода. Это необходимо учитывать, если на стороне базы данных или сервера настраиваются списки доступа по IP-адресам.

Подключение к облачной базе данных

Для подключения к облачной базе данных понадобятся:

• хост – приватный IP-адрес базы данных, указанный в панели управления;
• порт – стандартный для СУБД (системы управления базами данных): 5432 для PostgreSQL, 3306 для MySQL;
• имя базы данных;
• имя пользователя и пароль.

Данные для подключения указаны в панели управления на главной странице выбранной облачной базы данных. 

Параметры подключения рекомендуется передавать в поды через Secret – объект K8s для хранения конфиденциальных данных. В этом случае пароль не хранится в манифесте в открытом виде.

Создайте пространство имен (namespace), в котором будут размещены параметры подключения и проверочные задачи:

kubectl create namespace db-test

Затем создайте в нем Secret, указав параметры своей базы данных:

kubectl -n db-test create secret generic external-db \
  --from-literal=DB_HOST='<приватный_IP>' \
  --from-literal=DB_PORT='<порт>' \
  --from-literal=DB_NAME='<имя_бд>' \
  --from-literal=DB_USER='<имя_пользователя>' \
  --from-literal=DB_PASSWORD='<пароль>'

Для PostgreSQL в параметре DB_PORT укажите значение 5432, а для MySQL – 3306.

Подключение к VPS

Чтобы обращаться к VPS из кластера Kubernetes, подключите сервер к приватной сети по инструкции из статьи «Как подключить VPS к приватной сети». При подключении укажите IP-адрес из приватного блока 10.0.0.0/8. В зависимости от региона адрес выдается из соответствующей подсети с маской /16.

Приватный адрес VPS отличается от публичного, и из кластера необходимо обращаться именно по приватному адресу. Он отображается в панели управления, а на самом сервере его можно посмотреть командой:

ip -4 addr

Приватный адрес назначается отдельному сетевому интерфейсу:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 203.0.113.20/32 brd 203.0.113.20 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 ...
    inet 10.16.0.8/16 brd 10.16.255.255 scope global eth1

В этом примере 203.0.113.20 – публичный адрес сервера, а 10.16.0.8 – приватный.

Сервис на VPS, к которому подключаются приложения из кластера, должен принимать подключения на приватном интерфейсе. Если сервис слушает только адрес 127.0.0.1, подключения из кластера до него не дойдут. Кроме того, порт сервиса должен быть разрешен в файрволе (межсетевом экране) VPS. Например, при использовании ufw:

ufw allow <порт>/tcp

Проверка подключения

Проверку подключения выполнить двумя разными способами: 

• доступность порта ресурса из кластера; 
• подключение к базе данных с учетными данными.

Первый способ одинаков для облачной базы данных и VPS, второй – выполняется только для базы данных.

Для проверки доступности порта запустите временный под с утилитой nc, которая пытается установить соединение с указанным адресом и портом. Учетные данные для этого не требуются:

kubectl run netcheck --rm -it --image=busybox:1.36 --restart=Never -- nc -zv 10.16.0.2 5432

Вместо 10.16.0.2 и 5432 укажите приватный адрес и порт своего ресурса: для облачной базы данных – адрес и порт базы, для VPS – приватный адрес сервера и порт сервиса, запущенного на нем. Параметр --rm удаляет под после завершения проверки.

Если порт доступен, в выводе появится строка:

10.16.0.2 (10.16.0.2:5432) open

Если порт облачной базы данных доступен, проверьте подключение к ней с учетными данными. Для этого используется Job – задача Kubernetes, которая выполняется один раз и завершается. Job запускает под с клиентом СУБД, который подключается к базе данных с параметрами из созданного ранее Secret и выполняет тестовый запрос.

Для PostgreSQL сохраните манифест в файл pg-check.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  name: pg-check
  namespace: db-test
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 60
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: pg-check
          image: postgres:16-alpine
          envFrom:
            - secretRef:
                name: external-db
          command:
            - /bin/sh
            - -ec
            - |
              export PGPASSWORD="$DB_PASSWORD"
              export PGCONNECT_TIMEOUT=10
              psql -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$DB_NAME" \
                -c 'SELECT current_database(), current_user, now();'

Примените манифест и выведите результат выполнения:

kubectl apply -f pg-check.yaml
kubectl -n db-test logs -f job/pg-check

При успешном подключении запрос вернет имя базы, имя пользователя и текущее время сервера:

 current_database | current_user |              now
------------------+--------------+-------------------------------
 example_db       | example_user | 2026-09-07 17:35:44.117236+03
(1 row)

Для MySQL сохраните манифест в файл mysql-check.yaml:

apiVersion: batch/v1
kind: Job
metadata:
  name: mysql-check
  namespace: db-test
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 60
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: mysql-check
          image: mysql:8.4
          envFrom:
            - secretRef:
                name: external-db
          command:
            - /bin/sh
            - -ec
            - |
              export MYSQL_PWD="$DB_PASSWORD"
              mysql -h "$DB_HOST" -P "$DB_PORT" -u "$DB_USER" \
                --connect-timeout=10 --ssl-mode=PREFERRED "$DB_NAME" \
                -e 'SELECT DATABASE(), CURRENT_USER(), NOW();'

Примените манифест и выведите результат выполнения:

kubectl apply -f mysql-check.yaml
kubectl -n db-test logs -f job/mysql-check

При успешном подключении запрос также вернет имя базы, имя пользователя и текущее время сервера.

Чтобы запустить Job повторно, предварительно удалите предыдущий:

kubectl -n db-test delete job pg-check

Если на стороне базы данных настраиваются списки доступа по IP-адресам, можно убедиться, с какого адреса поступают подключения из кластера. Например, для PostgreSQL замените в файле pg-check.yaml запрос в параметре -c на следующий:

SELECT inet_client_addr(), inet_client_port();

Удалите предыдущий Job, примените измененный манифест и выведите результат:

kubectl -n db-test delete job pg-check
kubectl apply -f pg-check.yaml
kubectl -n db-test logs -f job/pg-check

Запрос вернет приватный адрес ноды, на которой запущен под:

 inet_client_addr | inet_client_port
------------------+------------------
 10.16.0.4        |            37338

Полученный адрес совпадает с INTERNAL-IP одной из нод в выводе команды kubectl get nodes -o wide. Запрос необходимо выполнять из пода в кластере: в SQL-консоли панели управления он вернет адрес самой консоли, а не кластера.

После завершения всех проверок удалите пространство имен. Вместе с ним будут удалены Secret и Job:

kubectl delete namespace db-test

Частые ошибки

nc: 10.16.0.1 (10.16.0.1:5432): Connection timed out
psql: error: connection to server at "10.16.0.1", port 5432 failed: timeout expired

psql: error: connection to server at "10.16.0.2", port 5432 failed: FATAL:  password authentication failed for user "example_user"
connection to server at "10.16.0.2", port 5432 failed: FATAL:  password authentication failed for user "example_user"

kubectl -n db-test delete secret external-db

psql: error: connection to server at "10.16.0.2", port 5432 failed: FATAL:  database "no_such_db" does not exist

Если возникнут вопросы, напишите нам, пожалуйста, тикет из панели управления аккаунта (раздел “Помощь и поддержка”), а если вы захотите обсудить доступ из кластера Managed Kubernetes к облачным базам данных и VPS по приватной сети или просто пообщаться с коллегами по цеху и сотрудниками Beget – ждем вас в нашем сообществе в Telegram.