DR-конфигурация

Active-passive, внешний балансировщик, два раздельных кластера.

DR-конфигурация (Disaster Recovery) обеспечивает переключение на резервный кластер управления при отказе основного. Доступна только в Enterprise и Enterprise ML. Перенос данных на резервный кластер рекомендуется выполнять с сопровождением инженеров внедрения.

Вариант 1: С внешним балансировщиком или DNS #

В один момент времени доступ только к одному кластеру управления. Полная прозрачность для пользователей и клиентских кластеров.

Подготовка #

1. Создайте общее Ingress-имя для обоих кластеров управления и сертификат для него.
2. Установите два кластера управления с этим сертификатом.

Вариант А: Два кластера с внешним балансировщиком для Ingress, общее имя Ingress (балансировщик смотрит на основной). Для KubeAPI — другой балансировщик или виртуальный IP.

Вариант Б: Два кластера с внутренним балансировщиком, разные IP для Ingress, но общее имя Ingress.

На основном кластере управления #

1. Настройте подключение к S3 для резервного копирования (Резервное копирование и восстановление → Хранилища).

2. Настройте провайдеры инфраструктуры (раздел Провайдеры).
3. Создайте клиентские кластеры (раздел Развертывание кластеров).
4. Подключите LDAP или OIDC: Интеграция с LDAP или Внешние провайдеры аутентификации.
5. Выдайте права доступа (Назначение прав доступа).
6. На дашбордах кластеров нажмите Приостановить реконсиляцию инфраструктуры и создайте резервные копии:
   • провайдеров;
   • неймспейсов клиентских кластеров;
   • UserRoles, GroupRoles.

Переключение при аварии #

Переключите балансировщик (или измените IP в DNS) на второй кластер управления.

На резервном кластере управления #

1. Настройте подключение к S3.
2. Дождитесь появления бэкапов в интерфейсе.
3. Восстановите в указанной очередности:
   1. провайдеры инфраструктуры;
   2. неймспейсы клиентских кластеров;
   3. UserRoles, GroupRoles.
4. Дождитесь отображения клиентских кластеров.
5. На дашбордах нажмите Возобновить реконсиляцию инфраструктуры. Подождите несколько минут.

Вариант 2: Два раздельных кластера управления #

Преимущество: обе платформы доступны сразу, внешний балансировщик не нужен.

Подготовка #

1. Создайте общий сертификат для Ingress на оба кластера (иначе после переключения потребуется обновить CA на Control Plane узлах клиентских кластеров).
2. Установите два кластера управления с общим сертификатом. Один — основной, второй — DR.

На основном кластере управления #

• Настройте S3, провайдеры, клиентские кластеры, LDAP, назначения прав доступа.
• Приостановите реконсиляцию и создайте резервные копии (провайдеры, неймспейсы, роли).

На резервном (DR) кластере управления #

1. Настройте подключение к S3 (то же хранилище).
2. Подключите LDAP.
3. Восстановите бэкапы в порядке: провайдеры → неймспейсы → UserRoles, GroupRoles.
4. Возобновьте реконсиляцию.

Для kubeconfig после переключения #

• Перенастройте Kube-APIServer на всех Control Plane узлах клиентских кластеров: укажите oidc-issuer-url на нужный кластер управления.
• Перенастройте параметры авторизации для сервисов: shturval-cd, shturval-dashboards, shturval-log-collector, shturval-metrics-collector (IP Ingress).

Примеры манифестов резервных копий #

Провайдеры инфраструктуры #

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: backup-platform-providers
  namespace: velero
  labels:
    velero.io/storage-location: s3
spec:
  includedNamespaces:
    - capv-system
    - capov-system
    - capbd-system
    - shturval-capsm
  includedClusterScopedResources:
    - vspherefailuredomains.infrastructure.cluster.x-k8s.io
    - vspheredeploymentzones.infrastructure.cluster.x-k8s.io
    - vsphereclusteridentities.infrastructure.cluster.x-k8s.io
    - ovirtproviders.infrastructure.cluster.x-k8s.io
    - basisproviders.infrastructure.cluster.x-k8s.io
    - shturvalproviders.infrastructure.cluster.x-k8s.io
    - shturvalhosts.infrastructure.cluster.x-k8s.io
  storageLocation: s3
  ttl: 24h

Неймспейсы клиентских кластеров #

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: backup-clusters
  namespace: velero
  labels:
    velero.io/storage-location: s3
spec:
  includedNamespaces:
    - shturval-myclustername-client1
    - shturval-myclustername-client2
  storageLocation: s3
  ttl: 24h

UserRoles, GroupRoles #

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: backup-platform-roles
  namespace: velero
  labels:
    velero.io/storage-location: s3
spec:
  includedNamespaces:
    - shturval-backend
  includedResources:
    - GroupRole
    - UserRole
  storageLocation: s3
  ttl: 24h

Создание общего сертификата (cfssl) #

Для двух кластеров с разными IP используйте wildcard-сертификат с hosts для обоих:

{
  "CN": "clustername.ip-XX-XX-XXX-XX.shturval.link",
  "hosts": [
    "*.clustername.ip-XX-XX-XXX-XX.shturval.link",
    "*.clustername.ip-XX-XX-XXX-XXY.shturval.link",
    "*.clustername.ip-XX-XX-XXX-XXZ.shturval.link"
  ],
  ...
}

Подробные примеры ca.json, cfssl.json, interm-ca.json, server-csr.json и команды cfssl — в официальной документации cfssl. Для wildcard-сертификата укажите в hosts все домены обоих кластеров.