Аварийное восстановление кластера global
Эта страница является точкой входа для аварийного восстановления кластера global, работающего на Immutable Infrastructure. Конфигурация аварийного восстановления на этапе развертывания является частью процедуры установки кластера global.
Процедура развертывания
Используйте необязательное развертывание для аварийного восстановления в руководстве по установке, когда создаете основной и резервный кластеры global.
Эта процедура развертывания является авторитетным источником конфигурации DR на этапе установки, включая следующее:
- Основной и резервный кластеры используют одну и ту же конфигурацию провайдера шифрования Kubernetes API server.
- Список SAN сертификата сервера etcd включает VIP-адреса управляющей плоскости основного и резервного кластеров, а также Platform Access Address.
- Развертывания Huawei DCS ссылаются на общий Secret провайдера шифрования из
DCSCluster.spec.encryptionProviderConfigRef. - Развертывания VMware vSphere записывают один и тот же файл
/etc/kubernetes/encryption-provider.confчерезKubeadmControlPlane.spec.kubeadmConfigSpec.files. - Развертывания Huawei Cloud Stack записывают один и тот же файл
/etc/kubernetes/encryption-provider.confчерезKubeadmControlPlane.spec.kubeadmConfigSpec.files. - VMware vSphere и Huawei Cloud Stack создают ConfigMap
dcs-import-extra-resourcesдо импорта установщиком, чтобы установка могла сохранить ресурсы, специфичные для провайдера. Имя сохраняет префиксdcsдля исторической совместимости с установщиком. Huawei DCS использует встроенную миграцию ресурсов провайдера, если только не требуется импортировать дополнительные ресурсы. - Основной кластер устанавливает
global-etcd-syncсо значениями подключения к резервному кластеру после успешного завершения обеих установок.
Область эксплуатации
После установки основного и резервного кластеров ведите DR как отдельный процесс жизненного цикла. Сохраняйте манифесты установки в соответствии с руководством по установке, а затем используйте утвержденный операционный runbook для следующих задач:
- Проверка состояния
etcd-syncи задержки репликации. - Проверка того, что резервный кластер может расшифровывать Kubernetes Secrets, созданные на основном кластере.
- Проверка VIP-адресов управляющей плоскости основного и резервного кластеров, а также пути доступа к платформе перед запланированным failover.
- Выполнение failover и failback с использованием утвержденной операционной процедуры.
- Согласование ресурсов, специфичных для провайдера, после failover.
Переключение аварийного восстановления и обновление кластера global с учетом DR оба удаляют плагин синхронизации etcd. Перед этим удалением убедитесь, что данные резервного кластера global согласованы с данными основного кластера. На Immutable Infrastructure узлы workload-кластера представлены объектами Cluster API Machine, поэтому неверное разрешение owner-reference после несогласованной синхронизации может удалить эти объекты Machine и уничтожить соответствующие виртуальные машины. Если проверка согласованности сообщает об отсутствующих или избыточных ключах, не удаляйте плагин; сначала устраните несогласованность или обратитесь в службу технической поддержки. Подробные процедуры переключения и обновления см. в Аварийное восстановление кластера `global` и Обновление кластера `global`.
Примечания для провайдеров
Следуйте шагам для DCS в необязательном развертывании для аварийного восстановления. Установка DCS должна сохранять один и тот же Secret провайдера шифрования и DCSCluster.spec.encryptionProviderConfigRef на обеих сторонах. Не добавляйте файл провайдера шифрования в KubeadmControlPlane.spec.kubeadmConfigSpec.files для DCS. Ресурсы провайдера DCS мигрируются встроенным механизмом; создавайте dcs-import-extra-resources только тогда, когда необходимо импортировать дополнительные ресурсы.
См. также
Для аварийного восстановления кластера global на традиционной операционной системе см. Аварийное восстановление кластера `global`.
Для установки и обновления кластера global на Immutable Infrastructure см.: