Модуль 9.1: Інтеграція реляційних баз даних (RDS / Cloud SQL / Flexible Server)

Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Основи хмар (будь-який провайдер), основи мереж Kubernetes

Чому цей модуль важливий

У вересні 2022 року фінтех-стартап запустив свою базу даних PostgreSQL як StatefulSet всередині EKS. Вони прочитали всі статті про “запуск БД у Kubernetes” і почувалися впевнено. Однієї п’ятниці о 16:47 спрацювало автомасшабування вузлів, яке перенесло под бази даних. Проблема була в тому, що диск (PersistentVolume) знаходився в us-east-1a, а новий сервер — в us-east-1b. Под “завис” у стані Pending на 22 хвилини. Протягом цих 22 хвилин їхній платіжний шлюз, що обробляв 14 000 транзакцій на годину, був повністю мертвим. Збитки оцінили у $89 000.

Наступного понеділка стартап перейшов на Amazon RDS. Не тому, що Kubernetes не може запускати бази даних (може!), а тому, що керовані сервіси беруть на себе найскладніше: автоматичний failover, відновлення на момент часу (PITR), патчі та реплікацію. Справжній інженерний виклик змістився з “як тримати Postgres живим” на “як підключити Kubernetes до керованих баз безпечно, ефективно та надійно”.

Цей модуль навчить вас саме цьому. Ви дізнаєтеся, як з’єднувати поди з базами через приватні мережі, як налаштовувати пулінг з’єднань, як автоматично ротувати паролі та як проводити міграції схем у GitOps воркфлоу так, щоб ваш on-call інженер міг спокійно спати вночі.

Приватне мережеве підключення

Перше правило підключення до бази: ніколи не відкривайте базу даних у публічний інтернет. Кожен провайдер має механізми приватних ендпоінтів.

AWS: RDS у приватних підмережах

Ваш кластер EKS та інстанс RDS мають бути в одній VPC. Ви створюєте Security Group, яка дозволяє вхідний трафік на порт 5432 тільки з діапазону IP вашого кластера.

GCP: Cloud SQL через Private Service Connect

Google використовує VPC Peering між вашою мережею та мережею сервісів Google. Ви отримуєте внутрішню IP-адресу бази, яка недоступна ззовні.

Azure: Flexible Server з Private Endpoint

Ви підключаєте базу безпосередньо до вашої віртуальної мережі (VNet) через Private Link, що робить її частиною вашої внутрішньої інфраструктури.

Пулінг з’єднань із PgBouncer

Кожне підключення до бази споживає пам’ять на сервері (близько 5-10 МБ для Postgres). У Kubernetes поди постійно масштабуються. Якщо у вас 20 реплік додатка, і кожна тримає 10 з’єднань — це вже 200 з’єднань. Під час деплою кількість подів подвоюється — і ваша база може просто “лягти” від кількості відкритих сокетів.

Рішення — PgBouncer. Він працює як посередник: додатки підключаються до нього, а він тримає невелику кількість постійних з’єднань із реальною базою.

Два патерни використання:

Sidecar: PgBouncer запускається в кожному поді поруч із вашим кодом.
Centralized: Окремий деплоймент PgBouncer, через який ходять усі сервіси.

Ротація паролів

Паролі, зашиті в Kubernetes Secrets — це ризик. Якщо ви хочете їх змінити, вам треба оновити базу, оновити секрет і перезапустити всі поди. Це важко зробити без простоїв.

ESO (External Secrets Operator): Він сам підтягує паролі з AWS Secrets Manager або Google Secret Manager у Kubernetes. Коли ви міняєте пароль у хмарі, ESO бачить це і оновлює секрет у кластері.

Міграції схем у GitOps

Запуск ALTER TABLE у продакшні — це завжди стрес. У світі GitOps ми використовуємо Kubernetes Jobs.

Патерн Expand-Contract (Розширення-Стиснення):

Крок 1: Додати нову колонку (не видаляючи стару).
Крок 2: Деплой коду, який пише в обидві колонки.
Крок 3: Видалення старої колонки, коли всі поди оновлені. Це гарантує, що стара і нова версії додатка можуть працювати одночасно під час деплою.

Типові помилки

Помилка	Чому це стається	Як виправити
Публічна IP для бази	”Щоб зручно було підключитися з дому”	Використовуйте `kubectl port-forward` для доступу адміністратора; база має бути в приватній підмережі
Немає лімітів на з’єднання	”Хай підключаються, скільки треба”	Завжди використовуйте PgBouncer та налаштовуйте `max_connections` на базі
Паролі в ConfigMaps	Плутанина між секретами та налаштуваннями	Тільки Secrets, а краще — інтеграція з Cloud Secret Manager
Міграції в коді додатка	Кожен под намагається мігрувати базу при старті	Використовуйте окремий Job (ArgoCD PreSync hook), щоб міграція пройшла рівно один раз

Тест

1. Чому важливо використовувати ExternalName Service для бази даних?

Це створює рівень абстракції. Ваш код звертається до db.production.svc.cluster.local. Якщо ви переїдете з одного регіону в інший або зміните тип бази, ви просто зміните налаштування Service у Kubernetes, не чіпаючи конфігурацію десятків додатків.

2. У чому різниця між режимами 'session' та 'transaction' у PgBouncer?

У режимі session з’єднання закріплюється за користувачем, поки він не відключиться. У режимі transaction PgBouncer віддає з’єднання назад у пул одразу після завершення кожного SQL-запиту. Для Kubernetes майже завжди краще transaction, бо це дозволяє обслуговувати сотні подів через десятки з’єднань із базою.

Практична вправа: Підключення до бази

Створіть Secret із креденшалами вашої бази.
Розгорніть PgBouncer як окремий деплоймент у кластері.
Налаштуйте Service типу ExternalName, що вказує на вашу хмарну базу.
Створіть Job, який при кожному деплої перевіряє версію схеми бази даних.

Наступний модуль

Переходьте до Модуля 9.2: Керовані брокери повідомлень — ви навчитеся інтегрувати SQS, Pub/Sub та Service Bus із вашим кластером та налаштовувати автомасшабування на основі довжини черги.