Обновление предыдущих версий решения

Ограничения:

1. Для действующих пользователей при обновлении с 3.2.0 или 3.2.1 до 3.4 не выполняется обновление универсального макета панели мониторинга.

   Возможное решение: перезапустите сервис Ядра kuma-core.service. После этого данные будут обновляться с заданным для макета интервалом.

2. Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:

   sudo systemctl reset-failed

   После выполнения команды старый сервис перестанет отображаться, а новый сервис успешно запустится.

Обновление KUMA с версии 3.2.0 или 3.2.1 до версии 3.4 состоти из следующих этапов:

Предварительные действия

1. Убедитесь, что соблюдены все аппаратные и программные требования к установке решения.
2. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 3.2.

   Резервные копии KUMA, созданные в версии 3.2 и ниже, не подлежат восстановлению в версии 3.4. Это означает, что невозможно установить KUMA 3.4 и восстановить в ней резервную копию 3.2.х.

   Сразу после обновления KUMA до версии 3.4 создайте резервную копию.

3. Убедитесь, что имя хоста Ядра KUMA не начинается с цифры. Обновление до версии 3.4 не может быть выполнено успешно, если имя хоста Ядра KUMA начинается с цифры. Если имя хоста Ядра KUMA начинается с цифры, потребуется ряд действий, чтобы успешно выполнить обновление. Обратитесь в Службу технической поддержки за дополнительными инструкциями.
4. На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
5. Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
   • Удалите неактуальные источники событий.
   • Измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий.
   • Для политик мониторинга, примененных к неактуальным источникам событий, выключите рассылку уведомлений.

   После обновления KUMA для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.

Обновление KUMA

В зависимости от используемой схемы развертывания KUMA выполните следующие действия:

• Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке решения.
• Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.

  Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы → Активные сервисы.

Процесс обновления полностью повторяет процесс установки.

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

Как перенести Ядро KUMA в кластер Kubernetes

Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.

Подготовка KUMA к работе

1. После обновления KUMA очистите кеш браузера.
2. Если вы используете агенты, вручную обновите агенты KUMA.

Решение KUMA успешно обновлено.

Ограничения:

1. Для действующих пользователей при обновлении с 3.4.х до 4.0 не выполняется обновление универсального макета панели мониторинга.

   Возможное решение: перезапустите сервис Ядра kuma-core.service. После перезапуска данные будут обновляться с заданным для панели мониторинга интервалом.

2. Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:

   sudo systemctl reset-failed

   После выполнения команды старый сервис перестанет отображаться, а новый сервис успешно запустится.

Обновление KUMA с версии 3.4.х до версии 4.0 состоит из следующих этапов:

Предварительные действия

1. Убедитесь, что соблюдены все аппаратные и программные требования к установке решения.
2. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 3.4.х.

   Резервные копии KUMA, созданные в версии 3.4.х и ниже, не подлежат восстановлению в версии 4.0. Это означает, что невозможно установить KUMA 4.0 и восстановить в ней резервную копию 3.4.х.

   Сразу после обновления KUMA до версии 4.0 создайте резервную копию.

3. Проверьте имя хоста Ядра KUMA.

   Имя хоста может начинаться с цифры, если это соответствует принятой в организации схеме именования. Однако для работы сервисов KUMA с Raft нужно имя хоста, которое не начинается с цифры.

   Если имя хоста начинается с цифры, переименовывать сервер необязательно. Настройте дополнительное имя (FQDN), начинающееся с буквы, выполнив следующие действия:

   1. В файле /etc/hosts добавьте запись:

      <IP_address> <new_fqdn> <fqdn> <hostname>

      где:

      <IP_address> – IP-адрес сервера;

      <new_fqdn> – дополнительное имя хоста;

      <fqdn> – исходное FQDN;

      <hostname> – короткое имя хоста.

   2. На DNS-сервере создайте CNAME-запись, в которой <new_fqdn> указывает на <fqdn>.

   После настройки используйте дополнительное имя для сервисов KUMA с Raft. Исходное имя хоста изменять не нужно.

4. На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
5. Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
   • удалите неактуальные источники событий;
   • измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий;
   • для политик мониторинга, примененных к неактуальным источникам событий, отключите рассылку уведомлений.

   После обновления KUMA для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.

