Распределенная установка в отказоустойчивой конфигурации

Вы можете обеспечить отказоустойчивость KUMA путем развертывания Ядра KUMA в кластере Kubernetes, а также использования внешнего балансировщика TCP-трафика.

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-<номер сборки>.tar.gz и подготовленный вами файл инвентаря k0s.inventory.yml, в котором вы определите конфигурацию кластера. При новой установке в отказоустойчивой конфигурации ресурсы OOTB импортируются всегда. Также вы можете выполнить установку с развертыванием демонстрационных сервисов. Для этого нужно в файле инвентаря указать параметр deploy_example_services: true.

Поместить Ядро KUMA в кластер Kubernetes можно следующими способами:

• Установить KUMA в кластере Kubernetes с нуля.
• Перенести Ядро существующей установки KUMA в кластер Kubernetes.

  Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:

  1. Подготовьте файл инвентаря k0s.inventory.yml.

     В файле инвентаря k0s.inventory.yml в разделах kuma_core, kuma_ collector, kuma_correlator, kuma_storage укажите те же хосты, которые использовались при обновлении KUMA с версии 2.1.3 до версии 3.0.3 или при новой установке программы. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s, need_transfer и airgap значение true. Параметру deploy_example_services необходимо присвоить значение false.

     Пример файла инвентаря с 3 выделенными контроллерами, 2 рабочими узлами и 1 балансировщиком.

  2. Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

  Процесс переноса Ядра KUMA в новый кластер Kubernetes

  При запуске установщика с файлом инвентаря производится поиск установленного Ядра KUMA на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.

  Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра KUMA в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе KUMA.

  Для коллекторов, корреляторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. URL Ядра для компонентов при этом не изменится.

  На хосте с Ядром установщик выполняет следующие действия:

  • Удаляет с хоста systemd-сервисы: kuma-core, kuma-mongodb, kuma-victoria-metrics, kuma-vmalert, kuma-grafana.
  • Удаляет internal сертификат Ядра.
  • Удаляет файлы сертификатов всех прочих компонентов и удаляет записи о них из MongoDB.
  • Удаляет директории:
    • /opt/kaspersky/kuma/core/bin
    • /opt/kaspersky/kuma/core/certificates
    • /opt/kaspersky/kuma/core/log
    • /opt/kaspersky/kuma/core/logs
    • /opt/kaspersky/kuma/grafana/bin
    • /opt/kaspersky/kuma/mongodb/bin
    • /opt/kaspersky/kuma/mongodb/log
    • /opt/kaspersky/kuma/victoria-metrics/bin
  • Переносит данные Ядра и ее зависимостей на сетевой диск внутри кластера Kubernetes.
  • На хосте с Ядром переносит директории:
    • /opt/kaspersky/kuma/core → /opt/kaspersky/kuma/core.moved
    • /opt/kaspersky/kuma/grafana → /opt/kaspersky/kuma/grafana.moved
    • /opt/kaspersky/kuma/mongodb → /opt/kaspersky/kuma/mongodb.moved
    • /opt/kaspersky/kuma/victoria-metrics → /opt/kaspersky/kuma/victoria-metrics.moved

  После проверки корректности переноса Ядра в кластер данные директории можно удалить.

  В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).

  При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.

  Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.

Минимальная конфигурация

В Kubernetes существует 2 роли узлов:

• контроллеры (control-plane) – узлы с этой ролью управляют кластером, хранят метаданные, распределяют рабочую нагрузку.
• рабочие (worker) – узлы с этой ролью несут полезную рабочую нагрузку, то есть размещают процессы KUMA.

Для выполнения установки KUMA в отказоустойчивой конфигурации вам понадобится:

• 3 выделенных контроллера
• 2 рабочих узла
• 1 балансировщик

Для эффективной работы Ядра KUMA в Kubernetes критически важно выделить 3 обособленных узла с единственной ролью контроллера. Это позволит обеспечить отказоустойчивость самого кластера Kubernetes и гарантировать, что рабочая нагрузка - процессы KUMA и другие процессы - не повлияет на задачи, связанные с управлением кластером Kubernetes. В случае использования средств виртуализации следует убедиться, что узлы размещены на разных физических серверах и эти физические серверы не выполняют роль рабочих узлов.

В случае демонстрационной установки KUMA допустимо совмещать роли контроллера и рабочего узла. Однако при расширении установки до распределенной необходимо переустановить кластер Kubernetes целиком, выделив 3 отдельных узла с ролью контроллера и как минимум 2 узла с ролью рабочего узла. Обновление KUMA до следующих версий недоступно при наличии узлов, совмещающих роли контроллера и рабочего узла.