Kaspersky Unified Monitoring and Analysis Platform
3.2
Русский

Содержание

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

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

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

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

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

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

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

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

Перенос Ядра KUMA с хоста в новый кластер Kubernetes может прерываться из-за превышения времени ожидания на шаге Deploy Core transfer job. После этого в журнале задач переноса core-transfer появится следующая запись об ошибке:

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

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

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

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

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

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

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

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

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

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

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

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

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

    sudo k0s kubectl delete daemonset/ingress -n ingress

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

    sudo k0s kubectl get jobs -n kuma

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

    sudo k0s kubectl delete job core-transfer -n kuma

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

    sudo systemctl start kuma-mongodb

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также:

Распределенная установка в отказоустойчивой конфигурации
В начало
[Topic 244734]