6. Для установки с Ядром KUMA в кластере Kubernetes с помощью скрипта определите размер данных метрик на томе Ядра KUMA 3.4, чтобы оценить, стоит ли переопределять значения параметров metrics_transfer_job_timeout, metrics_disk_request, core_disk_request в файле инвентаря k0s.inventory.yml, а затем перейдите к обновлению.

   Как определить размер данных метрик на томе Ядра KUMA 3.4

   Запустите скрипт get_old_metrics_size.sh с файлом инвентаря k0s.inventory.yml на целевой машине с помощью команды:

   sudo ./get_old_metrics_size_sh k0s.inventory.yml

   Скрипт не вносит изменений в существующую установку. В процессе работы скрипта выполняется подключение к мастер-контроллеру кластера для определения имени тома Ядра KUMA и к рабочим узлам кластера для определения размера директории внутри подключенного тома.

   В результате будет найдены тома Ядра KUMA на рабочих узлах кластера и определен размер директории victoria-metrics. Результат выполнения скрипта выводится на экран и сохраняется в журнале log/get_old_metrics_size-YYYYMMDD-HHMMSS.log.

   В журнале сохраняется сообщение следующего вида:

   TASK [Print metrics folder size] ***********************************************

   ok: [kuma1.example.com] => {}

   MSG:

   Found KUMA Core 3.4.1.53

   Found old metrics folder size: 1Gi

   Minimum metrics_data_size required to proceed: 3Gi (including 2Gi threshold)

   где:

   • Found KUMA Core – найденная версия Ядра KUMA.
   • Found old metrics folder size – текущий размер директории victoria-metrics в гигабайтах.
   • Minimum metrics_data_size required to proceed – минимально возможный размер тома метрик для миграции с версии 3.4.х. В этот размер заложен дополнительный запас свободного места в 2Gi. При необходимости вы можете отфильтровать вывод по строке Minimum metrics_data_size required to proceed.

   По результатам полученных данным вам необходимо определить необходимый размер тома сервиса Метрики в KUMA 4.0.x, в зависимости от ваших потребностей. Размер тома для сервиса Метрики не должен быть меньше значения Minimum metrics_data_size required to proceed.

   Если при обновлении c версии 3.4.х до версии 4.0.х вы укажете в файле инвентаря k0s.inventory.yml размер тома меньше чем в Minimum metrics_data_size required to proceed или используете значение параметра metrics_disk_request, которое будет меньше значения Minimum metrics_data_size required to proceed, установщик прервет выполнение обновления с версии 3.4.х до версии 4.0.х на этапе валидации установки со следующим сообщением:

   TASK [Check metrics volume size requirement] ***********************************

   fatal: [kuma1.example.com]: FAILED! => {

   "changed": false

   }

   MSG:

   Current metrics folder size: 20Gi

   Metrics disk request when low_resources=false: 10Gi

   Metrics disk request when low_resources=true: 10Gi

   Error: Available metric data exceeds specified volume size.

   The available metric data (20Gi + 2Gi threshold) is too large.

   Solution: Increase the metrics volume size by updating the metrics_disk_request variable in your inventory file.

   В приведенном примере пользователь попытался задать размер тома 10Gi через переменную инвентаря metrics_disk_request, при этом текущий размер данных метрик на диске составляет 20Gi. В результате желаемое значение размера тома меньше, чем текущий размер данных с учетом запаса свободного места в 2Gi, поэтому выполнить обновление с 3.4.х невозможно. Установка будет прервана на шаге валидации, при этом никаких изменений в текущую установку не вносится. Можно безопасно выбрать подходящее значение размера тома для метрик, переопределить его в файле инвентаря и повторить попытку обновления.

Обновление KUMA

В зависимости от используемой схемы развертывания KUMA выполните следующие действия:

• Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке решения.
• Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации с Ядром KUMA в кластере Kubernetes .

  Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.

Процесс обновления полностью повторяет процесс установки.

Вы можете изменить тип установки следующим образом:

• Если вы хотите выполнить обновление с распределенной установки до установки с Ядром 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, и затем до версии 3.2, или при новой установке решения. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s и need_transfer значение true. Параметру deploy_example_services необходимо присвоить значение false.

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

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

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

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

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

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

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

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

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

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

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

  Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.

• Если вы хотите обновить KUMA в распределенной установке до последней версии KUMA с Ядром в кластере Raft, в файле инвентаря distributed.inventory.yml вручную добавьте секцию kuma_core_peers и укажите в этой секции четное количество серверов, где вы планируете установить дополнительные сервисы Ядра KUMA. Также в секциях kuma_core и kuma_core_peers вы можете указать параметр raft_node_addr в формате <FQDN сервера из секции kuma_core, на котором установлено Ядро KUMA>:<порт>, если у сервера есть несколько разных FQDN. Указанный в параметре raft_node_addr FQDN будет использоваться для прослушивания сигналов от других узлов.

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

  После обновления все существующие сервисы KUMA будут подключены к Ядру KUMA на сервере из секции kuma_core. При дальнейшей установке новых сервисов вы можете указать несколько URL через запятую в команде установки, чтобы подключить сервисы к Ядрам KUMA в кластере Raft.

