Установка и удаление KUMA

Развернуть всё | Свернуть всё

Для выполнения установки вам понадобится дистрибутив:

• kuma-ansible-installer-<номер сборки>.tar.gz содержит все необходимые файлы для установки KUMA без поддержки отказоустойчивых конфигураций.
• kuma-ansible-installer-ha-<номер сборки>.tar.gz содержит все необходимые файлы для установки KUMA в отказоустойчивой конфигурации.

Для установки вам понадобится файл установщика install.sh и файл инвентаря с описанием инфраструктуры. Файл инвентаря вы сможете создать на основе шаблона. Каждый дистрибутив содержит файл установщика install.sh и следующие шаблоны файла инвентаря:

• single.inventory.yml.template
• distributed.inventory.yml.template
• expand.inventory.yml.template
• k0s.inventory.yml.template

KUMA размещает свои файлы в папке /opt, поэтому мы рекомендуем сделать /opt отдельным разделом и выделить под него все дисковое пространство, за исключением 16 ГБ для операционной системы.

Установка KUMA выполняется одинаково на всех хостах при помощи установщика и подготовленного вами файла инвентаря, в котором описана конфигурация. Мы рекомендуем заранее продумать схему установки.

Доступны следующие варианты установки:

• Установка на одном сервере

  Схема установки на одном сервере

  

  Установка на одном сервере

  Пример файла инвентаря для схемы установки на одном сервере

  all:

  vars:

  deploy_to_k8s: false

  need_transfer: false

  generate_etc_hosts: false

  deploy_example_services: true

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma1.example.com:

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma1.example.com

  kuma_correlator:

  hosts:

  kuma1.example.com

  kuma_storage:

  hosts:

  kuma1.example.com:

  shard: 1

  replica: 1

  keeper: 1

  Вы можете установить все компоненты KUMA на одном сервере: в файле инвентаря single.inventory.yml для всех компонентов следует указывать один сервер. Установка "все в одном" может обеспечить обработку небольшого потока событий - до 10000 EPS. Если вы планируете использовать много макетов панели мониторинга и обрабатывать большой объем поисковых запросов, одного сервера может не хватить. Мы рекомендуем выбрать распределенную установку.

• Распределенная установка

  Схема распределенной установки

  

  Схема распределенной установки

  Пример файла инвентаря для схемы распределенной установки

  all:

  vars:

  deploy_to_k8s: false

  need_transfer: false

  generate_etc_hosts: false

  deploy_example_services: false

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma-core-1.example.com:

  ip: 0.0.0.0

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma-collector-1.example.com:

  ip: 0.0.0.0

  kuma_correlator:

  hosts:

  kuma-correlator-1.example.com:

  ip: 0.0.0.0

  kuma_storage:

  hosts:

  kuma-storage-cluster1-server1.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server2.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server3.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server4.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server5.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 1

  kuma-storage-cluster1-server6.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 2

  kuma-storage-cluster1-server7.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 3

  Вы можете установить сервисы KUMA на разных серверах: конфигурацию для распределенной установки вы можете описать в файле инвентаря distributed.inventory.yml.

• Распределенная установка в отказоустойчивой конфигурации

  Схема распределенной установки в отказоустойчивой конфигурации

  

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

  Пример файла инвентаря для схемы распределенной установки в отказоустойчивой конфигурации

  all:

  vars:

  deploy_to_k8s: true

  need_transfer: true

  generate_etc_hosts: false

  airgap: true

  deploy_example_services: false

  no_firewall_actions: false

  kuma:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_core:

  hosts:

  kuma-core-1.example.com:

  mongo_log_archives_number: 14

  mongo_log_frequency_rotation: daily

  mongo_log_file_size: 1G

  kuma_collector:

  hosts:

  kuma-collector-1.example.com:

  ip: 0.0.0.0

  kuma-collector-2.example.com:

  ip: 0.0.0.0

  kuma_correlator:

  hosts:

  kuma-correlator-1.example.com:

  ip: 0.0.0.0

  kuma-correlator-2.example.com:

  ip: 0.0.0.0

  kuma_storage:

  hosts:

  kuma-storage-cluster1-server1.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server2.example.com:

  ip: 0.0.0.0

  shard: 1

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server3.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 1

  keeper: 0

  kuma-storage-cluster1-server4.example.com:

  ip: 0.0.0.0

  shard: 2

  replica: 2

  keeper: 0

  kuma-storage-cluster1-server5.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 1

  kuma-storage-cluster1-server6.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 2

  kuma-storage-cluster1-server7.example.com:

  ip: 0.0.0.0

  shard: 0

  replica: 0

  keeper: 3

  kuma_k0s:

  vars:

  ansible_connection: ssh

  ansible_user: root

  children:

  kuma_lb:

  hosts:

  kuma_lb.example.com:

  kuma_managed_lb: true

  kuma_control_plane_master:

  hosts:

  kuma_cpm.example.com:

  ansible_host: 10.0.1.10

  kuma_control_plane_master_worker:

  kuma_control_plane:

  hosts:

  kuma_cp1.example.com:

  ansible_host: 10.0.1.11

  kuma_cp2.example.com:

  ansible_host: 10.0.1.12

  kuma_control_plane_worker:

  kuma_worker:

  hosts:

  kuma-core-1.example.com:

  ansible_host: 10.0.1.13

  extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

  kuma_worker2.example.com:

  ansible_host: 10.0.1.14

  extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

  Вы можете установить Ядро KUMA в кластере Kubernetes для обеспечения отказоустойчивости. Используйте файл инвентаря k0s.inventory.yml для описания конфигурации.

Требования к установке программы

Общие требования к установке программы

Вы можете установить программу на следующих операционных системах:

• Oracle Linux.
• Astra Linux.
• Ubuntu 22.04 LTS.
• РЕД ОС 7.3.4 или 8.

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

  Операционная система РЕД ОС 8 поддерживается без высокой доступности (англ. High Availability, HA). При использовании операционной системы РЕД ОС 8 в конфигурации Сервер с поддержкой графического интерфейса вам нужно установить пакет iscsi-initiator-utils, после чего выполнить следующие команды:

  systemctl enable iscsid

  systemctl start iscsid

Перед развертыванием программы убедитесь, что выполнены следующие условия:

• Серверы, предназначенные для установки компонентов, соответствуют аппаратным и программным требованиям.
• Порты, которые KUMA займет при установке, доступны.
• Адресация компонентов KUMA осуществляется по полному доменному имени FQDN хоста в формате hostname.example.com. Перед установкой программы убедитесь, что в поле Static hostname возвращается правильное имя FQDN хоста. Для этого выполните команду:

  hostnamectl status

• Имя сервера, на котором запускается установщик, отличается от localhost или localhost.<домен>.
• Имя сервера, котором будет установлено Ядро KUMA, не начинается с цифры.
• Настроена синхронизация времени на всех серверах с сервисами KUMA по протоколу Network Time Protocol (NTP).

Требования к установке на операционных системах Oracle Linux, Astra Linux, Ubuntu 22.04 LTS и РЕД ОС 7.3.4 и 8

Обновление с операционной системы Oracle Linux 8.x до Oracle Linux 9.x

Чтобы выполнить обновление с Oracle Linux 8.x до Oracle Linux 9.x:

1. Отключите сервисы KUMA на хостах, где сервисы установлены, с помощью следующих команд:
   • sudo systemctl disable kuma-collector-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-correlator-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-storage-<идентификатор сервиса>.service
   • sudo systemctl disable kuma-grafana.service
   • sudo systemctl disable kuma-mongodb.service
   • sudo systemctl disable kuma-victoria-metrics.service
   • sudo systemctl disable kuma-vmalert.service
   • sudo systemctl disable kuma-core.service
2. Выполните обновление ОС на каждом хосте.
3. После обновления установите пакет compat-openssl11 на хосте, где будет разворачиваться Ядро KUMA вне кластера, с помощью следующей команды:

   yum install compat-openssl11

4. Включите сервисы на хостах, где сервисы установлены, с помощью следующих команд:
   • sudo systemctl enable kuma-core.service
   • sudo systemctl enable kuma-storage-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-collector-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-correlator-<идентификатор сервиса>.service
   • sudo systemctl enable kuma-grafana.service
   • sudo systemctl enable kuma-mongodb.service
   • sudo systemctl enable kuma-victoria-metrics.service
   • sudo systemctl enable kuma-vmalert.service
5. Перезагрузите хосты.

В результате обновление выполнено.

Порты, используемые KUMA при установке

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

Перед установкой Ядра на устройстве убедитесь, что следующие порты свободны:

• 9090: используется Victoria Metrics.
• 8880: используется VMalert.
• 27017: используется MongoDB.

В таблице ниже показаны значения сетевых портов по умолчанию. Порты открываются установщиком автоматически при установке KUMA

Сетевые порты, используемые для взаимодействия компонентов KUMA

Порты, используемые предустановленными ресурсами из состава OOTB

Порты открываются установщиком автоматически при установке KUMA.

Порты, используемые предустановленными ресурсами из состава OOTB:

• 7230/tcp
• 7231/tcp
• 7232/tcp
• 7233/tcp
• 7234/tcp
• 7235/tcp
• 5140/tcp
• 5140/udp
• 5141/tcp
• 5144/udp

Трафик Ядра KUMA в отказоустойчивой конфигурации

В таблице "Трафик Ядра KUMA в отказоустойчивой конфигурации" указаны инициатор соединения (источник) и назначение. Номер порта на инициаторе может быть динамическим. Обратный трафик в рамках установленного соединения не должен блокироваться.

Трафик Ядра KUMA в отказоустойчивой конфигурации

Перевыпуск внутренних CA-сертификатов

Изменено место хранения самоподписанного CA-сертификата и механизм перевыпуска сертификата.
Сертификат хранится в СУБД. Недопустимо применять прежний метод перевыпуска внутренних сертификатов через удаление сертификатов из файловой системы Ядра и перезапуск Ядра. Такой способ приведет к невозможности запустить Ядро. До завершения процесса перевыпуска сертификатов не следует подключать к Ядру новые сервисы.
После того как вы перевыпустите внутренние CA-сертификаты в разделе веб-интерфейса KUMA Параметры → Общие → Перевыпустить внутренние CA-сертификаты, необходимо остановить сервисы, удалить прежние сертификаты из директорий сервисов и вручную перезапустить все сервисы. Перевыпускать внутренние CA-сертификаты могут только пользователи с ролью Главный администратор.

