Post #1571

🔥 Задача для продвинутых 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-репликации.