#Восстановление после катастрофы глобального кластера

#Обзор

Данное решение предназначено для сценариев восстановления после катастрофы, связанных с кластером global. Кластер global служит управляющей плоскостью платформы и отвечает за управление другими кластерами. Для обеспечения непрерывной доступности сервисов платформы при сбое кластера global в этом решении развертываются два кластера global: основной кластер (Primary Cluster) и резервный кластер (Standby Cluster).

Механизм восстановления основан на синхронизации данных etcd в реальном времени с основного кластера на резервный. В случае недоступности основного кластера из-за сбоя, сервисы могут быстро переключиться на резервный кластер.

#Поддерживаемые сценарии катастроф

• Неисправимый системный сбой основного кластера, делающий его неработоспособным;
• Сбой физических или виртуальных машин, на которых размещён основной кластер, приводящий к его недоступности;
• Сбой сети в месте расположения основного кластера, вызывающий прерывание сервиса;

#Неподдерживаемые сценарии катастроф

• Сбои приложений, развернутых внутри кластера global;
• Потеря данных из-за сбоев в системе хранения (вне области синхронизации etcd);

Роли Primary Cluster и Standby Cluster являются относительными: кластер, обслуживающий платформу в данный момент, считается основным (DNS указывает на него), а резервный — резервным. После переключения роли меняются местами.

#Примечания

• Решение синхронизирует только данные etcd кластера global; данные реестра, chartmuseum и других компонентов не включены;

• Для удобства отладки и управления рекомендуется называть узлы в стиле standby-global-m1, чтобы указывать принадлежность узла к основному или резервному кластеру.

• Восстановление данных приложений внутри кластера не поддерживается;

• Для надежной синхронизации etcd требуется стабильное сетевое соединение между двумя кластерами;

• Если кластеры основаны на гетерогенных архитектурах (например, x86 и ARM), используйте пакет установки с поддержкой двух архитектур;

• Следующие пространства имён исключены из синхронизации etcd. Если в них создаются ресурсы, пользователи должны самостоятельно выполнять их резервное копирование:

  cpaas-system
  cert-manager
  default
  global-credentials
  cpaas-system-global-credentials
  kube-ovn
  kube-public
  kube-system
  nsx-system
  cpaas-solution
  kube-node-lease
  kubevirt
  nativestor-system
  operators

• Если оба кластера используют встроенные реестры образов, контейнерные образы необходимо загружать отдельно в каждый из них;

• Если в основном кластере развернут DevOps Eventing v3 (knative-operator) и его экземпляры, те же компоненты должны быть предварительно развернуты в резервном кластере.

#Обзор процесса

1. Подготовить единое доменное имя для доступа к платформе;
2. Направить домен на VIP основного кластера и установить Primary Cluster;
3. Временно переключить разрешение DNS на VIP резервного кластера для установки Standby Cluster;
4. Скопировать ключ шифрования ETCD основного кластера на узлы, которые впоследствии станут управляющими узлами резервного кластера;
5. Установить и включить плагин синхронизации etcd;
6. Проверить статус синхронизации и выполнять регулярные проверки;
7. В случае сбоя переключить DNS на резервный кластер для завершения восстановления.

#Требуемые ресурсы

• Единый домен, который будет Platform Access Address, а также TLS-сертификат и приватный ключ для обслуживания HTTPS на этом домене;

• Выделенный виртуальный IP-адрес для каждого кластера — один для Primary Cluster и другой для Standby Cluster;

  • Предварительно настроить балансировщик нагрузки для маршрутизации TCP-трафика на порты 80, 443, 6443, 2379 и 11443 на управляющие узлы за соответствующим VIP.

#Процесс

#Шаг 1: Установка основного кластера

Обратитесь к следующей документации для завершения установки:

• Подготовка к установке
• Установка

#Шаг 2: Установка резервного кластера

1. Временно направьте доменное имя на VIP резервного кластера;

2. Войдите на первый управляющий узел Primary Cluster и скопируйте конфигурацию шифрования etcd на все управляющие узлы резервного кластера:

   # Предположим, управляющие узлы основного кластера: 1.1.1.1, 2.2.2.2 и 3.3.3.3
   # управляющие узлы резервного кластера: 4.4.4.4, 5.5.5.5 и 6.6.6.6
   for i in 4.4.4.4 5.5.5.5 6.6.6.6  # Замените IP управляющих узлов резервного кластера
   do
     ssh "<user>@$i" "sudo mkdir -p /etc/kubernetes/"
     scp /etc/kubernetes/encryption-provider.conf "<user>@$i:/tmp/encryption-provider.conf"
     ssh "<user>@$i" "sudo install -o root -g root -m 600 /tmp/encryption-provider.conf /etc/kubernetes/encryption-provider.conf && rm -f /tmp/encryption-provider.conf"
   done