Опция Перевыпустить внутренние CA-сертификаты доступна только пользователю с ролью Главный администратор.

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

Чтобы перевыпустить внутренние CA-сертификаты:

1. В веб-интерфейсе KUMA перейдите в раздел Параметры → Общие, нажмите кнопку Перевыпустить внутренние CA-сертификаты и ознакомьтесь с отобразившимся предупреждением. Если вы принимаете решение продолжить перевыпуск сертификатов, нажмите Да.

   В результате будут перевыпущены CA-сертификаты для сервисов KUMA и CA-сертификат для ClickHouse. Далее вам нужно будет остановить сервисы, удалить прежние сертификаты из директорий установки сервисов, перезапустить Ядро и перезапустить остановленные сервисы, чтобы применить перевыпущенные сертификаты.

2. Подключитесь к хостам, где развернуты сервисы коллектора, коррелятора и маршрутизатора событий.
   1. Остановите все сервисы с помощью следующей команды:

      sudo systemctl stop kuma-<collector/correlator/eventRouter>-<ID сервиса>.service

   2. Удалите файлы сертификатов internal.cert и internal.key из директорий /opt/kaspersky/kuma/<тип сервиса>/<ID сервиса>/certificates с помощью следующей команды:

      sudo rm -f /opt/kaspersky/kuma/<тип сервиса>/<ID сервиса>/certificates/internal.cert

      sudo rm -f /opt/kaspersky/kuma/<тип сервиса>/<ID сервиса>/certificates/internal.key

3. Подключитесь к хостам, где развернуты сервисы хранилища.
   1. Остановите все сервисы хранилища.

      sudo systemctl stop kuma-<storage>-<ID сервиса>.service

   2. Удалите файлы сертификатов internal.cert и internal.key из директорий /opt/kaspersky/kuma/storage/<ID сервиса>/certificates.

      sudo rm -f /opt/kaspersky/kuma/storage/<ID сервиса>/certificates/internal.cert

      sudo rm -f /opt/kaspersky/kuma/storage/<ID сервиса>/certificates/internal.key

4. Удалите все сертификаты ClickHouse из директории /opt/kaspersky/kuma/clickhouse/certificates.

   sudo rm -f /opt/kaspersky/kuma/clickhouse/certificates/internal.cert

   sudo rm -f /opt/kaspersky/kuma/clickhouse/certificates/internal.key

5. Подключитесь к хостам, где развернуты сервисы агентов.
   1. Остановите сервисы агентов Windows и агентов Linux.
   2. Удалите файлы сертификатов internal.cert и internal.key из рабочих директорий агентов.
6. Запустите Ядро, чтобы применить новые CA-сертификаты.
   • Для установки "all-in-one" и распределенной установки KUMA выполните команду:

     sudo systemctl restart kuma-core-00000000-0000-0000-0000-000000000000.service

   • Для KUMA в отказоустойчивой конфигурации, чтобы перезапустить Ядро, на основном контоллере выполните следующую команду:

     sudo k0s kubectl rollout restart deployment/core-deployment -n kuma

     Перезапуск victoria-metrics при этом не потребуется.

     Следует выполнять перезапуск Ядра с использованием команды, поскольку перезапуск Ядра через интерфейс KUMA влияет на перезапуск только контейнера Ядра, а не весь под целиком.

7. Перезапустите все сервисы, остановленные в ходе выполнения инструкции.

   sudo systemctl start kuma-<collector/correlator/eventRouter/storage>-<ID сервиса>.service

8. Перезапустите victoria-metrics.

   sudo systemctl start kuma-victoria-metrics.service

Внутренние CA-сертификаты перевыпущены и применены.

Изменение самоподписанного сертификата веб-консоли

Вы можете использовать сертификат и ключ своей компании вместо самоподписанного сертификата веб-консоли. Например, если вы хотите заменить сертификат веб-консоли с самоподписанного CA Core на сертификат, выпущенный корпоративным CA, необходимо предоставить external.cert и незашифрованный external.key в формате PEM.

В следующем примере показано, как заменить самоподписанный CA Core с помощью корпоративного сертификата в формате PFX. Вы можете использовать инструкцию в качестве примера и адаптировать шаги в соответствии со своими потребностями.

Чтобы заменить сертификат веб-консоли KUMA на сертификат external:

1. Если вы используете сертификат и ключ в PFX контейнере, в OpenSSL конвертируйте файл PFX в сертификат и зашифрованный ключ в формате PEM:

   openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nokeys -out external.cert

   openssl pkcs12 -in kumaWebIssuedByCorporateCA.pfx -nocerts -nodes -out external.key

   При выполнении команды потребуется указать пароль от ключа PFX (Enter Import Password).

   В результате получен сертификат external.cert и ключ external.key в формате PEM.

2. В веб-интерфейсе KUMA перейдите в раздел Параметры → Общие → Параметры Ядра. В блоке параметров Внешняя TLS-пара нажмите Загрузить сертификат и Загрузить ключ и загрузите external.cert и незашифрованный external.key в формате PEM.
3. Перезапустите KUMA:

   systemctl restart kuma-core

4. Обновите страницу или перезапустите браузер, с помощью которого вы работаете в веб-интерфейсе KUMA.

Сертификат и ключ вашей компании заменены.

Синхронизация времени на серверах

Чтобы настроить синхронизацию времени на серверах:

1. Установите chrony с помощью следующей команды:

   sudo apt install chrony

2. Настройте синхронизацию системного времени с NTP-сервером:
   1. Убедитесь, что виртуальная машина имеет доступ в интернет.

      Если доступ есть, вы можете перейти к шагу b.

      Если доступ отсутствует, отредактируйте файл /etc/chrony.conf, заменив значение 2.pool.ntp.org на имя или IP-адрес внутреннего NTP-сервера вашей организации.

   2. Запустите сервис синхронизации системного времени, выполнив следующую команду:

      sudo systemctl enable --now chronyd

   3. Через несколько секунд выполните следующую команду:

      sudo timedatectl | grep 'System clock synchronized'

      Если системное время синхронизировано верно, вывод будет содержать строку System clock synchronized: yes.

Синхронизация настроена.

О файле инвентаря

Установка, обновление и удаление компонентов KUMA производится из папки с распакованным установщиком kuma-ansible-installer с помощью инструмента Ansible и созданного вами файла инвентаря. Вы можете указать значения параметров конфигурации KUMA в файле инвентаря, а установщик использует эти значения при развертывании, обновлении и удалении программы. Файл инвентаря имеет формат YAML.

Вы можете создать файл инвентаря на основе шаблонов, включенных в поставку. Доступны следующие шаблоны:

• single.inventory.yml.template – используется для установки KUMA на одном сервере. Содержит минимальный набор параметров, оптимизированный для установки на одном устройстве, без использования кластера Kubernetes.
• distributed.inventory.yml.template – используется для первоначальной распределенной установки KUMA без использования кластера Kubernetes, расширения установки "все в одном" до распределенной и для обновления KUMA.
• expand.inventory.yml.template – используется в ряде сценариев изменения конфигурации: для добавления серверов коллекторов и серверов корреляторов, для расширения существующего кластера хранения и добавления нового кластера хранения. Если вы используете этот файл инвентаря для изменения конфигурации, установщик не останавливает сервисы во всей инфраструктуре. Установщик может останавливать только те сервисы, которые размещены на хостах, перечисленных в файле инвентаря expand.inventory.yml, если вы повторно используете файл инвентаря.
• k0s.inventory.yml.template – используется для установки или переноса KUMA в кластер Kubernetes.

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

Параметры конфигурации KUMA в файле инвентаря

Файл инвентаря может содержать следующие блоки:

• all
• kuma
• kuma_k0s

Для каждого хоста вам нужно указать FQDN в формате <имя хоста>.<домен> и при необходимости IPv4-адрес или IPv6-адрес. Имя домена Ядра KUMA и его поддомены не должны начинаться с цифры.

Блок all

В этом блоке вы можете указать переменные, которые распространяются на все хосты, указанные в файле инвентаря, включая неявно заданный localhost, на котором запущена установка. Переменные можно переопределять на уровне групп хостов или отдельных хостов.

Пример переопределения переменных в файле инвентаря

В таблице ниже приведен список возможных переменных в разделе vars и их описание.

Список возможных переменных в разделе vars

Блок kuma

В этом блоке вы можете указать параметры компонентов KUMA, развернутых вне кластера Kubernetes. Блок kuma может содержать следующие разделы:

• vars – переменные, которые распространяются на все хосты, указанные в блоке kuma.
• children – группы параметров компонентов:
  • kuma_core – параметры Ядра KUMA. Вы можете указать только один хост и следующие параметры ротации журнала базы данных MongoDB для хоста:
    • mongo_log_archives_number – количество предыдущих журналов, которые сохраняются при ротации журнала базы данных MongoDB.
    • mongo_log_file_size – размер журнала базы данных MongoDB в гигабайтах, при котором начинается ротация. Если журнал базы данных MongoDB не превышает указанный размер, ротации не происходит.
    • mongo_log_frequency_rotation – интервал проверки размера журнала базы данных MongoDB для ротации. Возможные значения:
      • hourly – размер журнала базы данных MongoDB проверяется каждый час.
      • daily – размер журнала базы данных MongoDB проверяется каждый день.
      • weekly – размер журнала базы данных MongoDB проверяется каждую неделю.

    Журнал базы данных MongoDB содержится в директории /opt/kaspersky/kuma/mongodb/log.

    • raft_node_addr – FQDN, на котором raft будет слушать сигналы от других узлов. Значение параметра следует указывать в следующем формате: <FQDN хоста>:<порт>. Если значение параметра не указано явно, то в качестве <FQDN хоста> по умолчанию принимается FQDN, где разворачивается Ядро KUMA, а <порт> - 7209. Вы можете указать произвольный адрес, чтобы адаптировать Ядро KUMA под специфику своей инфраструктуры.
  • kuma_collector – параметры коллекторов KUMA. Вы можете указать несколько хостов.
  • kuma_correlator – параметры корреляторов KUMA. Вы можете указать несколько хостов.
  • kuma_storage – параметры узлов хранилища KUMA. Вы можете указать несколько хостов, а также идентификаторы шарда, реплики и кипера для хостов с помощью следующих параметров:
    • shard – идентификатор шарда.
    • replica – идентификатор реплики.
    • keeper – идентификатор кипера.

    Указанные идентификаторы шарда, реплики и кипера используются, только если вы разворачиваете демо-сервисы при новой установке KUMA. В остальных случаях используются идентификаторы шарда, реплики и кипера, которые вы указали в веб-интерфейсе KUMA при создании набора ресурсов для хранилища.