Подготовка KUMA к работе

1. После обновления KUMA очистите кеш браузера.
2. Если вы используете агенты, вручную обновите агенты KUMA.
3. Перенесите события алертов из MongoDB в ClickHouse.

   Как перенести события алертов

   После обновления KUMA с версии 3.4.x до версии 4.0 необходимо перенести события алертов из MongoDB в ClickHouse и указать хранилище в параметрах наполнения алертов.

   После обновления KUMA установщик останавливает сервис kuma-mongodb, который затем нужно вручную запустить перед переносом событий алертов. Если Ядро KUMA развернуто в кластере Kubernetes, после обновления контейнер с MongoDB также не будет запущен, поэтому его потребуется запустить перед переносом.

   Если вам необходимо прервать выполнение команды для переноса событий алертов, нажмите Ctrl+C в консоли командной строки. Отобразится уведомление о том, что команда будет остановлена. Текущая пачка событий будет безопасно перенесена в хранилище, прогресс переноса сохранится, и процесс можно будет продолжить при следующем запуске команды.

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

   • KUMA в неотказоустойчивой конфигурации.
   • В отказоустойчивой конфигурации в кластере Kubernetes.

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

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

   1. В веб-интерфейсе в разделе Ресурсы → Активные сервисы выберите хранилище, в которое будут перенесены события алертов, и нажмите Копировать идентификатор кластера.

      Идентификатор кластера хранения понадобится при выполнении команды по переносу событий алертов.

   2. На сервере с Ядром KUMA запустите сервис kuma-mongodb.service с помощью следующей команды:

      sudo systemctl start kuma-mongodb.service

   3. Перейдите в директорию /opt/kaspersky/kuma и выполните следующую команду, указав нужные значения параметров и скопированный ранее идентифкатор кластера хранения в параметр --cluster-id:

      ./kuma tools migrate --mongo="mongodb://<mongo_hostname>:<port>" --core-url="https://<FQDN>:<port>" --core-dir="<core_directory>" --cluster-id="<cluster_id>" --batch=<events_count> 2>&1 | tee /tmp/migrate.log | grep -v "debug"

      где:

      • <mongo_hostname> — имя хоста, на котором установлена MongoDB.
      • <FQDN> — полное доменное имя сервера, на котором установлено Ядро KUMA.
      • <port> — номер порта сервера Ядра KUMA.
      • <core_directory> — директория хранения данных Ядра KUMA: в зависимости от типа установки /opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000 или /opt/kaspersky/kuma/core.
      • <cluster_id> — идентификатор кластера хранения, куда вы хотите перенести события алертов KUMA 3.4.
      • <events_count> — количество событий алертов в пачке.

      Пример

      ./kuma tools migrate --mongo="mongodb://localhost:27017" --core-url="https://kuma.example.com:7210" --core-dir="/opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000" --cluster-id="0a123456-789a-0123-ab12-a3fab45ab6a7" --batch=10000 2>&1 | tee /tmp/migrate.log | grep -v "debug"

      Доступные параметры переноса событий алертов из MongoDB в ClickHouse

      Полный вывод команды будет сохранен в файл /tmp/migrate.log.

      Перенос может занять продолжительное время, если алертов много. Чтобы ускорить перенос событий алертов, вы можете применить параметр --batch, предварительно выделив дополнительное дисковое пространство и ОЗУ. Например, 150 000 алертов можно перенести за одну итерацию длительностью около трех минут при ОЗУ 12 ГБ для мигратора и MongoDB и дисковом пространстве 30 ГБ при значении параметра --batch равном 150000. В этом примере значения и продолжительность переноса событий алертов приведены в качестве ориентира. Продолжительность может отличаться в зависимости от количества алертов и событий в алертах, от доступного дискового пространства и ОЗУ, а также от количества событий алертов в пачке, указанном в параметре --batch. Вы можете адаптировать значения под свои нужды.

      Также вы можете ускорить перенос, если хотите перенести только часть событий алертов, например только события алертов за последний год. В таком случае вы можете указать значение параметра --time-limit, который будет соответствовать значению параметра Срок хранения алертов, дни.

      Например, у вас есть события алертов за полтора года, а вы хотите перенести события алертов за последний год. Вы выполняете перенос 18 августа 2025 года, при этом для параметра Срок хранения алертов, дни указано значение 365, тогда в значении параметра --time-limit следует указать 19 августа 2024 года следующим образом: --time-limit="Sun, 19 Aug 2024 00:01:00 UTC".

      Будут перенесены только события алертов за последние 365 дней. Это позволит ускорить перенос событий алертов и избежать переноса лишних событий.

      Если вы не укажете значение параметра --time-limit, будут перенесены все события алертов в ClickHouse, но это может занять больше времени, а события алертов старше заданного срока хранения алертов будут позднее удалены из ClickHouse.

   4. После выполнения команды остановите сервис mongodb и выключите его запуск следующими командами:

      sudo systemctl stop kuma-mongodb.service

      sudo systemctl disable kuma-mongodb.service

   События алертов перенесены.

   После обновления KUMA и переноса событий алертов хранилище для новых событий алертов не указывается автоматически. Вы указали кластер хранения только для переноса существующих событий алертов. Чтобы новые алерты наполнялись событиями, необходимо вручную указать значение параметра Хранилище в параметрах наполнения алертов. Пока значение параметра не будет указано, все новые алерты будут создаваться без событий.

   Перенос событий алертов после обновления KUMA с Ядром KUMA в кластере Kubernetes

   Чтобы перенести события алертов в KUMA с Ядром KUMA в кластере Kubernetes:

   1. В веб-интерфейсе в разделе Ресурсы → Активные сервисы выберите хранилище, куда будут перенесены события алертов, и нажмите Копировать идентификатор. Идентификатор кластера хранения понадобится при выполнении команды по переносу событий алертов.
   2. Запустите контейнер с MongoDB в поде Ядра KUMA, выполнив следующую команду на мастер-контроллере:

      sudo k0s kubectl apply -f /root/k0s/core-manifest.yaml

      Ядро KUMA будет перезапущено.

   3. Подключитесь к мастер-контроллеру кластера k0s и запустите перенос событий алертов, указав полученный ранее идентифкатор кластера хранения в параметр --cluster-id:

      k0s kubectl exec -it deployment/core-deployment -c core -n kuma -- kuma tools migrate --mongo="mongodb://127.0.0.1:27017" --core-url="https://core:7210" --core-dir="/opt/kaspersky/kuma/core" --cluster-id="ec9e34bc-8c05-4f95-bb37-cfd5fe4b354a" --wd="/opt/kaspersky/kuma/core" --batch=10000 2>&1 | tee /tmp/migrate.log | grep -v "debug"

      Доступные параметры переноса событий алертов из MongoDB в ClickHouse

      Полный вывод команды будет сохранен в файл /tmp/migrate.log на хосте, где вы запускаете k0s kubectl, а не в томе пода.

      Перенос может занять продолжительное время, если алертов много. Если прервется SSH-сессия, команда продолжит выполняться на поде. В таком случае запускать команду повторно не нужно. Можно отследить выполнение команды в процессах на рабочем узле где запущено Ядро KUMA:

      sudo watch 'ps -faux | grep "kuma tools migrate"'

      Чтобы ускорить перенос событий алертов, вы можете применить параметр --batch, предварительно выделив дополнительное дисковое пространство и ОЗУ. Например, 150 000 алертов можно перенести за одну итерацию длительностью порядка трех минут при ОЗУ 12 ГБ для мигратора и MongoDB и дисковом пространстве 30 ГБ при значении параметра --batch равном 150000. В этом примере значения и продолжительность переноса событий алертов приведены в качестве ориентира. Продолжительность может отличаться в зависимости от количества алертов и событий в алертах, от доступного дискового пространства и ОЗУ и от количества событий алертов в пачке, указанном в параметре --batch. Вы можете адаптировать значения под свои нужды.

      Также вы можете ускорить перенос, если хотите перенести только часть событий алертов, например, только события алертов за последний год. В таком случае вы можете указать значение параметра --time-limit, который будет соответствовать значению параметра Срок хранения алертов, дни.

      Например, у вас есть события алертов за полтора года, а вы хотите перенести события алертов за последний год. Вы выполняете перенос 18 августа 2025 года, при этом для параметра Срок хранения алертов, дни указано значение 365, тогда в значении параметра --time-limit следует указать 19 августа 2024 года следующим образом:

      --time-limit="Sun, 19 Aug 2024 00:01:00 UTC"

      Будут перенесены только события алертов за последние 365 дней. Это позволит ускорить перенос событий алертов и избежать переноса лишних событий.

      Если вы не укажете значение параметра --time-limit, перенос всех событий алертов в ClickHouse будет выполнен, но это может занять больше времени, а события алертов старше заданного срока хранения алертов будут позднее удалены из ClickHouse.

   4. После успешного переноса событий алертов мы рекомендуем запустить Ядро KUMA без контейнера MongoDB. Для этого на мастер-контроллере выполните запуск Ядра KUMA в версии без контейнера MongoDB с помощью следующей команды:

      sudo k0s kubectl apply -f /root/k0s/core-manifest-no-mongodb.yaml

      Ядро KUMA будет перезапущено.

   События алертов будут перенесены.

   После обновления KUMA и переноса событий алертов хранилище для новых событий алертов не указывается автоматически. Вы указали кластер хранения только для переноса существующих событий алертов. Чтобы новые алерты наполнялись событиями, необходимо вручную указать значение параметра Хранилище в параметрах наполнения алертов. Пока значение параметра не будет указано, все новые алерты будут создаваться без событий.

   После переноса событий алертов в KUMA нужно учитывать особенности их резервного копирования и восстановления такой резервной копии с помощью REST API.

