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