Обновление выполняется одинаково на всех хостах с использованием установщика и файла инвентаря.
Схема обновления версий:
2.0.х → 2.1.3 → 3.0.3 → 3.2.x
2.1.х → 2.1.3 → 3.0.3 → 3.2.x
2.1.3 → 3.0.3 → 3.2.x
3.0.x → 3.0.3 → 3.2.x
Обновление с версии 2.0.x до 2.1.3
Чтобы установить KUMA версии 2.1.3 поверх версии 2.0.х, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
Резервные копии KUMA, созданные в версии 2.0 и ниже, не подлежат восстановлению в версии 2.1.3. Это означает, что невозможно установить с нуля KUMA 2.1.3 и восстановить в ней резервную копию KUMA 2.0.
Сразу после обновления KUMA до версии 2.1.3 создайте резервную копию.
cd /opt/kaspersky/kuma/mongodb/bin/
./mongo
use kuma
db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1})
Если версия компонента отличается от 4.4, задайте значение 4.4 с помощью следующей команды:
db.adminCommand({ setFeatureCompatibilityVersion: "4.4" })
false следующим параметрам: deploy_to_k8s false
need_transfer false
deploy_example_services false
При работе установщика по такому файлу инвентаря обновляются все компоненты KUMA до версии 2.1.3. Также производится перенастройка имеющихся сервисов и ресурсов хранилища на хостах из группы kuma_storage:
Обновление KUMA
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:
В файле инвентаря 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.
Процесс переноса Ядра 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:
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:
sudo k0s kubectl delete daemonset/ingress -n ingress
sudo k0s kubectl get jobs -n kuma
sudo k0s kubectl delete job core-transfer -n kuma
sudo systemctl start kuma-mongodb
sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Другие хосты при этом могут быть остановлены.
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 Ядра для компонентов при этом не изменится.
На хосте с Ядром установщик выполняет следующие действия:
После проверки корректности переноса Ядра в кластер данные директории можно удалить.
В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).
При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.
Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки KUMA к работе
Обновление KUMA успешно выполнено.
Обновление с версии 2.1.x до 2.1.3
Чтобы установить KUMA версии 2.1.3 поверх версии 2.1.х, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
Резервные копии KUMA, созданные в версии ниже 2.1.3, не подлежат восстановлению в версии 2.1.3. Это означает, что невозможно установить с нуля KUMA 2.1.3 и восстановить в ней резервную копию KUMA 2.1.х.
Сразу после обновления KUMA до версии 2.1.3 создайте резервную копию.
Обновление KUMA
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:
В файле инвентаря 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.
Процесс переноса Ядра 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:
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:
sudo k0s kubectl delete daemonset/ingress -n ingress
sudo k0s kubectl get jobs -n kuma
sudo k0s kubectl delete job core-transfer -n kuma
sudo systemctl start kuma-mongodb
sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Другие хосты при этом могут быть остановлены.
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 Ядра для компонентов при этом не изменится.
На хосте с Ядром установщик выполняет следующие действия:
После проверки корректности переноса Ядра в кластер данные директории можно удалить.
В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).
При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.
Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки KUMA к работе
Обновление KUMA успешно выполнено.
Обновление с версии 2.1.3 до 3.0.3
Чтобы установить KUMA версии 3.0.3 поверх версии 2.1.3, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
Резервные копии KUMA, созданные в версии 2.1.3 и ниже, не подлежат восстановлению в версии 3.0.3. Это означает, что невозможно установить с нуля KUMA 3.0.3 и восстановить в ней резервную копию KUMA 2.1.3.
Сразу после обновления KUMA до версии 3.0.3 создайте резервную копию.
Обновление KUMA
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:
В файле инвентаря 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.
Процесс переноса Ядра 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:
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:
sudo k0s kubectl delete daemonset/ingress -n ingress
sudo k0s kubectl get jobs -n kuma
sudo k0s kubectl delete job core-transfer -n kuma
sudo systemctl start kuma-mongodb
sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Другие хосты при этом могут быть остановлены.
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 Ядра для компонентов при этом не изменится.
На хосте с Ядром установщик выполняет следующие действия:
После проверки корректности переноса Ядра в кластер данные директории можно удалить.
В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса 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-core.service - данные будут обновляться с заданным для макета интервалом.
Обновление с версии 3.0.x до 3.0.3
Чтобы установить KUMA версии 3.0.3 поверх версии 3.0.x, выполните шаги предварительной подготовки, а затем выполните обновление.
Предварительная подготовка
Резервные копии KUMA, созданные в версии ниже 3.0.3, не подлежат восстановлению в версии 3.0.3. Это означает, что невозможно установить с нуля KUMA 3.0.3 и восстановить в ней резервную копию KUMA 3.0.х.
Сразу после обновления KUMA до версии 3.0.3 создайте резервную копию.
Обновление KUMA
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes.
Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:
В файле инвентаря 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.
Процесс переноса Ядра 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:
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:
sudo k0s kubectl delete daemonset/ingress -n ingress
sudo k0s kubectl get jobs -n kuma
sudo k0s kubectl delete job core-transfer -n kuma
sudo systemctl start kuma-mongodb
sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Другие хосты при этом могут быть остановлены.
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 Ядра для компонентов при этом не изменится.
На хосте с Ядром установщик выполняет следующие действия:
После проверки корректности переноса Ядра в кластер данные директории можно удалить.
В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).
При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.
Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.
Финальный этап подготовки 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 и ниже, не подлежат восстановлению в версии 3.2.x. Это означает, что невозможно установить с нуля KUMA 3.2.x и восстановить в ней резервную копию 3.0.3.
Сразу после обновления KUMA до версии 3.2.x создайте резервную копию.
Обновление KUMA
В зависимости от используемой схемы развертывания KUMA выполните следующие действия:
Если файл инвентаря для действующей версии недоступен, воспользуйтесь шаблоном файла инвентаря в поставке и заполните соответствующие параметры. Чтобы посмотреть список хостов и роли хостов в действующей системе KUMA, в веб-интерфейсе перейдите в раздел Ресурсы - Активные сервисы.
Процесс обновления полностью повторяет процесс установки.
Если вы хотите выполнить обновление с распределенной установки до распределенной установки в отказоустойчивой конфигурации, выполните обновление распределенной установки, а затем выполните Перенос Ядра в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.
Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:
В файле инвентаря 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.
Процесс переноса Ядра 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:
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:
sudo k0s kubectl delete daemonset/ingress -n ingress
sudo k0s kubectl get jobs -n kuma
sudo k0s kubectl delete job core-transfer -n kuma
sudo systemctl start kuma-mongodb
sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Другие хосты при этом могут быть остановлены.
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 Ядра для компонентов при этом не изменится.
На хосте с Ядром установщик выполняет следующие действия:
После проверки корректности переноса Ядра в кластер данные директории можно удалить.
В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса 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-core.service - данные будут обновляться с заданным для макета интервалом.
sudo systemctl reset-failed
После выполнения команды старый сервис перестанет отображаться, а новый сервис успешно запустится.
Если вы хотите обновить KUMA в распределенной установке до последней версии KUMA в отказоустойчивой конфигурации, выполните обновление в распределенной установке до последней версии, а затем выполните перенос Ядра KUMA в кластер Kubernetes. Для дальнейшего обновления используйте файл инвентаря k0s.inventory.yml с параметром need_transfer: false, поскольку перенос Ядра KUMA в кластер Kubernetes уже выполнен и больше не требуется.
Чтобы перенести Ядро KUMA в новый кластер Kubernetes, выполните следующие шаги:
В файле инвентаря 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.
Процесс переноса Ядра 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:
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:
sudo k0s kubectl delete daemonset/ingress -n ingress
sudo k0s kubectl get jobs -n kuma
sudo k0s kubectl delete job core-transfer -n kuma
sudo systemctl start kuma-mongodb
sudo systemctl start kuma-core-00000000-0000-0000-0000-000000000000
sudo systemctl status kuma-core-00000000-0000-0000-0000-000000000000
Другие хосты при этом могут быть остановлены.
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 Ядра для компонентов при этом не изменится.
На хосте с Ядром установщик выполняет следующие действия:
После проверки корректности переноса Ядра в кластер данные директории можно удалить.
В случае возникновения проблем с переносом нужно проанализировать в журнале записи задачи переноса core-transfer в пространстве имен kuma на кластере (задача доступна в течение 1 часа после переноса).
При необходимости повторного переноса необходимо привести названия директорий /opt/kaspersky/kuma/*.moved к их исходному виду.
Если на хосте с Ядром использовался файл /etc/hosts со строками, не относящимися к адресам 127.X.X.X, при переносе Ядра в кластер Kubernetes содержимое файла /etc/hosts с хоста с Ядром заносится в ConfigMap coredns. Если переноса Ядра не происходит, в ConfigMap заносится содержимое /etc/hosts с хоста, на котором разворачивается главный контроллер.