#Аварийное восстановление глобального кластера

#Обзор

Это решение предназначено для сценариев аварийного восстановления, связанных с кластером global. Кластер global выполняет роль управляющей плоскости платформы и отвечает за управление другими кластерами. Чтобы обеспечить непрерывную доступность сервисов платформы при сбое кластера global, это решение разворачивает два кластера global: основной кластер и резервный кластер.

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

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

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

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

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

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

#Примечания

• Это решение синхронизирует только данные etcd кластера global; данные из registry, chartmuseum и других компонентов не входят в область синхронизации;

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

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

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

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

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

  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

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

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

#Общий порядок выполнения

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

#Необходимые ресурсы

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

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

  • Предварительно настройте load balancer для маршрутизации TCP-трафика на портах 80, 443, 6443, 2379 и 11443 к узлам control plane за соответствующим VIP.

#Порядок действий

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

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

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

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

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

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

   # Assume the primary cluster control plane nodes are 1.1.1.1, 2.2.2.2 & 3.3.3.3
   # and the standby cluster control plane nodes are 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  # Replace with standby cluster control plane node IPs
   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. При необходимости настройте load balancer для перенаправления порта 2379 на узлы control plane соответствующего кластера. Поддерживается ТОЛЬКО режим TCP; перенаправление на уровне L7 не поддерживается.

   INFO

   Перенаправление порта через load balancer не требуется. Если доступ из резервного кластера к активному глобальному кластеру возможен напрямую, укажите адреса etcd через Active Global Cluster ETCD Endpoints.

2. Откройте Web Console резервного глобального кластера через его VIP и переключитесь в представление Administrator;

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

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

   • Если порт 2379 не перенаправляется через load balancer, необходимо корректно настроить Active Global Cluster ETCD Endpoints;
   • Используйте значение по умолчанию для Data Check Interval;
   • Оставьте переключатель Print detail logs выключенным, если только не выполняете диагностику.

Проверьте, что sync 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 for Elasticsearch:

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

• Monitoring for VictoriaMetrics:

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

#Процесс аварийного восстановления

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

   # Copy installer/res/packaged-scripts/for-upgrade/ensure-asm-template.sh to /root:
   # DO NOT skip this step
   
   # switch to the root user if necessary
   sudo -i
   
   # check whether the Log Storage for Elasticsearch is installed on global cluster
   _es_pods=$(kubectl get po -n cpaas-system | grep cpaas-elasticsearch | awk '{print $1}')
   if [[ -n "${_es_pods}" ]]; then
       # In case the script returned the 401 error, restart Elasticsearch
       # then execute the script to check the cluster again
       bash /root/ensure-asm-template.sh
   
       # Restart Elasticsearch
       xargs -r -t -- kubectl delete po -n cpaas-system <<< "${_es_pods}"
   fi

2. Проверьте согласованность данных в резервном кластере (та же проверка, что и на Шаге 3). Если проверка сообщает о пропущенных или избыточных ключах, резервный кластер не согласован с основным: не переходите к следующему шагу. Сначала устраните несоответствие или обратитесь в техническую поддержку. Также на обоих кластерах убедитесь, что ни один узел Machine не находится в состоянии, отличном от running, и устраните все такие состояния перед продолжением:

   kubectl get machines.platform.tkestack.io

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

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

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

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

   kubectl exec -it -n cpaas-system deployments/sentry -- nslookup <platform access domain>
   # If not resolved correctly, restart coredns Pods and retry until success

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

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

   • Log Storage for Elasticsearch:

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

   • Monitoring for 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. Если workload-кластеры отправляют данные мониторинга в основной кластер, перезапустите warlock в workload-кластере:

   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 push см. в разделе Загрузка пакетов.