Блок kuma_k0s

В этом блоке вы можете указать параметры кластера Kubernetes, использование которого обеспечивает отказоустойчивость KUMA. Этот блок указан только в файле инвентаря, основанном на шаблоне файла инвентаря k0s.inventory.yml.template.

Для тестовой и демонстрационной установки в окружениях с ограниченными вычислительными ресурсами вам нужно указать переменную low_resources: true в блоке all. В этом случае минимальный объем директории для установки ядра KUMA будет снижен до 4 ГБ и ограничения для других вычислительных ресурсов не будут указаны.

Для каждого хоста в блоке kuma_k0s должен быть указан уникальный FQDN и IP-адрес с помощью переменной ansible_host, кроме хоста в разделе kuma_lb. Для хоста в разделе kuma_lb должен быть указан только FQDN. Хосты в группах не должны повторяться.

Для демонстрационной установки допустимо совместить контроллер с рабочим узлом. Такая конфигурация не обеспечивает отказоустойчивости Ядра KUMA и служит для демонстрации возможностей или проверки программной среды.
Минимальная конфигурация для обеспечения отказоустойчивости составляет 3 контроллера, 2 рабочих узла и 1 балансировщик нагрузки nginx. Для промышленной эксплуатации рекомендуется использовать отдельные рабочие узлы и контроллеры. Если контроллер кластера находится под рабочей нагрузкой и под (англ. pod) с Ядром KUMA размещается на контроллере, выключение контроллера приведет к полной потере доступа к Ядру KUMA.

Блок kuma_k0s может содержать следующие разделы:

• vars – переменные, которые распространяются на все хосты, указанные в блоке kuma.
• сhildren – параметры кластера Kubernetes, использование которого обеспечивает отказоустойчивость KUMA.

В таблице ниже приведен список возможных переменных в разделе vars и их описание.

Список возможных переменных в разделе vars

Установка на одном сервере

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

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке KUMA.
2. Подготовьте файл инвентаря single.inventory.yml.

   Используйте шаблон файла инвентаря single.yml.template, который входит в поставку, чтобы создать файл инвентаря single.inventory.yml и описать в нем сетевую структуру компонентов программы. С помощью single.inventory.yml установщик развернет KUMA.

3. Установите программу.

   Установите программу и выполните вход в веб-интерфейс, используя учетные данные по умолчанию.

При необходимости вы можете разнести компоненты программы на разные серверы, чтобы продолжить работу в распределенной конфигурации.

Подготовка файла инвентаря single.inventory.yml

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

Чтобы создать файл инвентаря для установки на одном сервере:

1. Скопируйте архив с установщиком kuma-ansible-installer-<номер версии>.tar.gz на сервер и распакуйте его с помощью следующей команды (потребуется около 2 ГБ дискового пространства):

   sudo tar -xpf kuma-ansible-installer-<номер версии>.tar.gz

2. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer

3. Скопируйте шаблон single.inventory.yml.template и создайте файл инвентаря с именем single.inventory.yml:

   cp single.inventory.yml.template single.inventory.yml

4. Отредактируйте параметры файла инвентаря single.inventory.yml.

   Если вы хотите, чтобы при установке были созданы предустановленные сервисы, присвойте параметру deploy_example_services значение true.

   deploy_example_services: true

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

5. Замените в файле инвентаря все строки kuma.example.com на имя хоста, на который следует установить компоненты KUMA.

Файл инвентаря создан. С его помощью можно установить KUMA на одном сервере.

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

Пример файла инвентаря для установки на одном сервере

Установка программы на одном сервере

Вы можете установить все компоненты KUMA на одном сервере с помощью инструмента Ansible и файла инвентаря single.inventory.yml.

Чтобы установить KUMA на одном сервере:

1. Скачайте на сервер дистрибутив KUMA kuma-ansible-installer-<номер сборки>.tar.gz и распакуйте его. Архив распаковывается в папку kuma-ansibleinstaller.
2. Войдите в папку с распакованным установщиком.
3. В зависимости от типа активации лицензии, который вы планируете использовать, выберите один из вариантов:
   • Если вы планируете использовать активацию лицензии файлом, поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

     Файл ключа должен иметь название license.key.

     sudo cp <файл ключа>.key <папка установщика>/roles/kuma/files/license.key

   • Если вы планируете использовать активацию с помощью лицензионного кода, переходите к следующему пункту инструкции.

     Активация с помощью лицензионного кода доступна только для KUMA версии 3.4. Для более ранних версий KUMA используется активация лицензии файлом.

4. Запустите установку компонентов с использованием подготовленного файла инвентаря single.inventory.yml с помощью следующей команды:

   sudo ./install.sh single.inventory.yml

5. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

   В зависимости от типа активации лицензии результатом запуска установщика будет один из следующих вариантов:

   • Если вы планируете использовать активацию лицензии файлом и поместили файл с лицензионным ключом в папку <папка установщика>/roles/kuma/files/, в результате запуска установщика с инвентарем single.inventory.yml будет установлено Ядро KUMA, все заданные в файле инвентаря сервисы и OOTB-ресурсы. Если в инвентаре был задан параметр example_services=true, демонстрационные сервисы будут установлены.
   • Если вы планируете использовать активацию с помощью лицензионного кода, или планируете предоставить лицензионный файл позднее, в результате запуска установщика с инвентарем single.inventory.yml будет установлено только Ядро KUMA.

     Чтобы установить сервисы, в консоли командной строки укажите лицензионный код. Затем запустите установщик postinstall.sh с файлом инвентаря single.inventory.yml.

     sudo ./postinstall.sh single.inventory.yml

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

6. По окончании установки войдите в веб-интерфейс KUMA и в строке браузера введите адрес веб-интерфейса KUMA, а затем на странице входа введите учетные данные.

   Адрес веб-интерфейса KUMA – https://<FQDN хоста, на котором установлена KUMA>:7220.

   Учетные данные для входа по умолчанию:
   - логин – admin
   - пароль – mustB3Ch@ng3d!

   После первого входа измените пароль учетной записи admin

Все компоненты KUMA установлены и выполнен вход в веб-интерфейс.

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

Установку можно расширить до распределенной.

Распределенная установка

Распределенная установка KUMA происходит в несколько этапов:

1. Проверка соблюдения аппаратных и программных требований, а также требований к установке KUMA.
2. Подготовка контрольной машины.

   Контрольная машина используется в процессе установки программы: на ней распаковывается и запускаются файлы установщика.

3. Подготовка целевых машин.

   На целевые машины устанавливаются компоненты программы.

4. Подготовка файла инвентаря distributed.inventory.yml.

   Создайте файл инвентаря с описанием сетевой структуры компонентов программы. С помощью этого файла инвентаря установщик развернет KUMA.

5. Установка программы.

   Установите программу и выполните вход в веб-интерфейс.

6. Создание сервисов.

   Создайте клиентскую часть сервисов в веб-интерфейсе KUMA и установите серверную часть сервисов на целевых машинах.

   Сервисы KUMA следует устанавливать только после завершения установки KUMA. Мы рекомендуем устанавливать сервисы в такой последовательности: хранилище, коллекторы, корреляторы и агенты.

   При развертывании нескольких сервисов KUMA на одном хосте в процессе установки требуется указать уникальные порты для каждого сервиса с помощью параметров --api.port <порт>.

При необходимости вы можете изменить сертификат веб-консоли KUMA на сертификат своей компании.

Подготовка контрольной машины

Чтобы подготовить контрольную машину для установки KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке программы.
2. Сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин, выполнив следующую команду:

   sudo ssh-keygen -f /root/.ssh/id_rsa -N "" -C kuma-ansible-installer

   Если на контрольной машине заблокирован доступ root по SSH, сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин с помощью пользователя из группы sudo:

   Если у пользователя нет прав sudo, добавьте пользователя в группу sudo:

   usermod -aG sudo user

   ssh-keygen -f /home/<имя пользователя из группы sudo>/.ssh/id_rsa -N "" -C kuma-ansible-installer

   В результате ключ будет сгенерирован и сохранен в домашней директории пользователя. Вам следует указать полный путь к ключу в файле инвентаря в значении параметра ansible_ssh_private_key_file, чтобы ключ был доступен при установке.

3. Убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   sudo ssh-copy-id -i /root/.ssh/id_rsa root@<имя хоста контрольной машины>

   Если на контрольной машине заблокирован доступ root по SSH и вы хотите использовать ключ SSH из домашней директории пользователя из группы sudo, убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   ssh-copy-id -i /home/<имя пользователя из группы sudo>/.ssh/id_rsa <имя пользователя из группы sudo>@<имя хоста контрольной машины>

4. Скопируйте архив с установщиком kuma-ansible-installer-<version>.tar.gz на контрольную машину и распакуйте его с помощью следующей команды (потребуется около 2 ГБ дискового пространства):

   sudo tar -xpf kuma-ansible-installer-<номер версии>.tar.gz

Контрольная машина готова для установки KUMA.

Подготовка целевой машины

Чтобы подготовить целевую машину для установки компонентов KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке.
2. Установите имя хоста. Мы рекомендуем указывать FQDN. Например: kuma1.example.com.

   Не следует изменять имя хоста KUMA после установки: это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами программы.

3. Зарегистрируйте целевую машину в DNS-зоне вашей организации для преобразования имен хостов в IP-адреса.

   Если в вашей организации не используется DNS-сервер, вы можете использовать для преобразования имен файл /etc/hosts. Содержимое файлов можно автоматически создать для каждой целевой машины при установке KUMA.

4. Чтобы получить имя хоста, которое потребуется указать при установке KUMA, выполните следующую команду и запишите результат:

   hostname -f

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

Целевая машина готова для установки компонентов KUMA.

Подготовка файла инвентаря distributed.inventory.yml

Чтобы создать файл инвентаря distributed.inventory.yml:

1. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer

2. Скопируйте шаблон distributed.inventory.yml.template и создайте файл инвентаря с именем distributed.inventory.yml:

   cp distributed.inventory.yml.template distributed.inventory.yml

