Обновление предыдущих версий LogAnalyzer
Обновление выполняется одинаково на всех хостах с использованием установщика и файла инвентаря.
Схема обновления версий:
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-файлы сервисов LogAnalyzer в каталоге /usr/lib/systemd/system вручную, то при обновлении с предыдущей версии LogAnalyzer эти изменения будут потеряны. Если потребуется, внесите изменения повторно после обновления приложения.
Обновление с версии 2.0.x до 2.1.3
Чтобы установить LogAnalyzer версии 2.1.3 поверх версии 2.0.х, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить резервную копию для версии 2.0.
Резервные копии LogAnalyzer, созданные в версии 2.0 и ниже, не подлежат восстановлению в версии 2.1.3. Это означает, что невозможно установить LogAnalyzer 2.1.3 и восстановить в ней резервную копию LogAnalyzer 2.0.
Сразу после обновления LogAnalyzer до версии 2.1.3 создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- Убедитесь в совместимости версий MongoDB, выполнив на устройстве с Ядром LogAnalyzer следующую последовательность команд:
cd /opt/kaspersky/kuma/mongodb/bin/./mongouse kumadb.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})Если версия компонента отличается от 4.4, задайте значение 4.4 с помощью следующей команды:
db.adminCommand({ setFeatureCompatibilityVersion: "4.4" }) - На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
- Если в кластере ClickHouse у вас есть кипер, развернутый на отдельном устройстве, перед обновлением установите сервис хранилища на том же устройстве:
- Используйте существующее хранилище кластера, чтобы создать в веб-интерфейсе сервис хранилища для кипера.
- Установите сервис на устройстве с выделенным кипером ClickHouse.
- В файле инвентаря укажите те же хосты, которые использовались при установке LogAnalyzer версии 2.0.Х. Присвойте значение
falseследующим параметрам:deploy_to_k8s falseneed_transfer falsedeploy_example_services falseПри работе установщика по такому файлу инвентаря обновляются все компоненты KUMA до версии 2.1.3. Также производится перенастройка имеющихся сервисов и ресурсов хранилища на хостах из группы kuma_storage:
- Удаляются systemd-сервисы ClickHouse.
- Удаляются сертификаты из директории /opt/kaspersky/kuma/clickhouse/certificates.
- Заполняются поля Идентификатор шарда, Идентификатор реплики, Идентификатор кипера и Переопределение параметров ClickHouse для каждого узла в ресурсе хранилища на основании значений из инвентаря и конфигурационных файлов сервиса на хосте. В дальнейшем управление ролями каждого узла вы будет выполнять в веб-интерфейсе LogAnalyzer.
- Удаляются все существующие файлы конфигурации из директории /opt/kaspersky/kuma/clickhouse/cfg (далее они будут генерироваться сервисом хранилища).
- Изменяется значение параметра LimitNOFILE (секция Service) c 64000 на 500000 в systemd-сервисах kuma-storage.
- Если вы используете правила сегментации алертов, подготовьте данные для переноса существующих правил и сохраните. На следующем этапе вы сможете использовать эти данные, чтобы заново создать правила. При обновлении правила сегментации алертов не переносятся автоматически.
- Чтобы выполнить обновление, вам понадобится действительный пароль от пользователя admin. Если вы забыли пароль от пользователя admin, обратитесь в Службу технической поддержки, чтобы сбросить действующий пароль и воспользуйтесь новым паролем, чтобы выполнить обновление на следующем этапе.
Обновление LogAnalyzer
- В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге
Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directoryЧтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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 с хоста, на котором разворачивается главный контроллер.
- Подготовьте файл инвентаря k0s.inventory.yml.
- При обновлении на системах, которые содержат большие данные и при этом работают на предельных ресурсах, после того, как вы введете пароль администратора, система может вернуть сообщение об ошибке Wrong admin password. Если вы указываете верный пароль, LogAnalyzer может все равно возвращать ошибку, потому что LogAnalyzer не удалось запустить сервис Ядра из-за ошибки по таймауту и предельных ресурсов. Если вы введете пароль администратора трижды, не дожидаясь завершения установки, обновление может завершиться фатальной ошибкой. Устраните ошибку по таймауту, чтобы продолжить обновление.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Создайте заново правила сегментации алертов.
- Вручную обновите агенты LogAnalyzer.
Обновление LogAnalyzer успешно выполнено.
Обновление с версии 2.1.x до 2.1.3
Чтобы установить LogAnalyzer версии 2.1.3 поверх версии 2.1.х, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить резервную копию для версии 2.1.х.
Резервные копии LogAnalyzer, созданные в версии ниже 2.1.3, не подлежат восстановлению в версии 2.1.3. Это означает, что невозможно установить LogAnalyzer 2.1.3 и восстановить в ней резервную копию LogAnalyzer 2.1.х.
Сразу после обновления LogAnalyzer до версии 2.1.3 создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
- Чтобы выполнить обновление, вам понадобится действительный пароль от пользователя admin. Если вы забыли пароль от пользователя admin, обратитесь в Службу технической поддержки, чтобы сбросить действующий пароль и воспользуйтесь новым паролем, чтобы выполнить обновление на следующем этапе.
Обновление LogAnalyzer
- В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге
Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directoryЧтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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. Если вы указываете верный пароль, LogAnalyzer может все равно возвращать ошибку, потому что LogAnalyzer не удалось запустить сервис Ядра из-за ошибки по таймауту и предельных ресурсов. Если вы введете пароль администратора трижды, не дожидаясь завершения установки, обновление может завершиться фатальной ошибкой. Устраните ошибку по таймауту, чтобы продолжить обновление.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Вручную обновите агенты LogAnalyzer.
Обновление LogAnalyzer успешно выполнено.
Обновление с версии 2.1.3 до 3.0.3
Чтобы установить LogAnalyzer версии 3.0.3 поверх версии 2.1.3, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить данные из резервной копии для версии 3.0.3.
Резервные копии LogAnalyzer, созданные в версии 2.1.3 и ниже, не подлежат восстановлению в версии 3.0.3. Это означает, что невозможно установить LogAnalyzer 3.0.3 и восстановить в ней резервную копию LogAnalyzer 2.1.3.
Сразу после обновления LogAnalyzer до версии 3.0.3 создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
Обновление LogAnalyzer
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:
cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directory
Чтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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 с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Вручную обновите агенты LogAnalyzer.
Обновление LogAnalyzer успешно выполнено.
Известные ограничения
- Поскольку в 3.0.2 иерархическая структура не поддерживается, при обновлении с версии 2.1.3 до 3.0.2 все хосты с LogAnalyzer становятся независимыми.
- Для действующих пользователей при обновлении с 2.1.3 до 3.0.2 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.
Обновление с версии 3.0.x до 3.0.3
Чтобы установить LogAnalyzer версии 3.0.3 поверх версии 3.0.x, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить данные из резервной копии для версии 3.0.х.
Резервные копии LogAnalyzer, созданные в версии ниже 3.0.3, не подлежат восстановлению в версии 3.0.3. Это означает, что невозможно установить LogAnalyzer 3.0.3 и восстановить в ней резервную копию LogAnalyzer 3.0.х.
Сразу после обновления LogAnalyzer до версии 3.0.3 создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
Обновление LogAnalyzer
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:
cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directory
Чтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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 с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Вручную обновите агенты LogAnalyzer.
Обновление LogAnalyzer успешно выполнено.
Известные ограничения
Для действующих пользователей при обновлении с 3.0.x до 3.0.3 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.
Обновление с версии 3.0.3 до 3.2.x
Чтобы установить LogAnalyzer версии 3.2.x поверх версии 3.0.3, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить данные из резервной копии для версии 3.0.3.
Резервные копии LogAnalyzer, созданные в версии 3.0.3 и ниже, не подлежат восстановлению в версии 3.2.x. Это означает, что невозможно установить LogAnalyzer 3.2.x и восстановить в ней резервную копию 3.0.3.
Сразу после обновления LogAnalyzer до версии 3.2.x создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- Убедитесь, что имя хоста Ядра LogAnalyzer не начинается с цифры. Обновление до версии 3.2.х не может быть выполнено успешно, если имя хоста Ядра LogAnalyzer начинается с цифры. Потребуется ряд мероприятий, чтобы успешно выполнить обновление. Обратитесь в техническую поддержку за дополнительными инструкциями.
- На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
Обновление LogAnalyzer
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра LogAnalyzer в кластер Kubernetes уже выполнен и больше не требуется.
Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:
cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directory
Чтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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 с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Если вы используете агенты, вручную обновите агенты LogAnalyzer.
Обновление LogAnalyzer успешно выполнено.
Известные ограничения
- Для действующих пользователей при обновлении с 3.0.3 до 3.2.x не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.
- Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:
sudo systemctl reset-failed
После выполнения команды старый сервис перестанет отображаться, а новый сервис успешно запустится.
Обновление с версии 3.2.0 или 3.2.1 до 3.4
Чтобы установить LogAnalyzer версии 3.4 поверх версии 3.2.0 или 3.2.1, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить данные из резервной копии для версии 3.2.
Резервные копии LogAnalyzer, созданные в версии 3.2 и ниже, не подлежат восстановлению в версии 3.4. Это означает, что невозможно установить LogAnalyzer 3.4 и восстановить в ней резервную копию 3.2.х.
Сразу после обновления LogAnalyzer до версии 3.4 создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- Убедитесь, что имя хоста Ядра LogAnalyzer не начинается с цифры. Обновление до версии 3.4 не может быть выполнено успешно, если имя хоста Ядра LogAnalyzer начинается с цифры. Если имя хоста Ядра LogAnalyzer начинается с цифры, потребуется ряд мероприятий, чтобы успешно выполнить обновление. Обратитесь в техническую поддержку за дополнительными инструкциями.
- На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
- Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
- удалите неактуальные источники событий;
- измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий;
- для политик мониторинга, примененных к неактуальным источникам событий, отключите рассылку уведомлений.
После обновления LogAnalyzer для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.
Обновление LogAnalyzer
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации.
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра LogAnalyzer в кластер Kubernetes уже выполнен и больше не требуется.
Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:
cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directory
Чтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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 с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Если вы используете агенты, вручную обновите агенты LogAnalyzer.
Обновление LogAnalyzer успешно выполнено.
Известные ограничения
- Для действующих пользователей при обновлении с 3.2.0 или 3.2.1 до 3.4 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для макета интервалом.
- Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:
sudo systemctl reset-failed
После выполнения команды старый сервис перестанет отображаться, а новый сервис успешно запустится.
Обновление с версии 3.4.х до 4.0
Чтобы установить LogAnalyzer версии 4.0 поверх версии 3.4.х, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
- Создайте резервную копию Ядра LogAnalyzer. При необходимости вы сможете восстановить данные из резервной копии для версии 3.4.х.
Резервные копии LogAnalyzer, созданные в версии 3.4.х и ниже, не подлежат восстановлению в версии 4.0. Это означает, что невозможно установить LogAnalyzer 4.0 и восстановить в ней резервную копию 3.4.х.
Сразу после обновления LogAnalyzer до версии 4.0 создайте резервную копию.
- Убедитесь, что соблюдены все требования к установке программы.
- Убедитесь, что имя хоста Ядра LogAnalyzer не начинается с цифры. Обновление до версии 4.0 не может быть выполнено успешно, если имя хоста Ядра LogAnalyzer начинается с цифры. Если имя хоста Ядра LogAnalyzer начинается с цифры, потребуется ряд мероприятий, чтобы успешно выполнить обновление. Обратитесь в техническую поддержку за дополнительными инструкциями.
- На время установки или обновления обеспечьте сетевую доступность порта 7220 TCP на Ядре LogAnalyzer с хостов хранилищ LogAnalyzer.
- Проверьте количество и актуальность источников событий, для которых отображается красный статус, в разделе Состояние источников → Список источников событий и для неактуальных источников событий выполните одно из следующих действий:
- удалите неактуальные источники событий;
- измените параметры политик мониторинга, примененных к неактуальным источникам событий, так, чтобы они соответствовали актуальному потоку событий;
- для политик мониторинга, примененных к неактуальным источникам событий, отключите рассылку уведомлений.
После обновления LogAnalyzer для всех источников событий с красным статусом, для которых настроена отправка уведомлений о срабатывании политики, будут отправлены уведомления на указанные адреса электронной почты.
- Для установки с Ядром LogAnalyzer в кластере Kubernetes запустите скрипт для определения размера данных метрик на томе Ядра LogAnalyzer 3.4, при необходимости задайте или переопределите значения параметров
metrics_transfer_job_timeout,metrics_disk_request,core_disk_requestв файле инвентаря k0s.inventory.yml, а затем перейдите к обновлению.
Обновление LogAnalyzer
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
- Используйте подготовленный файл инвентаря distributed.inventory.yml и следуйте инструкции по распределенной установке программы.
- Используйте подготовленный файл инвентаря k0s.inventory.yml и следуйте инструкции по распределенной установке в отказоустойчивой конфигурации с Ядром LogAnalyzer в кластере Kubernetes .
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе LogAnalyzer, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Вы можете изменить тип установки следующим образом:
- Если вы хотите выполнить обновление с распределенной установки до установки с Ядром LogAnalyzer в кластере Kubernetes, выполните обновление распределенной установки до последней версии, а затем выполните Перенос Ядра в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром
need_transfer: false, поскольку перенос Ядра LogAnalyzer в кластер Kubernetes уже выполнен и больше не требуется.Чтобы перенести Ядро LogAnalyzer в новый кластер 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.
Процесс переноса Ядра LogAnalyzer в новый кластер Kubernetes
При запуске установщика с файлом инвентаря производится поиск установленного Ядра LogAnalyzer на всех хостах, на которых планируется размещать рабочие узлы кластера. Найденное Ядро будет перенесено с хоста внутрь создаваемого кластера Kubernetes.
Устранение ошибки невозможности переноса Ядра LogAnalyzer
Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге
Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:cp: can't stat '/mnt/kuma-source/core/.lic': No such file or directoryЧтобы предотвратить появление ошибки до начала переноса Ядра LogAnalyzer:
- Перейдите в папку с распакованным установщиком и откройте файл 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если вы начали перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes и он завершился с ошибкой, вам нужно выполнить шаги ниже, чтобы исправить ошибку.
Чтобы исправить ошибку после попытки переноса Ядра LogAnalyzer с хоста в новый кластер 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.
- Запустите сервисы Ядра LogAnalyzer, выполнив следующие команды:
sudo systemctl start kuma-mongodbsudo 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. Перенос Ядра LogAnalyzer с хоста в новый кластер Kubernetes будет выполнен успешно.
Если на рабочих узлах компонент не обнаружен, то производится чистая установка Ядра LogAnalyzer в кластер без переноса в него ресурсов. Существующие компоненты требуется пересоздать с новым Ядром вручную в веб-интерфейсе LogAnalyzer.
Для коллекторов и хранилищ из файла инвентаря будут заново выпущены сертификаты для связи с Ядром внутри кластера. 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 с хоста, на котором разворачивается главный контроллер.
- Подготовьте файл инвентаря k0s.inventory.yml.
- Если вы хотите обновить LogAnalyzer в распределенной установке до последней версии LogAnalyzer с Ядром в кластере Raft, в файле инвентаря distributed.inventory.yml необходимо вручную добавить группу
kuma_core_peersи указать в этой группе четное количество серверов, где вы планируете установить дополнительные сервисы Ядра LogAnalyzer. Также в группеkuma_coreиkuma_core_peersвы можете указать параметрraft_node_addrв формате <FQDN сервера из группы kuma_core, на котором установлено Ядро KUMA>:<порт>, если у сервера есть несколько разных FQDN. Указанный в параметреraft_node_addrFQDN будет использоваться для прослушивания сигналов от других узлов.После запуска установщика с подготовленным файлом инвентаря никакие дополнительные сервисы Ядра LogAnalyzer не устанавливаются на серверах автоматически. Установщик только готовит указанные в файле инвентаря серверы к установке сервисов. После завершения работы установщика автоматически установлен только один сервис Ядра LogAnalyzer на сервере указанном в группе
kuma_core. После завершения работы установщика вам необходимо вручную создать сервисы Ядра LogAnalyzer в веб-интерфейсе и последовательно установить сервис Ядра LogAnalyzer с уникальным идентификатором на каждом сервере, указанном в группеkuma_core_peers.После обновления все существующие сервисы LogAnalyzer будут подключены к Ядру LogAnalyzer на сервере из группы
kuma_core. При дальнейшей установке новых сервисов вы можете указать несколько URL через запятую в команде установки, чтобы подключить сервисы к Ядрам LogAnalyzer в кластере Raft.
Финальный этап подготовки LogAnalyzer к работе
- После обновления LogAnalyzer очистите кеш браузера.
- Если вы используете агенты, вручную обновите агенты LogAnalyzer.
- Выполните миграцию событий алертов из MongoDB в ClickHouse.
- Укажите хранилище для новых событий алертов в параметрах наполнения алертов.
Обновление LogAnalyzer успешно выполнено.
Известные ограничения
- Для действующих пользователей при обновлении с 3.4.х до 4.0 не выполняется обновление универсального макета панели мониторинга.
Возможное решение: перезапустите сервис Ядра kuma-core.service - данные будут обновляться с заданным для панели мониторинга интервалом.
- Если после обновления остался отображается старый сервис Ядра kuma-core.service, после завершения установки выполните следующую команду:
sudo systemctl reset-failedПосле выполнения команды старый сервис перестанет отображаться, а новый сервис успешно запустится.