4. Укажите хранилище для новых событий алертов в параметрах наполнения алертов.

Решение KUMA успешно обновлено.

Ограничения:

• Для действующих пользователей при обновлении с 4.0.х до 4.2 не выполняется обновление универсального макета панели мониторинга.

  Возможное решение: перезапустите сервис Ядра kuma-core-<идентификатор сервиса Ядра KUMA>.service. После перезапуска данные будут обновляться с заданным для панели мониторинга интервалом.

Обновление KUMA с версии 4.0.х до версии 4.2 состоит из следующих этапов:

Предварительные действия

1. Убедитесь, что соблюдены все аппаратные и программные требования к установке решения.
2. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 4.0.х.

   Резервные копии KUMA, созданные в версии 4.0.х и ниже, не подлежат восстановлению в версии 4.2. Это означает, что невозможно установить KUMA 4.2 и восстановить в ней резервную копию 4.0.х.

   Сразу после обновления KUMA до версии 4.2 создайте резервную копию.

3. Проверьте имя хоста Ядра KUMA.

   Имя хоста может начинаться с цифры, если это соответствует принятой в организации схеме именования. Однако для работы сервисов KUMA с Raft нужно имя хоста, которое не начинается с цифры.

   Если имя хоста начинается с цифры, переименовывать сервер необязательно. Настройте дополнительное имя (FQDN), начинающееся с буквы, выполнив следующие действия:

   1. В файле /etc/hosts добавьте запись:

      <IP_address> <new_fqdn> <fqdn> <hostname>

      где:

      <IP_address> – IP-адрес сервера;

      <new_fqdn> – дополнительное имя хоста;

      <fqdn> – исходное FQDN;

      <hostname> – короткое имя хоста.

   2. На DNS-сервере создайте CNAME-запись, в которой <new_fqdn> указывает на <fqdn>.

   После настройки используйте дополнительное имя для сервисов KUMA с Raft. Исходное имя хоста изменять не нужно.

