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

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

Схема обновления версий:

2.0.х → 2.1.3 → 3.0.3 → 3.2.x → 3.4.х → 4.0

2.1.х → 2.1.3 → 3.0.3 → 3.2.x → 3.4.х → 4.0

2.1.3 → 3.0.3 → 3.2.x → 3.4.х → 4.0

3.0.x → 3.0.3 → 3.2.x → 3.4.х → 4.0

Если вы вносили изменения в unit-файлы сервисов KUMA в каталоге /usr/lib/systemd/system вручную, то при обновлении с предыдущей версии KUMA эти изменения будут потеряны. Если потребуется, внесите изменения повторно после обновления приложения.

Обновление с версии 2.0.x до 2.1.3

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

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

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

Сразу после обновления KUMA до версии 2.1.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" })
На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
Если в кластере ClickHouse у вас есть кипер, развернутый на отдельном устройстве, перед обновлением установите сервис хранилища на том же устройстве:
- Используйте существующее хранилище кластера, чтобы создать в веб-интерфейсе сервис хранилища для кипера.
- Установите сервис на устройстве с выделенным кипером ClickHouse.
В файле инвентаря укажите те же хосты, которые использовались при установке 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.
Если вы используете правила сегментации алертов, подготовьте данные для переноса существующих правил и сохраните. На следующем этапе вы сможете использовать эти данные, чтобы заново создать правила. При обновлении правила сегментации алертов не переносятся автоматически.
Чтобы выполнить обновление, вам понадобится действительный пароль от пользователя admin. Если вы забыли пароль от пользователя admin, обратитесь в Службу технической поддержки, чтобы сбросить действующий пароль и воспользуйтесь новым паролем, чтобы выполнить обновление на следующем этапе.

Обновление KUMA

В зависимости от используемой схемы развертывания 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/<идентификатор сервиса Ядра 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 с хоста, на котором разворачивается главный контроллер.

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

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

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

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

Обновление с версии 2.1.x до 2.1.3

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

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

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

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

Обновление KUMA

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

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

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

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

Обновление с версии 2.1.3 до 3.0.3

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

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

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

Сразу после обновления KUMA до версии 3.0.3 создайте резервную копию.
Убедитесь, что соблюдены все требования к установке программы.
На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.

Обновление KUMA

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

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

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

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

Подготовьте файл инвентаря 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.
Выполните шаги распределенной установки с использованием подготовленного файла инвентаря 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:

Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

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

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

На любом контроллере кластера удалите объект Ingress, выполнив следующую команду:
sudo k0s kubectl delete daemonset/ingress -n ingress
Проверьте, существует ли задача переноса в кластере:
sudo k0s kubectl get jobs -n kuma
Если задача переноса существует, удалите ее:
sudo k0s kubectl delete job core-transfer -n kuma
Перейдите в консоль хоста из группы kuma_core.
Запустите сервисы Ядра KUMA, выполнив следующие команды:
sudo systemctl start kuma-mongodb

sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что сервис kuma-core-00000000-0000-0000-0000-000000000000 запущен успешно:
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что из группы kuma_core есть доступ в интерфейс KUMA по FQDN хоста.
Другие хосты при этом могут быть остановлены.
Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

После этого вы можете повторно запустить распределенную установку с использованием подготовленного файла инвентаря 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/<идентификатор сервиса Ядра 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 очистите кеш браузера.
Вручную обновите агенты KUMA.

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

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

Поскольку в 3.0.2 иерархическая структура не поддерживается, при обновлении с версии 2.1.3 до 3.0.2 все хосты с KUMA становятся независимыми.
Для действующих пользователей при обновлении с 2.1.3 до 3.0.2 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.

Обновление с версии 3.0.x до 3.0.3

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

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

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

Сразу после обновления KUMA до версии 3.0.3 создайте резервную копию.
Убедитесь, что соблюдены все требования к установке программы.
На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.

Обновление KUMA

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

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

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

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

Подготовьте файл инвентаря 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.
Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

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

Устранение ошибки невозможности переноса Ядра KUMA

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

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

Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

На любом контроллере кластера удалите объект Ingress, выполнив следующую команду:
sudo k0s kubectl delete daemonset/ingress -n ingress
Проверьте, существует ли задача переноса в кластере:
sudo k0s kubectl get jobs -n kuma
Если задача переноса существует, удалите ее:
sudo k0s kubectl delete job core-transfer -n kuma
Перейдите в консоль хоста из группы kuma_core.
Запустите сервисы Ядра KUMA, выполнив следующие команды:
sudo systemctl start kuma-mongodb

sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что сервис kuma-core-00000000-0000-0000-0000-000000000000 запущен успешно:
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что из группы kuma_core есть доступ в интерфейс KUMA по FQDN хоста.
Другие хосты при этом могут быть остановлены.
Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

