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

Чтобы установить KUMA версии 2.1.3 поверх версии 2.0.х, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

1. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить резервную копию для версии 2.0.

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

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

2. Убедитесь, что соблюдены все требования к установке решения.
3. Убедитесь в совместимости версий MongoDB, выполнив на устройстве с Ядром KUMA следующую последовательность команд:

   cd /opt/kaspersky/kuma/mongodb/bin/

   ./mongo

   use kuma

   db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})

   Если версия компонента отличается от 4.4, задайте значение 4.4 с помощью следующей команды: 

   db.adminCommand({ setFeatureCompatibilityVersion: "4.4" })

4. На время установки или обновления обеспечьте сетевую доступность  порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
5. Если в кластере ClickHouse у вас есть кипер, развернутый на отдельном устройстве, перед обновлением установите сервис хранилища на том же устройстве:
   • Используйте существующее хранилище кластера, чтобы создать в веб-интерфейсе сервис хранилища для кипера.
   • Установите сервис на устройстве с выделенным кипером ClickHouse.
6. В файле инвентаря укажите те же хосты, которые использовались при установке KUMA версии 2.0.Х. Присвойте значение false следующим параметрам:

   deploy_to_k8s false

   need_transfer false

   deploy_example_services false

   При работе установщика по такому файлу инвентаря обновляются все компоненты KUMA до версии 2.1.3. Также производится перенастройка имеющихся сервисов и ресурсов хранилища на хостах из группы kuma_storage:

   • Удаляются systemd-сервисы ClickHouse.
   • Удаляются сертификаты из директории /opt/kaspersky/kuma/clickhouse/certificates.
   • Заполняются поля Идентификатор шарда, Идентификатор реплики, Идентификатор кипера и Переопределение параметров ClickHouse для каждого узла в ресурсе хранилища на основании значений из инвентаря и конфигурационных файлов сервиса на хосте. В дальнейшем управление ролями каждого узла вы будет выполнять в веб-интерфейсе KUMA.
   • Удаляются все существующие файлы конфигурации из директории /opt/kaspersky/kuma/clickhouse/cfg (далее они будут генерироваться сервисом хранилища).
   • Изменяется значение параметра LimitNOFILE (секция Service) c 64000 на 500000 в systemd-сервисах kuma-storage.
7. Если вы используете правила сегментации алертов, подготовьте данные для переноса существующих правил и сохраните. На следующем этапе вы сможете использовать эти данные, чтобы заново создать правила. При обновлении правила сегментации алертов не переносятся автоматически.
8. Чтобы выполнить обновление, вам понадобится действительный пароль от пользователя admin. Если вы забыли пароль от пользователя admin, обратитесь в Службу технической поддержки, чтобы сбросить действующий пароль и воспользуйтесь новым паролем, чтобы выполнить обновление на следующем этапе.

Обновление KUMA

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

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

  Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе 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 с хоста, на котором разворачивается главный контроллер.

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

Финальный этап подготовки KUMA к работе

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

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

Чтобы установить KUMA версии 2.1.3 поверх версии 2.1.х, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

1. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить резервную копию для версии 2.1.х.

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

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

2. Убедитесь, что соблюдены все требования к установке решения.
3. На время установки или обновления обеспечьте сетевую доступность  порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
4. Чтобы выполнить обновление, вам понадобится действительный пароль от пользователя admin. Если вы забыли пароль от пользователя admin, обратитесь в Службу технической поддержки, чтобы сбросить действующий пароль и воспользуйтесь новым паролем, чтобы выполнить обновление на следующем этапе.

Обновление KUMA

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

   Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе 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 с хоста, на котором разворачивается главный контроллер.

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

Финальный этап подготовки KUMA к работе

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

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

Чтобы установить KUMA версии 3.0.3 поверх версии 2.1.3, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

1. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 3.0.3.

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

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

2. Убедитесь, что соблюдены все требования к установке решения.
3. На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.

Обновление KUMA

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

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

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

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

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

Финальный этап подготовки KUMA к работе

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

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

Известные ограничения

1. Поскольку в 3.0.2 иерархическая структура не поддерживается, при обновлении с версии 2.1.3 до 3.0.2 все хосты с KUMA становятся независимыми.
2. Для действующих пользователей при обновлении с 2.1.3 до 3.0.2 не выполняется обновление универсального макета панели мониторинга.

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

Чтобы установить KUMA версии 3.0.3 поверх версии 3.0.x, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

1. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 3.0.х.

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

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

2. Убедитесь, что соблюдены все требования к установке решения.
3. На время установки или обновления обеспечьте сетевую доступность  порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.

Обновление KUMA

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

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

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

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

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

Финальный этап подготовки KUMA к работе

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

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

Известные ограничения

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

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

Чтобы установить KUMA версии 3.2.x поверх версии 3.0.3, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

1. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии для версии 3.0.3.

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

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

2. Убедитесь, что соблюдены все требования к установке решения.
3. Убедитесь, что имя хоста Ядра KUMA не начинается с цифры. Обновление до версии 3.2.х не может быть выполнено успешно, если имя хоста Ядра KUMA начинается с цифры. Потребуется ряд мероприятий, чтобы успешно выполнить обновление. Обратитесь в техническую поддержку за дополнительными инструкциями.
4. На время установки или обновления обеспечьте сетевую доступность  порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.

Обновление KUMA

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

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

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

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

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

Финальный этап подготовки KUMA к работе

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

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

Известные ограничения

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

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

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

   sudo systemctl reset-failed

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

Чтобы установить KUMA версии 3.4 поверх версии 3.2.0 или 3.2.1, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

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

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

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

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

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

Обновление KUMA

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

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

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

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

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

Финальный этап подготовки KUMA к работе

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

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

Известные ограничения

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

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

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

   sudo systemctl reset-failed

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

Чтобы установить KUMA версии 4.0 поверх версии 3.4.х, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

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

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

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

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 для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.

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

Обновление KUMA

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

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

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

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

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

• Если вы хотите выполнить обновление с распределенной установки до установки с Ядром KUMA в кластере Kubernetes, выполните обновление распределенной установки до последней версии, а затем выполните Перенос Ядра в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра 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 с хоста, на котором разворачивается главный контроллер.

• Если вы хотите обновить 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.
4. Укажите хранилище для новых событий алертов в параметрах наполнения алертов.

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

Известные ограничения

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

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

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

   sudo systemctl reset-failed

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

Чтобы установить KUMA версии 4.2 поверх версии 4.0.х, выполните шаги предварительной подготовки, а затем выполните обновление.

Предварительная подготовка

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

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

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

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, выполните обновление распределенной установки до последней версии, а затем выполните Перенос Ядра в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра 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 с хоста, на котором разворачивается главный контроллер.

• Если вы хотите обновить 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 обновите компоненты кластера.

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

Известные ограничения

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

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