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

#Обзор

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

   4.3.1+

   4.3.0

   Предварительное условие (только для 4.3.1+): создайте Secret etcd-sync-active-cluster-token в резервном глобальном кластере. Сначала получите bearer token для доступа к API server активного глобального кластера из активного глобального кластера. Затем скопируйте вывод команды и используйте его при создании Secret. Secret хранит токен в ключе данных token.

   # Run this command on the active cluster.
   kubectl -n cpaas-system get secret k8sadmin -o jsonpath='{.data.token}' | base64 -d

   Скопируйте значение вывода, затем выполните эту команду в резервном кластере:

   ACTIVE_CLUSTER_TOKEN='<paste-the-token-from-the-active-cluster>'
   kubectl -n cpaas-system create secret generic etcd-sync-active-cluster-token \
     --from-literal=token="${ACTIVE_CLUSTER_TOKEN}" \
     --dry-run=client -o yaml | kubectl apply -f -

   • Установите для Active Global Cluster VIP VIP активного глобального кластера.
   • Если порт 2379 не пробрасывается через load balancer, корректно настройте Active Global Cluster ETCD Endpoints.
   • Установите для Standby Cluster ETCD Endpoints адрес etcd резервного кластера. Используйте значение по умолчанию, если локальный сервис etcd не экспонируется через другой endpoint.
   • Установите для Active Global Cluster Token Secret значение etcd-sync-active-cluster-token.
   • Используйте значение по умолчанию для Data Check Interval.
   • Оставьте Print detail logs выключенным, если только вы не выполняете диагностику.

   Во время установки система запускает Job etcd-sync-bootstrap до старта Deployment etcd-sync. Установка плагина продолжается только после того, как Job подготовит remote-etcd-ca, remote-etcd-issuer и remote-etcd-client.

   Проверьте bootstrap Job и runtime-ресурсы:

   kubectl get job -n cpaas-system etcd-sync-bootstrap
   kubectl logs -n cpaas-system job/etcd-sync-bootstrap
   kubectl get secret -n cpaas-system remote-etcd-ca
   kubectl get issuer -n cpaas-system remote-etcd-issuer
   kubectl get certificate -n cpaas-system remote-etcd-client
   kubectl get secret -n cpaas-system remote-etcd-client

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

Дождитесь, пока kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}' не вернет непустое значение, прежде чем продолжать.

Проверьте, что sync Pod'ы запущены в резервном кластере, и определите текущего лидера:

kubectl get po -n cpaas-system -l app=etcd-sync
kubectl get lease -n cpaas-system etcd-sync-mirror
leader_pod=$(kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}')
kubectl logs -n cpaas-system "$leader_pod" | grep -E "Acquired leader lease|Start Sync update"

Если ресурсы с зависимостями ownerReference нужно повторно синхронизировать, пересоздайте Pod текущего лидера после появления сообщения Start Sync update:

leader_pod=$(kubectl get lease -n cpaas-system etcd-sync-mirror -o jsonpath='{.spec.holderIdentity}')
kubectl delete po -n cpaas-system "$leader_pod"

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

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
  mirror_host="[$mirror_svc]"
else
  mirror_host="$mirror_svc"
fi
curl -g "http://${mirror_host}/check"

Интерпретация вывода:

• LOCAL ETCD missed keys: ключи существуют в основном глобальном кластере, но отсутствуют в резервном. Это часто устраняется после перезапуска текущего 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 в резервном кластере:

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