3. Установите резервный кластер так же, как и основной

Обратитесь к следующей документации для завершения установки:

• Подготовка к установке
• Установка

#Шаг 3: Включение синхронизации etcd

1. Настройте балансировщик нагрузки для перенаправления порта 2379 на управляющие узлы соответствующего кластера. Поддерживается ТОЛЬКО TCP-режим; перенаправление на уровне L7 не поддерживается.

2. Получите доступ к веб-консоли резервного глобального кластера через его VIP и переключитесь в режим Administrator;

3. Перейдите в Marketplace > Cluster Plugins, выберите кластер global;

4. Найдите etcd Synchronizer, нажмите Install, настройте параметры:

   • Используйте интервал синхронизации по умолчанию;
   • Оставьте переключатель логирования выключенным, если не требуется отладка.

Проверьте, что Pod синхронизации запущен на резервном кластере:

kubectl get po -n cpaas-system -l app=etcd-sync
kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | head -1) | grep -i "Start Sync update"

Когда появится сообщение “Start Sync update”, пересоздайте один из Pod для повторного запуска синхронизации ресурсов с зависимостями ownerReference:

kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | head -1)

Проверьте статус синхронизации:

mirror_svc=$(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')
ipv6_regex="^[0-9a-fA-F:]+$"
if [[ $mirror_svc =~ $ipv6_regex ]]; then
  export mirror_new_svc="[$mirror_svc]"
else
  export mirror_new_svc=$mirror_svc
fi
curl $mirror_new_svc/check

Объяснение вывода:

• LOCAL ETCD missed keys: Ключи есть в основном кластере, но отсутствуют в резервном. Часто вызвано GC из-за порядка ресурсов при синхронизации. Перезапустите один Pod etcd-sync для исправления;
• LOCAL ETCD surplus keys: Лишние ключи есть только в резервном кластере. Перед удалением этих ключей из резервного кластера согласуйте с командой эксплуатации.

Если установлены следующие компоненты, перезапустите их сервисы:

• Log Storage для Elasticsearch:

  kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch

• Monitoring для VictoriaMetrics:

  kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'

#Процесс восстановления после катастрофы

1. При необходимости перезапустите Elasticsearch на резервном кластере:

   # Скопируйте installer/res/packaged-scripts/for-upgrade/ensure-asm-template.sh в /root:
   # НЕ пропускайте этот шаг
   
   # при необходимости переключитесь на пользователя root
   sudo -i
   
   # проверьте, установлен ли Log Storage для Elasticsearch в глобальном кластере
   _es_pods=$(kubectl get po -n cpaas-system | grep cpaas-elasticsearch | awk '{print $1}')
   if [[ -n "${_es_pods}" ]]; then
       # Если скрипт вернул ошибку 401, перезапустите Elasticsearch
       # затем выполните скрипт для повторной проверки кластера
       bash /root/ensure-asm-template.sh
   
       # Перезапустите Elasticsearch
       xargs -r -t -- kubectl delete po -n cpaas-system <<< "${_es_pods}"
   fi

2. Проверьте согласованность данных в резервном кластере (та же проверка, что и в Шаге 3);

3. Удалите плагин синхронизации etcd;

4. Уберите перенаправление порта 2379 с обоих VIP;

5. Переключите DNS домена платформы на VIP резервного кластера, который теперь становится основным;

6. Проверьте разрешение DNS:

   kubectl exec -it -n cpaas-system deployments/sentry -- nslookup <platform access domain>
   # Если разрешение некорректно, перезапустите Pod coredns и повторяйте попытки до успеха

7. Очистите кэш браузера и зайдите на страницу платформы, чтобы убедиться, что она отражает бывший резервный кластер;

8. Перезапустите следующие сервисы (если установлены):

   • Log Storage для Elasticsearch:

     kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch

   • Monitoring для VictoriaMetrics:

     kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'

   • cluster-transformer:

     kubectl delete po -n cpaas-system -l service_name=cluster-transformer

9. Если рабочие кластеры отправляют данные мониторинга в основной, перезапустите warlock в рабочем кластере:

   kubectl delete po -n cpaas-system -l service_name=warlock

10. На исходном основном кластере повторите шаги Включения синхронизации etcd, чтобы превратить его в новый резервный кластер.

#Регулярные проверки

Регулярно проверяйте статус синхронизации на резервном кластере:

curl $(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')/check

Если обнаружены отсутствующие или лишние ключи, следуйте инструкциям в выводе для их устранения.

#Загрузка пакетов

При использовании violet для загрузки пакетов в резервный кластер необходимо указывать параметр --dest-repo с VIP резервного кластера. Если этот параметр опущен, пакет будет загружен в репозиторий образов основного кластера, что помешает резервному кластеру установить или обновить соответствующее расширение.

#FAQ

• Инструкция на случай, если ключ шифрования ETCD резервного кластера не был синхронизирован с ключом основного кластера до установки резервного кластера.

1. Получите ключ шифрования ETCD на любом управляющем узле резервного кластера:

   ssh <user>@<STANDBY cluster control plane node> sudo cat /etc/kubernetes/encryption-provider.conf

Он должен выглядеть так:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: MTE0NTE0MTkxOTgxMA==

2. Создайте резервную копию ключа шифрования ETCD на любом управляющем узле основного кластера (например, 1.1.1.1):

   # Войдите на управляющий узел основного кластера 1.1.1.1
   ssh "<user>@1.1.1.1"
   sudo install -o root -g root -m 600 /etc/kubernetes/encryption-provider.conf /etc/kubernetes/encryption-provider.conf.bak

3. Объедините ключ шифрования ETCD резервного кластера в файл /etc/kubernetes/encryption-provider.conf на узле 1.1.1.1, убедившись, что имена ключей уникальны. Например, если ключ основного кластера называется key1, переименуйте ключ резервного в key2:

   apiVersion: apiserver.config.k8s.io/v1
   kind: EncryptionConfiguration
   resources:
     - resources:
       - secrets
       providers:
       - aescbc:
           keys:
           - name: key1
             secret: My4xNDE1OTI2NTM1ODk3
           - name: key2
             secret: MTE0NTE0MTkxOTgxMA==

4. Убедитесь, что новый файл /etc/kubernetes/encryption-provider.conf перезаписывает ВСЕ реплики на управляющих узлах обоих кластеров:

   # Предположим, управляющие узлы основного кластера: 1.1.1.1, 2.2.2.2 и 3.3.3.3
   # управляющие узлы резервного кластера: 4.4.4.4, 5.5.5.5 и 6.6.6.6
   
   # Поскольку 1.1.1.1 уже настроен на использование обоих ключей ETCD,
   # войдите на узел 1.1.1.1 и выполните следующие команды:
   for i in \
       2.2.2.2 3.3.3.3 \
       4.4.4.4 5.5.5.5 6.6.6.6 \
   ; do
       scp /etc/kubernetes/encryption-provider.conf "<user>@${i}:/tmp/encryption-provider.conf"
       ssh "<user>@${i}" '
   #!/bin/bash
   set -euo pipefail
   
   sudo install -o root -g root -m 600 \
       /etc/kubernetes/encryption-provider.conf /etc/kubernetes/encryption-provider.conf.bak
   sudo install -o root -g root -m 600 \
       /tmp/encryption-provider.conf            /etc/kubernetes/encryption-provider.conf
   sudo rm -f /tmp/encryption-provider.conf
   
   _pod_name="kube-apiserver"
   _pod_id=$(sudo crictl ps --name "${_pod_name}" --no-trunc --quiet)
   if [[ -z "${_pod_id}" ]]; then
       echo "FATAL: не найден pod `kube-apiserver` на узле $(hostname)"
       exit 1
   fi
   sudo crictl rm --force "${_pod_id}"
   sudo systemctl restart kubelet.service
   '
   done

5. Перезапустите kube-apiserver на узле 1.1.1.1

   _pod_name="kube-apiserver"
   _pod_id=$(sudo crictl ps --name "${_pod_name}" --no-trunc --quiet)
   if [[ -z "${_pod_id}" ]]; then
       echo "FATAL: не найден pod `kube-apiserver` на узле $(hostname)"
       exit 1
   fi
   sudo crictl rm --force "${_pod_id}"
   sudo systemctl restart kubelet.service