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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Создайте резервную копию Ядра KUMA. При необходимости вы сможете восстановить данные из резервной копии.
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. При необходимости вы сможете восстановить данные из резервной копии.
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 в новый кластер Kubernetes, выполните следующие шаги:

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

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

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

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

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

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

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

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

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

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

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

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

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

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