Содержание

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

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

Установка, обновление и удаление компонентов 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 и его поддомены не должны начинаться с цифры.

Пример:

hosts:

hostname.example.com:

ip: 0.0.0.0

Блок all

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

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

all:

vars:

ansible_connection: ssh

deploy_to_k8s: False

need_transfer: False

airgap: True

deploy_example_services: True

kuma:

vars:

ansible_become: true

ansible_user: i.ivanov

ansible_become_method: su

ansible_ssh_private_key_file: ~/.ssh/id_rsa

children:

kuma_core:

vars:

ansible_user: p.petrov

ansible_become_method: sudo

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

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

Переменная	Описание
`ansible_connection`	Способ подключения к целевым машинам. Возможные значения: `ssh` – подключение к удаленным хостам по SSH. `local` – подключение к удаленным хостам не производится.
`ansible_user`	Имя пользователя, от которого производится подключение к целевым машинам и установка компонентов. Если пользователь root на целевых машинах заблокирован, вам нужно использовать имя пользователя, имеющего право на подключение по SSH и повышение привилегий через su или sudo.
`ansible_become`	Переменная, определяющая, требуется ли повышать привилегии пользователя, от имени которого осуществляется установка компонентов KUMA. Возможные значения: `true` – вам нужно указать это значение, если для переменной `ansible_user` вы не указали значение `root`. `false`.
`ansible_become_method`	Способ повышения привилегий пользователя, от имени которого осуществляется установка компонентов KUMA. Вам нужно указать значение `su` или `sudo`, если для переменной `ansible_user` вы не указали значение `root`.
`ansible_ssh_private_key_file`	Путь к закрытому ключу в формате /<путь>/.ssh/id_rsa. Вам нужно указать эту переменную, если вы хотите указать файл ключа, отличный от файла ключа по умолчанию ~/.ssh/id_rsa.
`deploy_to_k8s`	Переменная, определяющая, требуется ли разворачивать компоненты KUMA в кластере Kubernetes. Возможные значения: `false` – это значение указано в шаблонах файла инвентаря single.inventory.yml и distributed.inventory.yml. `true` – это значение указано в шаблоне файла инвентаря k0s.inventory.yml. Если вы не укажете эту переменную, по умолчанию будет использовано значение `false`.
`need_transfer`	Переменная, определяющая, требуется ли переносить Ядро KUMA в новый кластер Kubernetes. Вам нужно указать эту переменную, только если для переменной `deploy_to_k8s` вы указали значение `true`. Возможные значения: `false` – KUMA требуется установить или обновить в кластере Kubernetes с нуля. `true` – Ядро KUMA требуется перенести в новый кластер Kubernetes. Если вы не укажете эту переменную, по умолчанию будет использовано значение `false`.
`no_firewall_actions`	Переменная, определяющая, выполняет ли установщик шаги по настройке межсетевого экрана на хостах. Возможные значения: `true` – при запуске установщик не выполняет шаги по настройке межсетевого экрана на хостах. `false` – при запуске установщик выполняет шаги по настройке межсетевого экрана на хостах. Это значение указано во всех шаблонах файла инвентаря. Если вы не укажете эту переменную, по умолчанию будет использовано значение `false`.
`generate_etc_hosts`	Переменная, определяющая, регистрируются ли машины в DNS-зоне вашей организации. Установщик автоматически дополнит файлы /etc/hosts на машинах, на которые устанавливаются компоненты KUMA, IP-адресами машин из файла инвентаря. Указанные IP-адреса должны быть уникальными. Возможные значения: `false`. `true`. Если вы не укажете эту переменную, по умолчанию будет использовано значение `false`.
`deploy_example_services`	Переменная, определяющая, создаются ли предустановленные сервисы при установке KUMA. Вам нужно указать эту переменную, если вы хотите создать демо-сервисы независимо от файла инвентаря single/distributed/k0s. Возможные значения: `false` – предустановленные сервисы не создаются при установке KUMA. Это значение указано во всех шаблонах файла инвентаря. `true` – предустановленные сервисы создаются при установке KUMA. Если вы не укажете эту переменную, по умолчанию будет использовано значение `false`.
`low_resources`	Переменная, определяющая, устанавливается ли KUMA в окружениях с ограниченными вычислительными ресурсами. Эта переменная отсутствует во всех шаблонах файла инвентаря. Возможные значения: `false` – KUMA устанавливается для промышленной эксплуатации. В этом случае установщик проверяет требования рабочих узлов (процессор, ОЗУ и свободное дисковое пространство) в соответствии с аппаратными и программными требованиями. Если требования не выполняются, установка прерывается с сообщением об ошибке. `true` – KUMA устанавливается в окружениях с ограниченными вычислительными ресурсами. В этом случае минимальный объем директории для установки Ядра KUMA на хосте составляет 4 ГБ. Ограничения для других вычислительных ресурсов отсутствуют. Если вы не укажете эту переменную, по умолчанию будет использовано значение `false`.

Блок 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_lb`	FQDN балансировщика нагрузки. Вы можете установить балансировщик нагрузки nginx или сторонний TCP-балансировщик нагрузки. Если вы устанавливаете балансировщик нагрузки nginx, вы можете указать параметр `kuma_managed_lb = true`, чтобы автоматически настроить балансировщик нагрузки nginx при установке KUMA, открыть на хосте балансировщика нагрузки nginx необходимые сетевые порты (6443, 8132, 9443, 7209, 7210, 7220, 7222, 7223, 7226, 8429), а также выполнить перезагрузку для применения изменений. Если вы устанавливаете сторонний TCP-балансировщик нагрузки, вам нужно вручную настроить его до установки KUMA.
`kuma_control_plane_master`	Хост, выполняющий роль главного контроллера в кластере.	Группы для указания главного контроллера. Вам нужно указать хост только для одной группы.
`kuma_control_plane_master_worker`	Хост, совмещающий роль главного контроллера и рабочего узла в кластере.Для каждого контроллера кластера, совмещенного с рабочим узлом, в файле инвентаря должен быть указан параметр `extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"`.
`kuma_control_plane`	Хосты, выполняющие роль контроллера в кластере.	Группы для указания второстепенных контроллеров.
`kuma_control_plane_worker`	Хосты, совмещающие роль контроллера и рабочего узла в кластере. Для каждого контроллера кластера, совмещенного с рабочим узлом, в файле инвентаря должен быть указан параметр `extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"`.	Группы для указания второстепенных контроллеров.
`kuma_worker`	Рабочие узлы кластера. Для каждого рабочего узла в файле инвентаря должен быть указан параметр `extra_args: "--labels=kaspersky.com/kuma-core=true,kaspersky.com/kuma-ingress=true,node.longhorn.io/create-default-disk=true"`.

В начало