3. Отредактируйте параметры файла инвентаря distributed.inventory.yml.

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

Пример файла инвентаря для Распределенной схемы установки

Установка программы в распределенной конфигурации

Установка KUMA производится помощью инструмента Ansible и YML-файла инвентаря. Установка производится с контрольной машины, при этом все компоненты KUMA устанавливаются на целевых машинах.

Чтобы установить KUMA:

1. На контрольной машине войдите в папку с распакованным установщиком.

   cd kuma-ansible-installer

2. В зависимости от типа активации лицензии, который вы планируете использовать, выберите один из вариантов:
   • Если вы планируете использовать активацию лицензии файлом, поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

     Файл ключа должен иметь название license.key.

     sudo cp <файл ключа>.key <папка установщика>/roles/kuma/files/license.key

   • Если вы планируете использовать активацию с помощью лицензионного кода, переходите к следующему пункту инструкции.
3. Запустите установку компонентов с использованием подготовленного файла инвентаря distributed.inventory.yml, находясь в папке с распакованным установщиком:

   sudo ./install.sh distributed.inventory.yml

4. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

   В зависимости от типа активации лицензии результатом запуска установщика будет один из следующих вариантов:

   • Если вы планируете использовать активацию лицензии файлом и поместили файл с лицензионным ключом в папку <папка установщика>/roles/kuma/files/, в результате запуска установщика с файлом инвентаря distributed.inventory.yml будет установлено Ядро KUMA, все заданные в файле инвентаря сервисы и OOTB-ресурсы.
   • Если вы планируете использовать активацию с помощью лицензионного кода, или планируете предоставить лицензионный файл позднее, в результате запуска установщика с файлом инвентаря distributed.inventory.yml будет установлено только Ядро KUMA.

     Чтобы установить сервисы, в консоли командной строки укажите лицензионный код. Затем запустите установщик postinstall.sh с файлом инвентаря distributed.inventory.yml.

     sudo ./postinstall.sh distributed.inventory.yml

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

5. По окончании установки войдите в веб-интерфейс KUMA и в строке браузера введите адрес веб-интерфейса KUMA, а затем на странице входа введите учетные данные.

   Адрес веб-интерфейса KUMA – https://<FQDN хоста, на котором установлена KUMA>:7220.

   Учетные данные для входа по умолчанию:
   - логин – admin
   - пароль – mustB3Ch@ng3d!

   После первого входа измените пароль учетной записи admin

Все компоненты KUMA установлены и выполнен вход в веб-интерфейс.

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

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

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

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-<номер сборки>.tar.gz и подготовленный вами файл инвентаря k0s.inventory.yml, в котором вы определите конфигурацию кластера. При новой установке в отказоустойчивой конфигурации всегда импортируются ресурсы OOTB. Вы можете выполнить установку с развертыванием демонстрационных сервисов. Для этого нужно в файле инвентаря указать параметр deploy_example_services: true.

Поместить Ядро KUMA в кластер Kubernetes можно следующими способами:

• Установить KUMA в кластере Kubernetes с нуля.
• Перенести Ядро существующей установки KUMA в кластер Kubernetes.

Минимальная конфигурация

В Kubernetes существует 2 роли узлов:

• контроллеры (control-plane) – узлы с этой ролью управляют кластером, хранят метаданные и распределяют рабочую нагрузку.
• рабочие (worker) – узлы с этой ролью несут полезную рабочую нагрузку, то есть размещают процессы KUMA.

Для выполнения установки KUMA в отказоустойчивой конфигурации вам понадобится:

• 3 выделенных контроллера;
• 2 рабочих узла;
• 1 TCP балансировщик.

Не следует использовать балансировщик в качестве контрольной машины для запуска установщика KUMA.

Для эффективной работы Ядра KUMA в Kubernetes необходимо выделить 3 обособленных узла с единственной ролью контроллера. Это позволит обеспечить отказоустойчивость самого кластера Kubernetes и гарантировать, что рабочая нагрузка - процессы KUMA и другие процессы - не повлияет на задачи, связанные с управлением кластером Kubernetes. В случае использования средств виртуализации следует убедиться, что узлы размещены на разных физических серверах и эти физические серверы не выполняют роль рабочих узлов.

В случае демонстрационной установки KUMA допустимо совмещать роли контроллера и рабочего узла. Однако при расширении установки до распределенной необходимо переустановить кластер Kubernetes целиком, выделив 3 отдельных узла с ролью контроллера и как минимум 2 узла с ролью рабочего узла. Обновление KUMA до следующих версий недоступно при наличии узлов, совмещающих роли контроллера и рабочего узла.

Дополнительные требования при развертывании Ядра в Kubernetes

Если вы планируете защитить сетевую инфраструктуру KUMA с помощью программы Kaspersky Endpoint Security for Linux, вам нужно сначала установить KUMA в кластере Kubernetes и только потом разворачивать Kaspersky Endpoint Security for Linux. При обновлении или удалении KUMA вам нужно предварительно остановить Kaspersky Endpoint Security for Linux с помощью команды:

systemctl stop kesl

При установке KUMA в отказоустойчивом варианте должны выполняться следующие требования:

• Общие требования к установке программы.
• На хостах, которые планируются под узлы кластера Kubernetes, не используются IP-адреса из следующих блоков Kubernetes:
  • serviceCIDR: 10.96.0.0/12;
  • podCIDR: 10.244.0.0/16.

  Для IP-адресов из блоков исключен трафик на прокси-серверы.