4. На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
5. Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
   • Удалите неактуальные источники событий.
   • Измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий.
   • Для политик мониторинга, примененных к неактуальным источникам событий, отключите рассылку уведомлений.

   После обновления KUMA для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.

Обновление KUMA

В зависимости от используемой схемы развертывания KUMA выполните следующие действия:

• Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке решения. В файле инвентаря в секции kuma_metrics необходимо указать хост, на котором запущен активный сервис Метрики. При запуске обновления выполняется проверка и если сервис Метрики на этом хосте не найден, вернется ошибка и обновление прервется.
• Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации с Ядром KUMA в кластере Kubernetes.

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

  Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы → Активные сервисы.

Процесс обновления полностью повторяет процесс установки.

Вы можете изменить тип установки следующим образом:

• Если вы хотите выполнить обновление с распределенной установки до установки с Ядром 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, и затем до версии 3.2, или при новой установке решения. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s и need_transfer значение true. Параметру deploy_example_services необходимо присвоить значение false.

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

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

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

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

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

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

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

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

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

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

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

  Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.

• Если вы хотите обновить KUMA в распределенной установке до последней версии KUMA с Ядром в кластере Raft, в файле инвентаря distributed.inventory.yml вручную добавьте секцию kuma_core_peers и укажите в этой секции четное количество серверов, где вы планируете установить дополнительные сервисы Ядра KUMA. Также в секциях kuma_core и kuma_core_peers вы можете указать параметр raft_node_addr в формате <FQDN сервера из секции kuma_core, на котором установлено Ядро KUMA>:<порт>, если у сервера есть несколько разных FQDN. Указанный в параметре raft_node_addr FQDN будет использоваться для прослушивания сигналов от других узлов.

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

  После обновления все существующие сервисы KUMA будут подключены к Ядру KUMA на сервере из секции kuma_core. При дальнейшей установке новых сервисов вы можете указать несколько URL через запятую в команде установки, чтобы подключить сервисы к Ядрам KUMA в кластере Raft.

