Чтобы установить 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 с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:

  cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directory

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

  1. Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
  2. В файле core-transfer-job.yaml.j2 найдите следующие строки:

     cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

     cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&

  3. Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:

     cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

     cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&

  4. Сохраните изменения в файле.

  После этого вы можете повторно запустить распределенную установку с использованием подготовленного файла инвентаря k0s.inventory.yml. Перенос Ядра KUMA с хоста в новый кластер Kubernetes будет выполнен успешно.

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

  Чтобы исправить ошибку после попытки переноса Ядра KUMA с хоста в новый кластер Kubernetes:

  1. На любом контроллере кластера удалите объект Ingress, выполнив следующую команду:

     sudo k0s kubectl delete daemonset/ingress -n ingress

  2. Проверьте, существует ли задача переноса в кластере:

     sudo k0s kubectl get jobs -n kuma

  3. Если задача переноса существует, удалите ее:

     sudo k0s kubectl delete job core-transfer -n kuma

  4. Перейдите в консоль хоста из группы kuma_core.
  5. Запустите сервисы Ядра KUMA, выполнив следующие команды:

     sudo systemctl start kuma-mongodb

     sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000

  6. Убедитесь, что сервис kuma-core-00000000-0000-0000-0000-000000000000 запущен успешно:

     sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000

  7. Убедитесь, что из группы kuma_core есть доступ в интерфейс KUMA по FQDN хоста.

     Другие хосты при этом могут быть остановлены.

  8. Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
  9. В файле core-transfer-job.yaml.j2 найдите следующие строки:

     cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

     cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&

  10. Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:

      cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

      cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&

  11. Сохраните изменения в файле.

  После этого вы можете повторно запустить распределенную установку с использованием подготовленного файла инвентаря k0s.inventory.yaml. Перенос Ядра 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.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 с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:

   cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directory

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

   1. Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
   2. В файле core-transfer-job.yaml.j2 найдите следующие строки:

      cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

      cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&

   3. Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:

      cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

      cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&

   4. Сохраните изменения в файле.

   После этого вы можете повторно запустить распределенную установку с использованием подготовленного файла инвентаря k0s.inventory.yml. Перенос Ядра KUMA с хоста в новый кластер Kubernetes будет выполнен успешно.

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

   Чтобы исправить ошибку после попытки переноса Ядра KUMA с хоста в новый кластер Kubernetes:

   1. На любом контроллере кластера удалите объект Ingress, выполнив следующую команду:

      sudo k0s kubectl delete daemonset/ingress -n ingress

   2. Проверьте, существует ли задача переноса в кластере:

      sudo k0s kubectl get jobs -n kuma

   3. Если задача переноса существует, удалите ее:

      sudo k0s kubectl delete job core-transfer -n kuma

   4. Перейдите в консоль хоста из группы kuma_core.
   5. Запустите сервисы Ядра KUMA, выполнив следующие команды:

      sudo systemctl start kuma-mongodb

      sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000

   6. Убедитесь, что сервис kuma-core-00000000-0000-0000-0000-000000000000 запущен успешно:

      sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000

   7. Убедитесь, что из группы kuma_core есть доступ в интерфейс KUMA по FQDN хоста.

      Другие хосты при этом могут быть остановлены.

   8. Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
   9. В файле core-transfer-job.yaml.j2 найдите следующие строки:

      cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

      cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&

   10. Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:

       cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

       cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&

   11. Сохраните изменения в файле.

   После этого вы можете повторно запустить распределенную установку с использованием подготовленного файла инвентаря k0s.inventory.yaml. Перенос Ядра 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. При необходимости вы сможете восстановить данные из резервной копии для версии 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 в новый кластер 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 в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе 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 с хоста, на котором разворачивается главный контроллер.