• Каждый хост имеет уникальный идентификатор (/etc/machine-id).
• На хостах установлен и включен инструмент для управления межсетевым экраном firewalld или uwf для внесения правил в iptables.
• Установлен и настроен балансировщик нагрузки nginx (дополнительные сведения см. в документации балансировщика нагрузки nginx). Вы можете установить балансировщик нагрузки nginx с помощью одной из следующих команд:
  • sudo yum install nginx – для операционной системы Oracle Linux.
  • sudo apt install nginx-full – для операционной системы Astra Linux.
  • sudo apt install nginx libnginx-mod-stream – для операционной системы Ubuntu.
  • sudo yum install nginx nginx-all-modules – для операционной системы РЕД ОС.

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

  Пример автоматически созданной конфигурации nginx

  Установщик создает файл конфигурации /etc/nginx/kuma_nginx_lb.conf, пример содержимого которого приведен ниже. Разделы upstream формируются динамически и содержат IP-адреса контроллеров кластера Kubernetes (в примере – 10.0.0.2-4 в разделах upstream kubeAPI_backend, upstream konnectivity_backend, controllerJoinAPI_backend) и IP-адреса рабочих узлов (в примере 10.0.1.2-3), для которых в файле инвентаря в переменной extra_args содержится значение "kaspersky.com/kuma-ingress=true".

  В конец файла /etc/nginx/nginx.conf дописывается строка "include /etc/nginx/kuma_nginx_lb.conf;", позволяющая применить сформированный файл конфигурации. При большом количестве активных сервисов и пользователей может понадобиться увеличить лимит открытых файлов в параметрах nginx.conf.

  Пример файла конфигурации:

  # Ansible managed

  #

  # LB KUMA cluster

  #

  stream {

      server {

          listen          6443;

          proxy_pass      kubeAPI_backend;

      }

      server {

          listen          8132;

          proxy_pass      konnectivity_backend;

      }

      server {

          listen          9443;

          proxy_pass      controllerJoinAPI_backend;

      }

      server {

          listen          7209;

          proxy_pass      kuma-core-hierarchy_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7210;

          proxy_pass      kuma-core-services_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7220;

          proxy_pass      kuma-core-ui_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7222;

          proxy_pass      kuma-core-cybertrace_backend;

          proxy_timeout   86400s;

      }

      server {

          listen          7223;

          proxy_pass      kuma-core-rest_backend;

          proxy_timeout   86400s;

      }

      upstream kubeAPI_backend {

          server 10.0.0.2:6443;

          server 10.0.0.3:6443;

          server 10.0.0.4:6443;

      }

      upstream konnectivity_backend {

          server 10.0.0.2:8132;

          server 10.0.0.3:8132;

          server 10.0.0.4:8132;

      }

      upstream controllerJoinAPI_backend {

          server 10.0.0.2:9443;

          server 10.0.0.3:9443;

          server 10.0.0.4:9443;

      }

      upstream kuma-core-hierarchy_backend {

          server 10.0.1.2:7209;

          server 10.0.1.3:7209;

      }

      upstream kuma-core-services_backend {

          server 10.0.1.2:7210;

          server 10.0.1.3:7210;

      }

      upstream kuma-core-ui_backend {

          server 10.0.1.2:7220;

          server 10.0.1.3:7220;

      }

      upstream kuma-core-cybertrace_backend {

          server 10.0.1.2:7222;

          server 10.0.1.3:7222;

      }

      upstream kuma-core-rest_backend {

          server 10.0.1.2:7223;

          server 10.0.1.3:7223;

  }

   worker_rlimit_nofile 1000000;

  events {

  worker_connections 20000;

  }

  # worker_rlimit_nofile – ограничение на максимальное число открытых файлов (RLIMIT_NOFILE) для рабочих процессов. Используется для увеличения ограничения без перезапуска главного процесса.

  # worker_connections – максимальное число соединений, которые одновременно может открыть рабочий процесс.

• На сервере балансировщика нагрузки nginx добавлен ключ доступа с устройства, с которого осуществляется установка KUMA.
• На сервере балансировщика нагрузки nginx в операционной системе не включен модуль SELinux.
• На хостах установлены пакеты tar, systemctl.

При установке KUMA автоматически проверяется соответствие хостов следующим аппаратным требованиям:

• Количество ядер CPU (потоков) – 12 или больше.
• ОЗУ – 22528 МБ или больше.
• Объем свободного пространства на диске в разделе /opt/ – 1000 ГБ или больше.
• Если производится первичная установка, в /var/lib/ должно быть не менее 32GB свободного места. Если установка кластера на этот узел ранее уже проводилась, размер требуемого свободного пространства уменьшается на размер директории /var/lib/k0s.

Если условия не выполняются, установка прерывается. Проверку условий при установке для демонстрации можно выключить, указав в файле инвентаря переменную low_resources: true.

Дополнительные требования при установке на операционной системе Astra Linux или Ubuntu

• Установка KUMA в отказоустойчивом варианте поддерживается на операционной системе Astra Linux Special Edition РУСБ.10015-01 (2022-1011SE17MD, оперативное обновление 1.7.2.UU.1). Требуется версия ядра 5.15.0.33 или выше.
• На машинах, предназначенных для развертывания кластера Kubernetes, установлены следующие пакеты:
  • open-iscsi;
  • wireguard;
  • wireguard-tools.

  Вы можете установить пакеты с помощью команды:

  sudo apt install open-iscsi wireguard wireguard-tools

Дополнительные требования при установке на операционной системе Oracle Linux, РЕД ОС и на операционных системах Red Hat Enterprise Linux

На машинах, предназначенных для развертывания кластера Kubernetes, установлены следующие пакеты:

• iscsi-initiator-utils;
• wireguard-tools.

Перед установкой пакетов на операционной системе Oracle Linux вам нужно добавить репозиторий EPEL в качестве источника с помощью одной из следующих команд:

• sudo yum install oracle-epel-release-el8 - для операционной системы Oracle Linux 8.
• sudo yum install oracle-epel-release-el9 - для операционной системы Oracle Linux 9.

Вы можете установить пакеты с помощью команды:

sudo yum install iscsi-initiator-utils wireguard-tools

Установка KUMA в кластере Kubernetes с нуля

Распределенная установка KUMA происходит в несколько этапов:

1. Проверка соблюдения аппаратных и программных требований, а также требований к установке KUMA.
2. Подготовка контрольной машины.

   Контрольная машина используется в процессе установки программы: на ней распаковывается и запускаются файлы установщика.

3. Подготовка целевых машин.

   На целевые машины устанавливаются компоненты программы.

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

   Создайте файл инвентаря с описанием сетевой структуры компонентов программы. С помощью этого файла инвентаря установщик развернет KUMA.

5. Установка программы.

   Установите программу и войдите в веб-интерфейс.

6. Создание сервисов.

   Создайте клиентскую часть сервисов в веб-интерфейсе KUMA и установите серверную часть сервисов на целевых машинах.

   Сервисы KUMA следует устанавливать только после завершения установки KUMA. Мы рекомендуем устанавливать сервисы в такой последовательности: хранилище, коллекторы, корреляторы и агенты.

   При развертывании нескольких сервисов KUMA на одном хосте в процессе установки требуется указать уникальные порты для каждого сервиса с помощью параметров --api.port <порт>.

При необходимости вы можете изменить сертификат веб-консоли KUMA на сертификат своей компании.

Подготовка контрольной машины

Чтобы подготовить контрольную машину для установки KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке программы.
2. Сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин, выполнив следующую команду:

   sudo ssh-keygen -f /root/.ssh/id_rsa -N "" -C kuma-ansible-installer

   Если на контрольной машине заблокирован доступ root по SSH, сгенерируйте SSH-ключ для аутентификации на SSH-серверах целевых машин с помощью пользователя из группы sudo:

   Если у пользователя нет прав sudo, добавьте пользователя в группу sudo:

   usermod -aG sudo user

   ssh-keygen -f /home/<имя пользователя из группы sudo>/.ssh/id_rsa -N "" -C kuma-ansible-installer

   В результате ключ будет сгенерирован и сохранен в домашней директории пользователя. Вам следует указать полный путь к ключу в файле инвентаря в значении параметра ansible_ssh_private_key_file, чтобы ключ был доступен при установке.

3. Убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   sudo ssh-copy-id -i /root/.ssh/id_rsa root@<имя хоста контрольной машины>

   Если на контрольной машине заблокирован доступ root по SSH и вы хотите использовать ключ SSH из домашней директории пользователя из группы sudo, убедитесь, что контрольная машина имеет сетевой доступ ко всем целевым машинам по имени хоста и скопируйте SSH-ключ на каждую целевую машину, выполнив следующую команду:

   ssh-copy-id -i /home/<имя пользователя из группы sudo>/.ssh/id_rsa <имя пользователя из группы sudo>@<имя хоста контрольной машины>

4. Скопируйте архив с установщиком kuma-ansible-installer-ha-<номер версии>.tar.gz на контрольную машину и распакуйте его с помощью следующей команды:

   sudo tar -xpf kuma-ansible-installer-ha-<номер версии>.tar.gz

Контрольная машина готова для установки KUMA.

Подготовка целевой машины

Чтобы подготовить целевую машину для установки компонентов KUMA:

1. Убедитесь, что соблюдены аппаратные и программные требования, а также требования к установке.
2. Установите имя хоста. Мы рекомендуем указывать FQDN. Например: kuma1.example.com.

   Не следует изменять имя хоста KUMA после установки: это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами программы.

3. Зарегистрируйте целевую машину в DNS-зоне вашей организации для преобразования имен хостов в IP-адреса.

   Вариант с использованием файла /etc/hosts не применим для развертывания Ядра в Kubernetes.

4. Чтобы получить имя хоста, которое потребуется указать при установке KUMA, выполните следующую команду и запишите результат:

   hostname -f

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

Целевая машина готова для установки компонентов KUMA.

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

Развернуть всё | Свернуть всё

Чтобы создать файл инвентаря k0s.inventory.yml:

1. Перейдите в директорию установщика KUMA, выполнив следующую команду:

   cd kuma-ansible-installer-ha

2. Скопируйте шаблон k0s.inventory.yml.template и создайте файл инвентаря с именем k0s.inventory.yml:

   cp k0s.inventory.yml.template k0s.inventory.yml

3. Отредактируйте параметры файла инвентаря k0s.inventory.yml.

   Пример файла инвентаря для демонстрационной установки с Ядром в Kubernetes

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: false

   generate_etc_hosts: false

   deploy_example_services: true

   kuma:

   children:

   kuma_core:

   hosts:

   kuma.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma.example.com:

   kuma_correlator:

   hosts:

   kuma.example.com:

   kuma_storage:

   hosts:

   kuma.example.com:

   shard: 1

   replica: 1

   keeper: 1

   kuma_k0s:

   children:

   kuma_control_plane_master_worker:

   hosts:

   kuma-cpw.example.com:

   ansible_host: 10.0.2.11

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   Для демонстрационной установки следует указать deploy_example_services: true - KUMA развернет демонстрационные сервисы на указанных хостах и назначит роль шарда, реплики и кипера указанному хосту, настраивать эти роли для демонстрационной установки в веб-интерфейсе KUMA не нужно.

   Пример файла инвентаря для распределенной установки в отказоустойчивой конфигурации с 3 контроллерами, 2 рабочими узлами и 1 балансировщиком

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: false

   generate_etc_hosts: false

   deploy_example_services: false

   kuma:

   children:

   kuma_core:

   hosts:

   kuma-core.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma-collector.example.com:

   kuma_correlator:

   hosts:

   kuma-correlator.example.com:

   kuma_storage:

   hosts:

   kuma-storage-cluster1.server1.example.com

   kuma-storage-cluster1.server2.example.com

   kuma-storage-cluster1.server3.example.com

   kuma-storage-cluster1.server4.example.com

   kuma-storage-cluster1.server5.example.com

   kuma-storage-cluster1.server6.example.com

   kuma-storage-cluster1.server7.example.com

   kuma_k0s:

   children:

   kuma_lb:

   hosts:

   kuma-lb.example.com:

   kuma_managed_lb: true

   kuma_control_plane_master:

   hosts:

   kuma_cpm.example.com:

   ansible_host: 10.0.1.10

   kuma_control_plane_master_worker:

   kuma_control_plane:

   hosts:

   kuma_cp2.example.com:

   ansible_host: 10.0.1.11

   kuma_cp3.example.com:

   ansible_host: 10.0.1.12

   kuma_control_plane_worker:

   kuma_worker:

   hosts:

   kuma-w1.example.com:

   ansible_host: 10.0.2.11

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   kuma-w2.example.com:

   ansible_host: 10.0.2.12

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   Для такой конфигурации следует указать параметры need_transfer: false, deploy_example_services: false, в разделе kuma_storage перечислить серверы для кластера хранения. Роли шарда, реплики и кипера вы сможете назначить указанным в инвентаре серверам в веб-интерфейсе KUMA после завершения установки.

   Пример файла инвентаря для переноса Ядра в кластер Kubernetes из распределенной установки для обеспечения отказоустойчивости

   all:

   vars:

   ansible_connection: ssh

   ansible_user: root

   deploy_to_k8s: true

   need_transfer: true

   generate_etc_hosts: false

   deploy_example_services: false

   kuma:

   children:

   kuma_core:

   hosts:

   kuma-core.example.com:

   mongo_log_archives_number: 14

   mongo_log_frequency_rotation: daily

   mongo_log_file_size: 1G

   kuma_collector:

   hosts:

   kuma-collector.example.com:

   kuma_correlator:

   hosts:

   kuma-correlator.example.com:

   kuma_storage:

   hosts:

   kuma-storage-cluster1.server1.example.com

   kuma-storage-cluster1.server2.example.com

   kuma-storage-cluster1.server3.example.com

   kuma-storage-cluster1.server4.example.com

   kuma-storage-cluster1.server5.example.com

   kuma-storage-cluster1.server6.example.com

   kuma-storage-cluster1.server7.example.com

   kuma_k0s:

   children:

   kuma_lb:

   hosts:

   kuma-lb.example.com:

   kuma_managed_lb: true

   kuma_control_plane_master:

   hosts:

   kuma_cpm.example.com:

   ansible_host: 10.0.1.10

   kuma_control_plane_master_worker:

   kuma_control_plane:

   hosts:

   kuma_cp2.example.com:

   ansible_host: 10.0.1.11

   kuma_cp3.example.com:

   ansible_host: 10.0.1.12

   kuma_control_plane_worker:

   kuma_worker:

   hosts:

   kuma-w1.example.com:

   ansible_host: 10.0.2.11

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

   kuma-w2.example.com:

   ansible_host: 10.0.2.12

   extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"

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

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

Установка программы в отказоустойчивой конфигурации

Установка KUMA производится помощью инструмента Ansible и файла инвентаря k0s.inventory.yml. Установка производится с контрольной машины, при этом все компоненты KUMA устанавливаются на целевых машинах.

Чтобы установить KUMA:

1. На контрольной машине войдите в папку с распакованным установщиком.

   cd kuma-ansible-installer-ha

2. В зависимости от типа активации лицензии, который вы планируете использовать, выберите один из вариантов:
   • Если вы планируете использовать активацию лицензии файлом, поместите в папку <папка установщика>/roles/kuma/files/ файл с лицензионным ключом.

     Файл ключа должен иметь название license.key.

     sudo cp <файл ключа>.key <папка установщика>/roles/kuma/files/license.key

   • Если вы планируете использовать активацию с помощью лицензионного кода, переходите к следующему пункту инструкции.
3. Запустите установку компонентов с использованием подготовленного файла инвентаря distributed.inventory.yml, находясь в папке с распакованным установщиком:

   sudo ./install.sh k0s.inventory.yml

4. Примите условия Лицензионного соглашения.

   Если вы не примете условия Лицензионного соглашения, программа не будет установлена.

   В зависимости от типа активации лицензии результатом запуска установщика будет один из следующих вариантов:

   • Если вы планируете использовать активацию лицензии файлом и поместили файл с лицензионным ключом в папку <папка установщика>/roles/kuma/files/, в результате запуска установщика с файлом инвентаря k0s.inventory.yml будет установлено Ядро KUMA, все заданные в файле инвентаря сервисы и OOTB-ресурсы.
   • Если вы планируете использовать активацию с помощью лицензионного кода, или планируете предоставить лицензионный файл позднее, в результате запуска установщика с файлом инвентаря k0s.inventory.yml будет установлено только Ядро KUMA.

     Чтобы установить сервисы, в консоли командной строки укажите лицензионный код. Затем запустите установщик postinstall.sh с файлом инвентаря k0s.inventory.yml.

     sudo ./postinstall.sh k0s.inventory.yml

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

5. По окончании установки войдите в веб-интерфейс KUMA и в строке браузера введите адрес веб-интерфейса KUMA, а затем на странице входа введите учетные данные.

   Адрес веб-интерфейса KUMA – https://<FQDN балансировщика нагрузки nginx>:7220.

   Учетные данные для входа по умолчанию:
   - логин – admin
   - пароль – mustB3Ch@ng3d!

   После первого входа измените пароль учетной записи admin

Все компоненты KUMA установлены и выполнен вход в веб-интерфейс.

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

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

Доступность Ядра KUMA при различных сценариях

Доступность Ядра KUMA при различных сценариях:

• Выход из строя или отключение от сети рабочего узла, на котором развернут сервис Ядра KUMA.

  Доступ к веб-интерфейсу KUMA пропадает. Через 6 минут Kubernetes инициирует перенос контейнера с Ядром на работающий узел кластера. После завершения развертывания, которое занимает менее одной минуты, веб-интерфейс KUMA снова доступен по URL, в которых используются FQDN балансировщика. Чтобы определить, на каком из хостов работает Ядро, в терминале одного из контроллеров выполните команду:

  k0s kubectl get pod -n kuma -o wide

  Когда вышедший из строя рабочий узел или доступ к нему восстанавливается, контейнер с Ядром не переносится с текущего рабочего узла. Восстановленный узел может участвовать в репликации дискового тома сервиса Ядра.

• Выход из строя или отключение от сети рабочего узла с репликой диска Ядра KUMA, на котором в этот момент не развернут сервис Ядра.

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

• Потеря доступности одного или нескольких контроллеров кластера при сохранении кворума.

  Рабочие узлы работают в обычном режиме. Перерыва в доступе к KUMA не возникает. Выход из строя контроллеров кластера, при котором кворум не обеспечивается оставшимися в работе контроллерами, ведет к потере управления кластером.

  Соответствие количества используемых машин для обеспечения отказоустойчивости

  Количество контроллеров при установке кластера	Минимальное количество контроллеров, необходимое для работы кластера (кворум)	Возможное количество неработающих контроллеров
  1	1	0
  2	2	0
  3	2	1
  4	3	1
  5	3	2
  6	4	2
  7	4	3
  8	5	3
  9	5	4

• Одновременный выход из строя всех контроллеров кластера Kubernetes.

  Кластером невозможно управлять, из-за чего его работоспособность будет нарушена.

• Одновременная потеря доступности всех рабочих узлов кластера с репликами тома Ядра и подом Ядра.

  Доступ к веб-интерфейсу KUMA пропадает. Если утеряны все реплики, будет потеряна информация.

Управление Kubernetes и доступ к KUMA

При установке KUMA в отказоустойчивом варианте, в директории установщика создается файл artifacts/k0s-kubeconfig.yml, содержащий реквизиты, необходимые для подключения к созданному кластеру Kubernetes. Такой же файл создается на основном контроллере в домашней директории пользователя, заданного в файле инвентаря как ansible_user.

Для обеспечения возможности мониторинга и управления кластером Kubernetes файл k0s-kubeconfig.yml необходимо сохранить в месте, доступном для администраторов кластера. Доступ к файлу следует ограничить.

Управление кластером Kubernetes

Для мониторинга и управления кластером можно использовать программу k0s, устанавливаемую на все узлы кластера при развертывании KUMA. Например, для просмотра нагрузки на рабочие узлы можно использовать команду:

k0s kubectl top nodes

Доступ к Ядру KUMA

Доступ к Ядру KUMA осуществляется по URL https://<FQDN рабочего узла>:<порт рабочего узла>. Доступные порты: 7209, 7210, 7220, 7222, 7223. По умолчанию для подключения к веб-интерфейсу Ядра KUMA используется порт 7220. Доступ может осуществляться через любой рабочий узел, в параметре extra_args которого содержится значение kaspersky.com/kuma-ingress=true.

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

В случае использования внешнего балансировщика нагрузки в конфигурации кластера Kubernetes с обеспечением отказоустойчивости доступ к портам Ядра KUMA осуществляется через FQDN балансировщика.

Часовой пояс в кластере Kubernetes

Внутри кластера Kubernetes всегда используется часовой пояс UTC+0, поэтому при обращении с данными, созданными Ядром KUMA, развернутом в отказоустойчивом варианте, следует учитывать эту разницу во времени:

• В событиях аудита в поле DeviceTimeZone будет указан часовой пояс UTC+0.
• В сформированных отчетах пользователь будет видеть разницу между временем формирования отчета и временем браузера.
• В панели мониторинга пользователь будет видеть разницу между временем в виджете (отображается время браузера пользователя) и временем в выгрузке данных виджета в CSV-файле (отображается время внутри кластера Kubernetes).

Резервное копирование KUMA

KUMA позволяет выполнять резервное копирование базы данных Ядра KUMA и сертификатов. Функция резервного копирования предназначена для восстановления KUMA – для переноса или копирования ресурсов следует использовать функции экспорта и импорта ресурсов.

Резервное копирование можно выполнить с помощью REST API.

Особенности резервного копирования KUMA

• Восстановление данных из резервной копии поддерживается только при сохранении версии KUMA.
• Резервное копирование коллекторов не требуется, за исключением коллекторов с SQL-подключением. При восстановлении таких коллекторов следует вернуть к исходному начальное значение идентификатора.
• Если после восстановления KUMA не включается, рекомендуется обнулить базу данных kuma в MongoDB.

  Как обнулить базу данных в MongoDB

  Если после восстановления данных не включается Ядро KUMA, необходимо повторить восстановление, обнулив при этом базу данных kuma в MongoDB.

  Чтобы восстановить данные KUMA с обнулением базы данных MongoDB:

  1. Войдите в ОС сервера, на котором установлено Ядро KUMA.
  2. Остановите Ядро KUMA, выполнив следующую команду:

     sudo systemctl stop kuma-core

  3. Войдите в MongoDB, выполнив следующие команды:
     1. cd /opt/kaspersky/kuma/mongodb/bin/
     2. ./mongo
  4. Обнулите базу данных MongoDB, выполнив следующие команды:
     1. use kuma
     2. db.dropDatabase()
  5. Выйдите из базы данных MongoDB, нажав Ctrl+C.
  6. Восстановите данные из резервной копии, выполнив следующую команду:

     sudo /opt/kaspersky/kuma/kuma tools restore --src <путь к директории с резервной копией> --certificates

     Флаг --certificates не является обязательным и используется для восстановления сертификатов.

  7. Запустите KUMA, выполнив следую команду:

     sudo systemctl start kuma-core

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

  Данные восстановлены из резервной копии.

Изменение конфигурации KUMA

Доступны следующие изменения конфигурации KUMA.

• Расширение установки "все в одном" до распределенной.

  Чтобы расширить установку "все в одном" до распределенной:

  1. Создайте резервную копию KUMA.
  2. Удалите с сервера предустановленные сервисы коррелятора, коллектора и хранилища.
     1. В веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы выберите сервис и нажмите Копировать идентификатор. На сервере, где были установлены сервисы, выполните команду удаления сервиса:

        sudo /opt/kaspersky/kuma/kuma <collector/correlator/storage> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --uninstall

        Повторите команду удаления для каждого сервиса.

     2. Затем удалите сервисы в веб-интерфейсе KUMA.

     В результате на сервере первоначальной установки останется только Ядро KUMA.

  3. Подготовьте файл инвентаря distributed.inventory.yml и укажите в нем сервер первоначальной установки "все в одном" в группе kuma_core.

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

     Пример файла инвентаря для расширения установки "все в одном" до распределенной

     all:

     vars:

     deploy_to_k8s: false

     need_transfer: false

     generate_etc_hosts: false

     deploy_example_services: false

     no_firewall_actions: false

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_core:

     hosts:

     kuma-core-1.example.com:

     ip: 0.0.0.0

     mongo_log_archives_number: 14

     mongo_log_frequency_rotation: daily

     mongo_log_file_size: 1G

     kuma_collector:

     hosts:

     kuma-collector-1.example.com:

     ip: 0.0.0.0

     kuma_correlator:

     hosts:

     kuma-correlator-1.example.com:

     ip: 0.0.0.0

     kuma_storage:

     hosts:

     kuma-storage-cluster1-server1.example.com:

     ip: 0.0.0.0

     shard: 1

     replica: 1

     keeper: 0

     kuma-storage-cluster1-server2.example.com:

     ip: 0.0.0.0

     shard: 1

     replica: 2

     keeper: 0

     kuma-storage-cluster1-server3.example.com:

     ip: 0.0.0.0

     shard: 2

     replica: 1

     keeper: 0

     kuma-storage-cluster1-server4.example.com:

     ip: 0.0.0.0

     shard: 2

     replica: 2

     keeper: 0

     kuma-storage-cluster1-server5.example.com:

     ip: 0.0.0.0

     shard: 0

     replica: 0

     keeper: 1

     kuma-storage-cluster1-server6.example.com:

     ip: 0.0.0.0

     shard: 0

     replica: 0

     keeper: 2

     kuma-storage-cluster1-server7.example.com:

     ip: 0.0.0.0

     shard: 0

     replica: 0

     keeper: 3

  4. Создайте и установите сервисы хранилища, коллектора, коррелятора и агента на других машинах.
     1. После того, как вы заполните в файле инвентаря distributed.inventory.yml значения параметров для всех разделов, запустите установщик на контрольной машине.

        sudo ./install.sh distributed.inventory.yml

        В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря distributed.inventory.yml, появятся файлы, необходимые для установки компонентов KUMA: хранилища, коллекторов, корреляторов.

     2. Создайте сервисы хранилища, коллекторов и корреляторов.

  Расширение установки завершено.

• Добавление серверов для коллекторов в распределенную установку.

  В следующей инструкции показано, как добавить один или несколько серверов в существующую инфраструктуру, чтобы затем установить на них коллекторы и таким образом перераспределить нагрузку. Вы можете использовать инструкцию в качестве примера и адаптировать ее под свои потребности.

  Чтобы добавить серверы в распределенную установку:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

     cp expand.inventory.yml.template expand.inventory.yml

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе kuma_collector.

     Пример файла инвентаря expand.inventory.yml для добавления серверов для коллекторов

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma-additional-collector1.example.com

     kuma-additional-collector2.example.com

     kuma_correlator:

     kuma_storage:

     hosts:

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки коллектора.

  6. Создайте и установите коллекторы. Поскольку коллекторы KUMA состоят из двух частей, клиентской и серверной, вы будете создавать коллекторы в два этапа.
     1. Создание клиентской части коллектора, которая включает в себя набор ресурсов и сервис коллектора.

        Чтобы создать набор ресурсов для коллектора, в веб-интерфейсе KUMA в разделе Ресурсы → Коллекторы нажмите Добавить коллектор и настройте параметры. Подробнее см. Создание коллектора.

        На последнем шаге мастера настройки, после того, как вы нажмете Создать и сохранить, будет создан набор ресурсов для коллектора и автоматически будет создан сервис коллектора. Также будет автоматически сформирована команда для установки сервиса на сервере, она отобразится на экране. Скопируйте команду установки и переходите к следующему шагу.

     2. Создание серверной части коллектора.
     1. На целевой машине выполните скопированную на предыдущем шаге команду. Команда будет выглядеть подобным образом, но все параметры будут автоматически заполнены.

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис коллектора установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     2. Повторите выполнение команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml.
  7. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление серверов завершено.

• Добавление серверов для корреляторов в распределенную установку.

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

  Чтобы добавить серверы в распределенную установку:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

     cp expand.inventory.yml.template expand.inventory.yml

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе kuma_correlator.

     Пример файла инвентаря expand.inventory.yml для добавления серверов для корреляторов

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma_correlator:

     kuma-additional-correlator1.example.com

     kuma-additional-correlator2.example.com

     kuma_storage:

     hosts:

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки коррелятора.

  6. Создайте и установите корреляторы. Поскольку корреляторы KUMA состоят из двух частей, клиентской и серверной, вы будете создавать корреляторы в два этапа.
     1. Создание клиентской части коррелятора, которая включает в себя набор ресурсов и сервис коллектора.

        Чтобы создать набор ресурсов для коррелятора, в веб-интерфейсе KUMA в разделе Ресурсы → Корреляторы нажмите Добавить коррелятор и настройте параметры. Подробнее см. Создание коррелятора.

        На последнем шаге мастера настройки, после того, как вы нажмете Создать и сохранить, будет создан набор ресурсов для коррелятора и автоматически будет создан сервис коррелятора. Также будет автоматически сформирована команда для установки сервиса на сервере — команда отобразится на экране. Скопируйте команду установки и переходите к следующему шагу.

     2. Создание серверной части коррелятора.
     1. На целевой машине выполните скопированную на предыдущем шаге команду. Команда будет выглядеть подобным образом, но все значения всех параметров будут автоматически присвоены.

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис коррелятора установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     2. Повторите выполнение команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml.
  7. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление серверов завершено.

• Добавление серверов в существующий кластер хранения.

  В следующей инструкции показано, как добавить несколько серверов в существующий кластер хранения. Вы можете использовать инструкцию в качестве примера и адаптировать ее под свои потребности.

  Чтобы добавить серверы в существующий кластер хранения:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

     cp expand.inventory.yml.template expand.inventory.yml

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе storage. В следующем примере в разделе storage указаны серверы для установки двух шардов, каждый из которых будет содержать по две реплики. В файле инвентаря expand.inventory.yml следует указать только FQDN, роли шардов и реплик вы будете назначать позднее в веб-интерфейсе KUMA, последовательно выполняя шаги инструкции. Вы можете адаптировать этот пример под свои потребности.

     Пример файла инвентаря expand.inventory.yml для добавления серверов в существующий кластер хранения

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma_correlator:

     kuma_storage:

     hosts:

     kuma-storage-cluster1-server8.example.com

     kuma-storage-cluster1-server9.example.com

     kuma-storage-cluster1-server10.example.com

     kuma-storage-cluster1-server11.example.com

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки хранилища.

  6. Поскольку вы добавляете серверы в существующий кластер хранения, создавать отдельное хранилище не требуется. Измените параметры хранилища существующего кластера:
     1. В разделе Ресурсы → Хранилища выберите существующее хранилище и откройте его для редактирования.
     2. В разделе Узлы кластера ClickHouse нажмите Добавить узлы и в появившихся полях для нового узла укажите роли. В следующем примере показано, как указать идентификаторы, чтобы добавить в существующий кластер два шарда, каждый из которых содержит две реплики. Вы можете адаптировать пример под свои потребности.

        Пример:

        Узлы кластера ClickHouse

        <существующие узлы>

        Полное доменное имя: kuma-storage-cluster1server8.example.com

        Идентификатор шарда: 1

        Идентификатор реплики: 1

        Идентификатор кипера: 0

        Полное доменное имя: kuma-storage-cluster1server9.example.com

        Идентификатор шарда: 1

        Идентификатор реплики: 2

        Идентификатор кипера: 0

        Полное доменное имя: kuma-storage-cluster1server9.example.com

        Идентификатор шарда: 2

        Идентификатор реплики: 1

        Идентификатор кипера: 0

        Полное доменное имя: kuma-storage-cluster1server10.example.com

        Идентификатор шарда: 2

        Идентификатор реплики: 2

        Идентификатор кипера: 0

     3. Сохраните параметры хранилища.

        Теперь можно создать сервисы хранилища для каждого узла кластера ClickHouse.

  7. Чтобы создать сервис хранилища, в веб веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить сервис.

     В открывшемся окне Выберите сервис выберите измененное на предыдущем шаге хранилище и нажмите Создать сервис. Повторите для каждого добавляемого узла хранилища ClickHouse.

     В результате количество созданных сервисов должно равняться количеству добавляемых узлов в кластере ClickHouse, то есть четыре узла - четыре сервиса. Созданные сервисы хранилища отображаются в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы.

  8. Теперь сервисы хранилища необходимо установить на каждом сервере, используя идентификатор сервиса.
     1. В веб-интерфейсе KUMA Ресурсы → Активные сервисы выберите нужный сервис хранилища и нажмите Копировать идентификатор.

        Идентификатор сервиса будет скопирован в буфер обмена, он понадобится для выполнения команды установки сервиса.

     2. Сформируйте и выполните на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис хранилища установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     3. Последовательно выполните команду установки сервиса хранилища на каждой целевой машине, указанной в разделе storage в файле инвентаря expand.inventory.yml. На каждой машине в команде установки следует указывать уникальный идентификатор сервиса в рамках кластера.
  9. Чтобы применить изменения в работающем кластере, в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы установите флажок рядом со всеми сервисами хранилища в кластере, который вы расширяете, и нажмите Обновить параметры. Изменения будут применены без остановки сервисов.
  10. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление серверов в кластер хранения завершено.

• Добавление дополнительного кластера хранения.

  В следующей инструкции показано, как добавить дополнительный кластер хранения в существующую инфраструктуру. Вы можете использовать инструкцию в качестве примера и адаптировать ее под свои потребности.

  Чтобы добавить дополнительный кластер хранения:

  1. Убедитесь, что на целевых машинах соблюдены аппаратные и программные требования, а также требования к установке.
  2. На контрольной машине перейдите в директорию с распакованным установщиком KUMA, выполнив следующую команду:

     cd kuma-ansible-installer

  3. Скопируйте шаблон expand.inventory.yml.template и создайте файл инвентаря с именем expand.inventory.yml:

     cp expand.inventory.yml.template expand.inventory.yml

  4. Отредактируйте параметры файла инвентаря expand.inventory.yml и укажите в нем серверы, которые вы хотите добавить, в разделе storage. В следующем примере в разделе storage указаны серверы для установки трех выделенных киперов и двух шардов, каждый из которых будет содержать по две реплики. В файле инвентаря expand.inventory.yml следует указать только FQDN, роли киперов, шардов и реплик вы будете назначать позднее в веб-интерфейсе KUMA, последовательно выполняя шаги инструкции. Вы можете адаптировать этот пример под свои потребности.

     Пример файла инвентаря expand.inventory.yml для добавления дополнительного кластера хранения

     kuma:

     vars:

     ansible_connection: ssh

     ansible_user: root

     children:

     kuma_collector:

     kuma_correlator:

     kuma_storage:

     hosts:

     kuma-storage-cluster2-server1.example.com

     kuma-storage-cluster2-server2.example.com

     kuma-storage-cluster2-server3.example.com

     kuma-storage-cluster2-server4.example.com

     kuma-storage-cluster2-server5.example.com

     kuma-storage-cluster2-server6.example.com

     kuma-storage-cluster2-server7.example.com

  5. На контрольной машине с доступом root из папки с распакованным установщиком выполните следующую команду:

     ./expand.sh expand.inventory.yml

     В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки хранилища.

  6. Создайте и установите хранилище. Для каждого кластера хранения следует создавать отдельное хранилище, то есть три кластера хранения - три хранилища. Поскольку хранилище состоит из двух частей, клиентской и серверной, вы будете создавать хранилище в два этапа.
     1. Создание клиентской части хранилища, которая включает в себя набор ресурсов и сервис хранилища.
        1. Чтобы создать набор ресурсов для хранилища, в веб-интерфейсе KUMA в разделе Ресурсы → Хранилища нажмите Добавить хранилище и настройте параметры. В разделе Узлы кластера ClickHouse укажите роли для каждого добавляемого сервера: кипер, шард, реплика. Подробнее см. Создание набора ресурсов для хранилища.

           Созданный набор ресурсов для хранилища отображается в разделе Ресурсы → Хранилища. Теперь можно создать сервисы хранилища для каждого узла кластера ClickHouse.

        2. Чтобы создать сервис хранилища, в веб веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы нажмите Добавить сервис.

           В открывшемся окне Выберите сервис выберите созданный на шаге a. набор ресурсов для хранилища и нажмите Создать сервис. Повторите для каждого узла хранилища ClickHouse.

           В результате количество созданных сервисов должно равняться количеству узлов в кластере ClickHouse, то есть пятьдесят узлов - пятьдесят сервисов. Созданные сервисы хранилища отображаются в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы. Теперь сервисы хранилища необходимо установить на каждом узле кластера ClickHouse, используя идентификатор сервиса.

     2. Создание серверной части хранилища.
     1. На целевой машине создайте серверную часть хранилища: в веб-интерфейсе KUMA Ресурсы → Активные сервисы выберите нужный сервис хранилища и нажмите Копировать идентификатор.

        Идентификатор сервиса будет скопирован в буфер обмена, он понадобится для выполнения команды установки сервиса.

     2. Сформируйте и выполните на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый Ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --install

        Сервис хранилища установлен на целевой машине. Вы можете проверить статус сервиса в веб-интерфейсе в разделе Ресурсы → Активные сервисы.

     3. Последовательно выполните команду установки сервиса хранилища на каждой целевой машине, указанной в разделе storage в файле инвентаря expand.inventory.yml. На каждой машине в команде установки следует указывать уникальный идентификатор сервиса в рамках кластера.
     4. Выделенные киперы запускаются автоматически сразу после установки и отображаются в разделе Ресурсы → Активные сервисы в зеленом статусе. Сервисы на остальных узлах хранилища могут не запускаться до тех пор, пока не будут установлены сервисы для всех узлов данного кластера. До этого момента сервисы могут отображаться в красном статусе. Это нормальное поведение для создания нового кластера хранения или добавления узлов в существующий кластер хранения. Как только будет выполнена команда установки сервисов на всех узлах кластера, все сервисы переходят в зеленый статус.
  7. Укажите добавленные серверы в файле инвентаря distributed.inventory.yml, чтобы в нем были актуальные сведения на случай обновления KUMA.

  Добавление дополнительного кластера хранения завершено.

• Удаление серверов из распределенной установки.

  Чтобы удалить сервер из распределенной установки:

  1. Удалите все сервисы с сервера, который вы планируете удалить из распределенной установки.
     1. Удалите серверную часть сервиса. Скопируйте в веб-интерфейсе KUMA идентификатор сервиса и запустите на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <collector/correlator/storage> --core https://<FQDN сервера Ядра KUMA>:<порт, используемый ядром KUMA для внутренних коммуникаций (по умолчанию используется порт 7210)> --id <идентификатор сервиса, скопированный из веб-интерфейса KUMA> --uninstall

     2. Удалите клиентскую часть сервиса в веб-интерфейсе KUMA в разделе Активные сервисы – Удалить.

        Сервис удален.

  2. Повторите шаг 1 для каждого сервера, который вы хотите удалить из инфраструктуры.
  3. Удалите серверы из соответствующих разделов файла инвентаря distributed.inventory.yml, чтобы в файле инвентаря были актуальные сведения на случай обновления KUMA.

  Серверы удалены из распределенной установки.

• Удаление кластера хранения из распределенной установки.

  Чтобы удалить один или несколько кластеров хранения из распределенной установки:

  1. Удалите сервис хранилища на каждом сервере кластера, подлежащем удалению из распределенной установки.
     1. Удалите серверную часть сервиса хранилища. Скопируйте в веб-интерфейсе KUMA идентификатор сервиса и запустите на целевой машине следующую команду:

        sudo /opt/kaspersky/kuma/kuma <storage> --id <идентификатор сервиса> --uninstall

        Повторите для каждого сервера.

     2. Удалите клиентскую часть сервиса в веб-интерфейсе KUMA в разделе Ресурсы → Активные сервисы → Удалить.

        Сервис удален.

  2. Удалите серверы из раздела storage в файле инвентаря distributed.inventory.yml, чтобы в файле инвентаря были актуальные сведения на случай обновления KUMA или изменения конфигурации.

  Кластер удален из распределенной установки.

• Перенос Ядра 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 с хоста, на котором разворачивается главный контроллер.

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

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

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

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

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

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

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

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

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

Устранение ошибок при обновлении

При обновлении KUMA вы можете столкнуться со следующими ошибками:

• Ошибка по таймауту

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

  Выполните следующие шаги, чтобы устранить ошибку по таймауту и успешно завершить обновление:

  1. Откройте отдельный второй терминал и запустите следующую команду, чтобы убедиться, что вывод команды содержит строку с сообщением об ошибке таймауту:

     journalctl -u kuma-core | grep 'start operation timed out' 

     Сообщение об ошибке по таймауту:

     kuma-core.service: start operation timed out. Terminating.

  2. После того, как вы нашли сообщение об ошибке по таймауту, в файле сервиса /usr/lib/systemd/system/kuma-core.service измените значение параметра TimeoutSec с 300 на 0, чтобы снять ограничения по времени ожидания и временно исключить возможность повторного появления ошибки.
  3. После изменения файла сервиса последовательно выполните следующие команды:

     systemctl daemon-reload

     service kuma-core restart

  4. После выполнения команд и успешного запуска сервиса во втором терминале еще раз введите пароль администратора в исходном первом терминале, где установщик запрашивает пароль.

     KUMA продолжит установку. В условиях предельных ресурсов установка может занять до часа.

  5. После успешного завершения установки верните параметр TimeoutSec к значению 300 в файле /usr/lib/systemd/system/kuma-core.service.
  6. После изменения файла сервиса выполните следующие команды во втором терминале:

     systemctl daemon-reload

     service kuma-core restart

  После выполнения команд обновление будет успешно выполнено.

• Неверный пароль администратора

  Пароль к пользователю admin нужен для автоматического заполнения параметров хранилища при обновлении. Если при выполнении задачи TASK [Prompt for admin password] вы указали неверный пароль к пользователю admin девять раз, установщик все равно выполнит обновление и веб-интерфейс будет доступен, но настройки хранилища не мигрируют и хранилища будут в красном статусе.

  Чтобы устранить ошибку и сделать хранилища вновь доступными для работы, обновите настройки хранилища:

  1. Перейдите в настройки хранилища, вручную заполните поля кластера ClickHouse и нажмите Сохранить.
  2. Перезапустите сервис хранилища.

  Сервис хранилища будет запущен с заданными параметрами и будет в зеленом статусе.

• Ошибка DB::Exception

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

  Пример ошибки:

  DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, int, bool) @ 0xda0553a in /opt/kaspersky/kuma/clickhouse/bin/clickhouse

  Чтобы перезапустить ClickHouse, выполните следующую команду на сервере хранилища KUMA:

  touch /opt/kaspersky/kuma/clickhouse/data/flags/force_restore_data && systemctl restart kuma-storage-<идентификатор хранилища, в котором обнаружена ошибка>