Подготовка KUMA к работе

1. После обновления KUMA очистите кеш браузера.
2. Если вы используете агенты, вручную обновите агенты KUMA.
3. Для распределенной установки в отказоустойчивой конфигурации с Ядром KUMA в кластере Kubernetes обновите компоненты кластера.

   Как обновить компоненты кластера Kubernetes

   Обновление компонентов кластера Kubernetes выполняется только в случае обновления KUMA до версии 4.2.x. При установке KUMA 4.2.x с нуля обновлять компоненты кластера Kubernetes не требуется.

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

   Обновление компонентов кластера Kubernetes выполняется с выделенной машины ansible-controller, не являющейся участником кластера Kubernetes, поскольку скрипт обновления предусматривает перезагрузку всех хостов кластера. Если ansible-controller будет машиной внутри кластера, во время штатной перезагрузки хостов кластера выполнение скрипта прервется и работоспособность кластера будет утрачена.

   Обновление компонентов кластера Kubernetes выполняется с помощью скрипта cluster_upgrade.sh и файла инвентаря k0s.inventory.yaml, только на хостах из секции k0s файла инвентаря k0s.inventory.yaml. Внешние сервисы KUMA не затрагиваются.

   По умолчанию скрипт обновления предусматривает автоматическое создание резервной копии.

   Если создание резервной копии Ядра KUMA вручную на случай непредвиденных сбоев обновления заняло значительное время и вы не хотите ждать аналогичное время при автоматическом создании резервной копии, вы можете поместить резервную копию, созданную вручную, на выделенной машине ansible-controller в файл autobackup.tar.gz и запустить скрипт с параметром -e 'manual_restore_only=true'. Применение параметра -e 'manual_restore_only=true' при запуске скрипта позволяет пропустить этап автоматического создания резервной копии и автоматического восстановления данных из резервной копии и таким образом сократить время обновления. В этом случае вам необходимо будет восстановить Ядро KUMA из резервной копии вручную.

   Доступны следующие способы обновления компонентов кластера Kubernetes:

   Обновление компонентов кластера Kubernetes без параметра -e 'manual_restore_only=true'

   Чтобы обновить компоненты кластера Kubernetes без параметра -e 'manual_restore_only=true':

   1. Выполните подготовку к обновлению:
      1. Убедитесь, что выполнено обновление KUMA с версии 4.0.х до 4.2.х с помощью установщика install.sh и файла инвентаря k0s.inventory.yaml.
      2. Подготовьте выделенную машину ansible-controller, с которой вы будете запускать скрипт обновления, и убедитесь, что машина не является участником кластера. Скрипт обновления предусматривает перезагрузку всех хостов кластера. Если ansible-controller будет машиной внутри кластера, во время штатной перезагрузки хостов кластера выполнение скрипта будет прервано и процесс установки новых версий компонентов Kubernetes аварийно завершится.
      3. Убедитесь, что на выделенной машине ansible-controller и на master-controller достаточно свободного дискового пространства для размещения резервной копии.
      4. Создайте резервную копию Ядра KUMA вручную на случай непредвиденных сбоев.

         Данные метрик в резервную копию не входят и в кластер Kubernetes не переносятся. При обновлении компонентов кластера Kubernetes данные метрик будут утрачены.

         Если вам критически важны данные метрик, обратитесь к специалистам Службы технической поддержки перед обновлением компонентов кластера Kubernetes.

      5. Укажите значение параметра backup_timeout в файле инвентаря k0s.inventory.yaml в секции vars.
   2. Выполните обновление:
      1. На выделенной машине ansible-controller перейдите в директорию установщика 4.2 и запустите скрипт cluster_upgrade.sh, передав в качестве параметра имя актуального файла инвентаря k0s.inventory.yaml:

         ./cluster_upgrade.sh k0s.inventory.yaml

      2. В консоли командной строки подтвердите наличие резервной копии Ядра KUMA и согласие с выполнением обновления, указав yes.

         В процессе обновления будет автоматически создана резервная копия Ядра KUMA – autobackup.tar.gz. Скрипт создает резервную копию Ядра KUMA на машине master-controller в директории /root/k0s/, а затем переносит на выделенную машину ansible-controller, с которой выполняется обновление компонентов Kubernetes, в директорию со скриптом. В процессе автоматического восстановления данных Ядра KUMA в новом кластере Kubernetes также используется директория установщика и директория /root/k0s/ на машине master-controller.

         Из резервной копии в дальнейшем будет автоматически выполнено восстановление Ядра KUMA в новом кластере Kubernetes. Если в процессе обновления произойдет сбой, вы сможете поместить созданную вручную резервную копию в файл autobackup.tar.gz, расположенный на машине ansible-controller в директории со скриптом, и перезапустить скрипт cluster_upgrade.sh.

         Перезапись созданной резервной копии автоматически не выполняется.

   Компоненты кластера Kubernetes будут обновлены.

   Восстановление при сбое

   Доступны следующие сценарии восстановления в случае сбоя:

   • Сбой при обновлении компонентов кластера Kubernetes. Вы можете использовать любой из вариантов восстановления:
     • Поместить созданную вручную резервную копию в файл autobackup.tar.gz, расположенный на машине master-controller в директории со скриптом, и перезапустить скрипт cluster_upgrade.sh. Скрипт примет созданную вручную резервную копию в обработку и продолжит процедуру обновления.
     • Запустить скрипт cluster_upgrade.sh с указанием параметра -e 'manual_restore_only=true' и выполнить восстановление вручную.
   • Сбой при запуске Ядра KUMA после успешного обновления кластера Kubernetes.

     Если вы хотите, чтобы скрипт автоматически повторил удаление и новую установку кластера, необходимо остановить службу k0s на любом из узлов кластера и удалить на этом узле исполняемый файл k0s. Скрипт будет интерпретировать состояние кластера как неконсистентное и выполнит удаление и установку кластера с использованием ранее созданного файла autobackup.tar.gz.

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

     sudo systemctl stop k0scontroller.service

     sudo rm /usr/bin/k0s

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

     sudo systemctl stop k0sworker.service

     sudo rm /usr/bin/k0s

     Удаление кластера выполняется только после получения корректного файла резервной копии или явного отказа от автоматического резервного копирования и восстановления применением параметра -e 'manual_restore_only=true' и согласия на продолжение обновления без выполнения резервного копирования. Если у вас отсутствует резервная копия, созданная вручную, в случае сбоя все данные будут утрачены.

   Обновление компонентов кластера Kubernetes с параметром -e 'manual_restore_only=true'

   Чтобы выполнить обновление компонентов кластера Kubernetes с параметром -e 'manual_restore_only=true':

   1. Выполните подготовку к обновлению:
      1. Убедитесь, что выполнено обновление KUMA с версии 4.0.х до 4.2.х с помощью установщика install.sh и файла инвентаря k0s.inventory.yaml.
      2. Подготовьте выделенную машину ansible-controller, с которой вы будете запускать скрипт обновления, и убедитесь, что машина не является участником кластера. Скрипт обновления предусматривает перезагрузку всех хостов кластера. Если ansible-controller будет машиной внутри кластера, во время штатной перезагрузки хостов кластера выполнение скрипта будет прервано и процесс установки новых версий компонентов Kubernetes аварийно завершится.
      3. Убедитесь, что на выделенной машине ansible-controller и на master-controller достаточно свободного дискового пространства для размещения резервной копии.
      4. Создайте резервную копию Ядра KUMA вручную на случай непредвиденных сбоев.

         Данные метрик в резервную копию не входят и в кластер Kubernetes не переносятся. При обновлении компонентов кластера Kubernetes данные метрик будут утрачены.

         Если вам критически важны данные метрик, обратитесь к специалистам Службы технической поддержки перед обновлением компонентов кластера Kubernetes.

   2. Выполните обновление:
      1. На выделенной машине ansible-controller перейдите в директорию установщика KUMA 4.2 и запустите скрипт cluster_upgrade.sh, передав в качестве параметра имя актуального файла инвентаря k0s.inventory.yaml и указав параметр -e 'manual_restore_only=true':

         ./cluster_upgrade.sh k0s.inventory.yaml [-e 'manual_restore_only=true']

         Автоматическое создание резервной копии и автоматическое восстановление из резервной копии отключены. Скрипт удалит старый кластер и создаст новый кластер Kubernetes.

      2. В консоли командной строки подтвердите наличие резервной копии Ядра KUMA и согласие с выполнением обновления, указав yes.

         Если у вас отсутствует созданная вручную резервная копия и вы подтвердите удаление кластера, данные будут утрачены.

   3. Восстановите Ядро KUMA из резервной копии.

   Компоненты кластера Kubernetes обновлены.

   Восстановление при сбое

   В случае сбоя при обновлении перезапустите скрипт cluster_upgrade.sh и выполните восстановление Ядра KUMA из резервной копии вручную.

