tgoop.com/DevOPSitsec/1571
Last Update:
🔥 Задача для продвинутых DevOps-инженеров: «Миграция Postgres в облако без остановки сервиса»
Представьте продакшн-платформу:
• Kubernetes-кластер (v1.28) в двух регионах
• Микросервисы на Go и Python, общаются по gRPC
• StatefulSet с PostgreSQL 13 (self-hosted, SSD RAID-10)
• Трафик 7000 RPS, SLA = 99.95 %, окно простоя ≤ 30 сек
Цель
Перенести базу в управляемый Postgres-кластер (например, AWS Aurora) так, чтобы:
• API не теряли запросы и транзакции
• Метрики и алерты оставались валидными
• CI/CD остался GitOps-основанным (Argo CD)
• Секреты не хранились в манифестах
Условия и «подводные камни»
• В исходном Postgres включён logical replication; 2 тб данных, 3 млн TPS в pgbouncer-пуле
• Используется pgcrypto → нельзя менять шифрование на лету
• Приложения имеют hard-coded connection string в ConfigMap
• Читать из реплик можно, писать нужно только в primary
• Регион А может потерять связь с S3 на 5 минут в любой момент
• Лимит: 1 час на full-rollback в случае аварии
Что нужно спроектировать
1. План миграции с отметками T-0/T-1/T-2 (pre-cutover, dual-write, switchover)
2. Полностью идемпотентный GitOps-pipeline (ArgoCD-App-of-Apps)
3. Пошаговое обновление Secrets (Vault → CSI driver) без ревизии pod’ов
4. Canary-механизм трафика (Istio 1.22) + прометей-алерты уровня query latency p95
5. Rollback-стратегию, если write-amplification > 1.5× на новой БД
6. Планирование maintenance-окна с блокировкой DDL и feature-флагами
Решение (пояснение ключевых шагов)
*Логическая реплика и dual-write*
• Создаём Aurora как read-replica Postgres, подключаем pglogical для lorepl.
• В Kubernetes добавляем Sidecar-proxy (envoy) → умеет писать одновременно в old и new primary.
• Включаем dual-write только для команд INSERT/UPDATE/DELETE; SELECT всё ещё смотрит на старую primary.
*Секреты без простоя*
• Секреты переносятся из ConfigMap в Vault KV2.
• Deploy CSI-driver и auto-injector; переменные окружения читают через projected volume.
• Патчинг Deployments через kubectl patch --type strategic не перезапускает pod’ы (без изменения podSpec.h`) — остаёмся в том же ReplicaSet.
*Canary и метрики*
• Istio DestinationRule + VirtualService: трафик canary: 10 %, stable: 90 %.
• Прометей-rule: rate(http_requests_total{status!~"5..",destination_service="canary"}[5m]) < threshold.
• Отдельный alert на pg_stat_replication replay_lag > 1 сек.
*Cutover*
1. T-0: включён dual-write, read-only на реплики.
2. T-1: проверяем чек-суммы через pg_dump --schema-only и pg_comparator.
3. T-2: Istio маршрутизирует 100 % на новую primary, выключаем dual-write.
4. Разморозка DDL через Liquibase-pipeline.
*Rollback*
• Переключаем Istio обратно на старый primary (мгновенно)
• Опционально реплицируем дельту назад через wal2json → old primary
• Откатываем Secrets версией Vault с «previous revision» (Vault KV2)
*GitOps-pipeline (ArgoCD)*
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: postgres-cutover
spec:
syncPolicy:
automated:
selfHeal: true
prune: true
retry:
limit: 4
source:
repoURL: [email protected]:corp/platform-deploy
path: k8s/postgres/aurora
targetRevision: migrate-prod
destination:
namespace: database
server: https://kubernetes.default.svc
• Весь cutover хранится в migrate-prod ветке → можно мгновенно вернуться на main.
Фиксация SLA
• Приложения читают тайм-ауты из ConfigMap, а не код. Перед миграцией снижаем тайм-ауты connect_timeout=2s.
• Версионируем Helm-charts микросервисов: appVersion: 2024.06-cutover.
Итог
При правильной настройке dual-write и canary-трафика фактический простой уложится в 5-10 секунд (только время Istio-промотирования) с гарантированным откатом ≤ 1 час. Это упражнение проверяет глубокие знания Kubernetes, GitOps, сетевого слоя и Postgres-репликации.
BY DevOps
Share with your friend now:
tgoop.com/DevOPSitsec/1571