Удаляет с хоста 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/<идентификатор сервиса Ядра 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

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

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

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

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

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

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

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

Обновление с версии 3.0.3 до 3.2.x

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

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

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

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

Обновление KUMA

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

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

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

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

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

Подготовьте файл инвентаря 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.
Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

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

Устранение ошибки невозможности переноса Ядра KUMA

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

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

Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

На любом контроллере кластера удалите объект Ingress, выполнив следующую команду:
sudo k0s kubectl delete daemonset/ingress -n ingress
Проверьте, существует ли задача переноса в кластере:
sudo k0s kubectl get jobs -n kuma
Если задача переноса существует, удалите ее:
sudo k0s kubectl delete job core-transfer -n kuma
Перейдите в консоль хоста из группы kuma_core.
Запустите сервисы Ядра KUMA, выполнив следующие команды:
sudo systemctl start kuma-mongodb

sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что сервис kuma-core-00000000-0000-0000-0000-000000000000 запущен успешно:
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что из группы kuma_core есть доступ в интерфейс KUMA по FQDN хоста.
Другие хосты при этом могут быть остановлены.
Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

Удаляет с хоста 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/<идентификатор сервиса Ядра 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

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

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

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

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

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

Для действующих пользователей при обновлении с 3.0.3 до 3.2.x не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.
Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:
sudo systemctl reset-failed

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

Обновление с версии 3.2.0 или 3.2.1 до 3.4

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

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

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

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

Обновление KUMA

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

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

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

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

Подготовьте файл инвентаря 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.
Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

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

Устранение ошибки невозможности переноса Ядра KUMA

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

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

Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

На любом контроллере кластера удалите объект Ingress, выполнив следующую команду:
sudo k0s kubectl delete daemonset/ingress -n ingress
Проверьте, существует ли задача переноса в кластере:
sudo k0s kubectl get jobs -n kuma
Если задача переноса существует, удалите ее:
sudo k0s kubectl delete job core-transfer -n kuma
Перейдите в консоль хоста из группы kuma_core.
Запустите сервисы Ядра KUMA, выполнив следующие команды:
sudo systemctl start kuma-mongodb

sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что сервис kuma-core-00000000-0000-0000-0000-000000000000 запущен успешно:
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Убедитесь, что из группы kuma_core есть доступ в интерфейс KUMA по FQDN хоста.
Другие хосты при этом могут быть остановлены.
Перейдите в папку с распакованным установщиком и откройте файл roles/k0s_prepare/templates/core-transfer-job.yaml.j2 для изменения.
В файле core-transfer-job.yaml.j2 найдите следующие строки:
cp /mnt/kuma-source/core/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/.tenantsEPS {{ core_k0s_home }}/ &&
Измените эти строки следующим образом с сохранением отступов, задающихся пробелами:
cp /mnt/kuma-source/core/{{ core_uid }}/.lic {{ core_k0s_home }}/ &&

cp /mnt/kuma-source/core/{{ core_uid }}/.tenantsEPS {{ core_k0s_home }}/ &&
Сохраните изменения в файле.

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

Удаляет с хоста 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/<идентификатор сервиса Ядра 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

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

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

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

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

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

Для действующих пользователей при обновлении с 3.2.0 или 3.2.1 до 3.4 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.
Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:
sudo systemctl reset-failed

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

Обновление с версии 3.4.х до 4.0

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

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

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

Сразу после обновления KUMA до версии 4.0 создайте резервную копию.
Убедитесь, что соблюдены все требования к установке программы.
Убедитесь, что имя хоста Ядра KUMA не начинается с цифры. Обновление до версии 4.0 не может быть выполнено успешно, если имя хоста Ядра KUMA начинается с цифры. Если имя хоста Ядра KUMA начинается с цифры, потребуется ряд мероприятий, чтобы успешно выполнить обновление. Обратитесь в техническую поддержку за дополнительными инструкциями.
На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре KUMA с хостов хранилищ KUMA.
Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
- удалите неактуальные источники событий;
- измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий;
- для политик мониторинга, примененных к неактуальным источникам событий, отключите рассылку уведомлений.
После обновления KUMA для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.
Для установки с Ядром 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 с хоста в новый кластер 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/<идентификатор сервиса Ядра 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 к работе

После обновления KUMA очистите кеш браузера.
Если вы используете агенты, вручную обновите агенты KUMA.
Выполните миграцию событий алертов из MongoDB в ClickHouse.
Укажите хранилище для новых событий алертов в параметрах наполнения алертов.

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

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

Для действующих пользователей при обновлении с 3.4.х до 4.0 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для панели мониторинга интервалом.
Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:
sudo systemctl reset-failed

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

В начало