Решение KUMA успешно обновлено.

Ограничения:

• Для действующих пользователей при обновлении с 4.2 до 4.6 не выполняется обновление универсального макета панели мониторинга.

  Возможное решение: перезапустите сервис Ядра kuma-core-<идентификатор сервиса Ядра KUMA>.service. После перезапуска данные будут обновляться с заданным для панели мониторинга интервалом.

Обновление KUMA с версии 4.2 до версии 4.6 состоит из следующих этапов:

Предварительные действия

1. Убедитесь, что соблюдены все аппаратные и программные требования к установке решения.

   Минимальная версия ядра Linux на целевых хостах при установке решения: 5.15

2. Если решение KUMA развернуто в кластере Kubernetes и вы выполняете обновление KUMA в следующей последовательности: 4.0 → 4.2 → 4.6, вам нужно перевыпустить сертификаты сервиса метрик KUMA. Для этого в KUMA 4.2 после обновления компонентов кластера Kubernetes выполните следующие действия:
   1. Удалите сертификаты сервиса метрик. Для этого на любом контроллере кластера Kubernetes выполните следующие команды из-под учетной записи с root-правами:

      k0s kubectl exec deployment/metrics -n kuma -- rm -rf /opt/kaspersky/kuma/metrics/certificates

      k0s kubectl rollout restart deployment metrics -n kuma

   2. Сбросьте сертификаты сервиса метрик в разделе Активные сервисы. После этого убедитесь, что сервис метрик отображается в зеленом статусе.
3. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 4.2.

   Резервные копии KUMA, созданные в версии 4.2 и ниже, не подлежат восстановлению в версии 4.6. Это означает, что невозможно установить KUMA 4.6 и восстановить в ней резервную копию 4.2.

   Сразу после обновления KUMA до версии 4.6 создайте резервную копию.

4. Проверьте имя хоста Ядра KUMA.

   Имя хоста может начинаться с цифры, если это соответствует принятой в организации схеме именования. Однако для работы сервисов KUMA с Raft нужно имя хоста, которое не начинается с цифры.

   Если имя хоста начинается с цифры, переименовывать сервер необязательно. Настройте дополнительное имя (FQDN), начинающееся с буквы, выполнив следующие действия:

   1. В файле /etc/hosts добавьте запись:

      <IP_address> <new_fqdn> <fqdn> <hostname>

      где:

      <IP_address> – IP-адрес сервера;

      <new_fqdn> – дополнительное имя хоста;

      <fqdn> – исходное FQDN;

      <hostname> – короткое имя хоста.

   2. На DNS-сервере создайте CNAME-запись, в которой <new_fqdn> указывает на <fqdn>.

   После настройки используйте дополнительное имя для сервисов KUMA с Raft. Исходное имя хоста изменять не нужно.

5. На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
6. Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
   • Удалите неактуальные источники событий.
   • Измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий.
   • Для политик мониторинга, примененных к неактуальным источникам событий, отключите рассылку уведомлений.

   После обновления KUMA для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.

Обновление KUMA

В зависимости от используемой схемы развертывания KUMA выполните следующие действия:

• Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке решения. В файле инвентаря в секции kuma_metrics необходимо указать хост, на котором запущен активный сервис Метрики. При запуске обновления выполняется проверка и если сервис Метрики на этом хосте не найден, вернется ошибка и обновление прервется.
• Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации с Ядром KUMA в кластере Kubernetes. Убедитесь, что используется версия Kubernetes 1.33.

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

  Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы → Активные сервисы.

Процесс обновления полностью повторяет процесс установки.

Вы можете изменить тип установки следующим образом:

• Если вы хотите выполнить обновление с распределенной установки до установки с Ядром 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, и затем до версии 3.2, или при новой установке решения. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s и need_transfer значение true. Параметру deploy_example_services необходимо присвоить значение false.

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

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

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

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

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

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

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

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

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

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

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

  Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.

• Если вы хотите обновить KUMA в распределенной установке до последней версии KUMA с Ядром в кластере Raft, в файле инвентаря distributed.inventory.yml вручную добавьте секцию kuma_core_peers и укажите в этой секции четное количество серверов, где вы планируете установить дополнительные сервисы Ядра KUMA. Также в секциях kuma_core и kuma_core_peers вы можете указать параметр raft_node_addr в формате <FQDN сервера из секции kuma_core, на котором установлено Ядро KUMA>:<порт>, если у сервера есть несколько разных FQDN. Указанный в параметре raft_node_addr FQDN будет использоваться для прослушивания сигналов от других узлов.

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

  После обновления все существующие сервисы KUMA будут подключены к Ядру KUMA на сервере из секции kuma_core. При дальнейшей установке новых сервисов вы можете указать несколько URL через запятую в команде установки, чтобы подключить сервисы к Ядрам KUMA в кластере Raft.

Подготовка KUMA к работе

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

Решение KUMA успешно обновлено.