Администрирование кластера Kubernetes в нескольких зонах доступности

Организации, предъявляющие самые высокие требования к времени безотказной работы, должны быть способны выдерживать более значительные сбои, например, потерю всей зоны доступности (AZ). Хотя подготовка кластера Kubernetes, охватывающего несколько AZ, является простой задачей у управляемых облачных провайдеров, существуют дополнительные административные требования, которые необходимо учитывать во время этапов развертывания, конфигурации и эксплуатации программного обеспечения ArcGIS Enterprise on Kubernetes.

В следующих разделах описываются соображения, которые необходимо принять во внимание, и требования, которые должны быть выполнены перед настройкой организации, ожидаемые последствия потери функциональности в AZ и то, как администратор может проверить работоспособность базовой системы после восстановления функциональности в этой AZ.

Как минимум, кластер Kubernetes, где развернуто приложение, должен соответствовать следующим требованиям:

• Группы рабочих узлов охватывают не менее трех зон доступности (AZ).

• Имеется достаточная мощность рабочих узлов для восстановления баланса всех рабочих нагрузок в двух AZ во время простоя.

Развертывание и настройка

При развертывании ArcGIS Enterprise on Kubernetes в кластере с несколькими AZ наличие рабочих нагрузок с отслеживанием состояния означает, что существует зависимость связанных дисков от AZ при использовании устройств блочного хранилища.

Чтобы соответствующие реплики каждого StatefulSet были распределены по соответствующей топологии, в файл свойств развертывания введено новое свойство K8S_AVAILABILITY_TOPOLOGY_KEY, которое необходимо обновить перед запуском скрипта развертывания. Обновление этого свойства до значения, отличного от kubernetes.io/hostname, приведет к появлению спецификации topologySpreadConstraint в наборах StatefulSet, которая гарантирует, что у нас не будет неравного баланса или реплик в какой-либо одной AZ. Ключом к метке узла AZ у большинства облачных провайдеров является topology.kubernetes.io/zone.

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

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

• enterprise-manager

• enterprise-web-style-app

• enterprise-help

• service-lifecycle-manager

• featureserver-webhook-processor

• gpserver-webhook-processor

Увеличение числа реплик всех перечисленных развертываний приведет к добавлению дополнительных ресурсов CPU и памяти к запросам и ограничениям пространства имен. Общее увеличение зависит от числа дополнительных реплик модулей, а также от запросов и ограничений, установленных для каждого модуля. См. Профили производительности для получения информации о запросах и ограничениях по умолчанию, установленных каждым профилем производительности.

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

Последствия потери зоны доступности

Значение и последствия потери AZ различаются в зависимости от того, какие облачные сервисы затронуты. Потеря конкретного сервиса, например вычислительного или хранилища, может оказать существенное влияние на выполняемые рабочие нагрузки, в то время как другие сетевые сбои, такие как разрешение DNS или резкое увеличение задержки, могут повлиять на взаимодействие микросервисов друг с другом.

Во время аварийного восстановления реляционного хранилища для некоторых функций, таких как вход в систему, редактирование размещенных сервисов объектов и загрузка размещенных слоев, может быть на короткое время снижена производительность. Когда резервный экземпляр будет переведен в основной, все функциональные возможности организации должны вернуться в стабильное состояние.

Верификация работоспособности организации

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

При отключении зоны доступности

Если при использовании блочного хранилища для PV зона доступности (AZ) будет потеряна, то модули statefulset не смогут быть перепланированы в другие AZ из-за требований к сходству томов.

Для тех хранилищ данных, которым это необходимо, поддерживается кворум, чтобы соответствующие сервисы могли функционировать в состоянии пониженной производительности. Поскольку реляционное хранилище является основным компонентом, от которого зависят несколько других сервисов, режим ожидания можно сбросить с помощью Admin API. Это приведет к удалению набора statefulset и связанного с ним PVC и созданию нового набора statefulset. Это позволяет резервному экземпляру повторно синхронизироваться с основным после появления в одной из оставшихся AZ.

После отключения зоны доступности

Когда службы восстановлены в AZ, где произошел сбой, перезапустите связанные рабочие нагрузки, которые находились в состоянии ожидания, что можно подтвердить через Kubernetes API.

Если сервисы не удается восстановить в существующей AZ, убедитесь, что в кластере осталось как минимум три AZ. Если это не так, расширьте кластер на дополнительную AZ. После этого создайте резервную копию, выполните деинсталляцию и повторную установку, а затем выполните операцию восстановления из резервной копии.