• Истечение срока действия сертификатов кластера k0s

  Симптомы

  Невозможно подключение контроллеров или рабочих узлов, перенос подов с одного рабочего узла на другой.

  В журналах сервисов k0scontroller и k0sworker появляются множественные записи со следующей подстрокой:

  x509: certificate has expired or is not yet valid

  Причина

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

  Способ исправления

  Чтобы исправить ошибку, поочередно перезапустите сервисы k0scontroller с правами root на каждом контроллере кластера - сертификаты будут перевыпущены:

  systemctl restart k0scontroller

  Чтобы проверить сроки действия сертификатов на контроллерах, выполните следующие команды с правами root:

  find /var/lib/k0s/pki/ -type f -name "*.crt" -print|egrep -v 'ca.crt$'|xargs -L 1 -t -i bash -c 'openssl x509 -noout -text -in {}|grep After'

  find /var/lib/k0s/pki/etcd -type f -name "*.crt" -print|egrep -v 'ca.crt$'|xargs -L 1 -t -i bash -c 'openssl x509 -noout -text -in {}|grep After'

  Команды выведут названия файлов сертификатов и сроки их действия.

Устраните ошибки, чтобы успешно завершить обновление.

Удаление KUMA

При удалении KUMA используется инструмент Ansible и созданный пользователем файл инвентаря.

