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

#Обзор

Это решение предназначено для сценариев аварийного восстановления, связанных с кластером 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, контейнерные image необходимо загружать отдельно в каждый из них;

• Если в основном кластере развернуты 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). Если проверка сообщает о missing или surplus keys, резервный кластер не согласован с основным: не переходите к следующему шагу. Сначала устраните несоответствие или обратитесь в техническую поддержку. На обоих кластерах также убедитесь, что ни один узел 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 см. в разделе Загрузка пакетов.