#Аварийное восстановление Global Cluster

#Обзор

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

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

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

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

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

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

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

#Примечания

• Это решение синхронизирует только данные etcd кластера global; данные из registry, 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

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

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

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

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

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

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

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

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

#Процедура

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

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

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

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

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

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

   # 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 на узлы плоскости управления соответствующего кластера. Поддерживается ТОЛЬКО режим 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 выключенным, если только вы не выполняете устранение неполадок.

Проверьте, что 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 не находится в нерабочем состоянии, и устраните все такие состояния перед продолжением:

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