Чтобы удалить KUMA:

1. На контрольной машине войдите в директорию установщика:

   cd kuma-ansible-installer

2. Выполните следующую команду:

   sudo ./uninstall.sh <файл инвентаря>

KUMA и все данные программы удалены с серверов.

Базы данных, которые использовались KUMA (например, база данных хранилища ClickHouse), и содержащуюся в них информацию следует удалить отдельно.

Особенности удаления KUMA, установленной в отказоустойчивом варианте

Состав удаляемых компонентов зависит от значения параметра deploy_to_k8s в файле инвентаря, используемого для удаления KUMA:

• true – удаляется созданный при установке KUMA кластер Kubernetes.
• false – из кластера Kubernetes удаляются все компоненты KUMA, кроме Ядра. Сам кластер не удаляется.

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

• /usr/bin/k0s
• /etc/k0s/
• /var/lib/k0s/
• /usr/libexec/k0s/
• ~/k0s/ (для пользователя ansible_user)
• /opt/longhorn/
• /opt/cni/
• /opt/containerd

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

• Для задач Delete KUMA transfer job и Delete KUMA pod такие сообщения можно игнорировать.
• Для задач Reset k0s (при сообщении об ошибке, содержащем текст "To ensure a full reset, a node reboot is recommended.") и Delete k0s Directories and files (при сообщении об ошибке, содержащем текст "Ошибка ввода/вывода: '/var/lib/k0s/kubelet/plugins/kubernetes.io/csi/driver.longhorn.io/") рекомендуется перезагрузить хост, к которому относится ошибка и выполнить повторное удаление KUMA с тем же файлом инвентаря.

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