# Установка KUMA с отказоустойчивым ядром - Kubernetes Отказоустойчивость KUMA обеспечивается путем внедрения ядра KUMA в кластер Kubernetes, развернутый установщиком KUMA. В качестве распределённого блочного хранилища для кластера используется Longhorn. Схема: ![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2025-01/scaled-1680-/IWFimage.png)
Схема работы в случае отказа оного из воркеров ядра ![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2025-01/scaled-1680-/5jsimage.png) Через ~ 5 минут ![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2025-01/scaled-1680-/oSiimage.png) Через ~ 1-2 минуты [![image.png](https://kb.kuma-community.ru/uploads/images/gallery/2025-01/scaled-1680-/gxDimage.png)](https://kb.kuma-community.ru/uploads/images/gallery/2025-01/gxDimage.png)
Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-**ha**-2.1. X.tar.gz. Конфигурация кластера Kubernetes задается в файле инвентаря `k0s.inventory.yml`. Требования к устройствам для установки KUMA в Kubernetes - [https://support.kaspersky.com/help/KUMA/3.0.2/ru-RU/217889.htm](https://support.kaspersky.com/help/KUMA/3.0.2/ru-RU/217889.htm)
Порты доступа для кластера ядра
Трафик KUMA core в отказоустойчивой конфигурации (трафик, в котором и источником и получателем выступают внешние сервисы KUMA здесь не рассматривается)
В таблице указаны инициатор соединения (источник) и назначение. Номер порта на инициаторе может быть динамическим. Обратный трафик в рамках установленного соединения не должен блокироваться
ИсточникНазначениеПорт назначенияТип
Внешние сервисы KUMAБалансировщик нагрузки7209tcp
Внешние сервисы KUMAБалансировщик нагрузки7210tcp
Внешние сервисы KUMAБалансировщик нагрузки7220tcp
Внешние сервисы KUMAБалансировщик нагрузки7222tcp
Внешние сервисы KUMAБалансировщик нагрузки7223tcp
Рабочий узелБалансировщик нагрузки6443tcp
Рабочий узелБалансировщик нагрузки8132tcp
Управляющий узелБалансировщик нагрузки6443tcp
Управляющий узелБалансировщик нагрузки8132tcp
Управляющий узелБалансировщик нагрузки9443tcp
Рабочий узелВнешние сервисы KUMAв зависимости от настроек при создании сервисаtcp
Балансировщик нагрузкиРабочий узел7209tcp
Балансировщик нагрузкиРабочий узел7210tcp
Балансировщик нагрузкиРабочий узел7220tcp
Балансировщик нагрузкиРабочий узел7222tcp
Балансировщик нагрузкиРабочий узел7223tcp
Внешние сервисы KUMAРабочий узел7209tcp
Внешние сервисы KUMAРабочий узел7210tcp
Внешние сервисы KUMAРабочий узел7220tcp
Внешние сервисы KUMAРабочий узел7222tcp
Внешние сервисы KUMAРабочий узел7223tcp
Рабочий узелРабочий узел179tcp
Рабочий узелРабочий узел9500tcp
Рабочий узелРабочий узел10250tcp
Рабочий узелРабочий узел51820udp
Рабочий узелРабочий узел51821udp
Управляющий узелРабочий узел10250tcp
Балансировщик нагрузкиУправляющий узел6443tcp
Балансировщик нагрузкиУправляющий узел8132tcp
Балансировщик нагрузкиУправляющий узел9443tcp
Рабочий узелУправляющий узел6443tcp
Рабочий узелУправляющий узел8132tcp
Рабочий узелУправляющий узел10250tcp
Управляющий узелУправляющий узел2380tcp
Управляющий узелУправляющий узел6443tcp
Управляющий узелУправляющий узел9443tcp
Управляющий узелУправляющий узел10250tcp
Консоль управления кластером (CLI)Балансировщик нагрузки6443tcp
Консоль управления кластером (CLI)Управляющий узел6443tcp
Минимально кластер должен включать: - один контроллер (выделенный или совмещенный с рабочим узлом); - один рабочий узел (выделенный, или совмещенный с контроллером); - 0 и более выделенных рабочих узлов.

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

Для реализации отказоустойчивости необходим выделенный контроллер кластера и минимум 2 рабочих узла. Если контроллер кластера содержит рабочую нагрузку и под (pod) с Core размещается на нем, то его отключение приведет к полной потере доступа к Core.

На всех компонентах ядра должно быть единое время, настройте на всех машинах NTP

На контроллерах кластера должен быть уникальный machine-id, это значит, что не рекомендуется клонирование машин с этой ролью, либо необходимо изменить ID на машинах до установки. **Внимание!** Допустимость данной операции должен определять администратор хоста с учётом возможного использования machine-id другими сервисами! `rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen --ensure=/etc/machine-id && dbus-uuidgen --ensure && reboot`

1. В нашем случае мы будем использовать установку All-In-One хост kuma-1.local, один узел контроллера (хост kuma-2.local) и два рабочих узла (хост kuma-3.local и kuma-4.local), пример файла инвентаря: [https://box.kaspersky.com/f/bf06497b5b004dc3b1e5/](https://box.kaspersky.com/f/bf06497b5b004dc3b1e5/) Другие примеры инвентарей: [https://box.kaspersky.com/d/b397490dc08048acb671/](https://box.kaspersky.com/d/b397490dc08048acb671/) 2.

При установке с нуля kuma\_core игнорируется, его заполнение нужно только для переноса ранее установленной коры без HA в кластер Kubernetes Т.е. kuma\_core должен быть равен одному из kuma\_worker, если у нас уже есть кума и мы тащим ее в кубер.

3. В распределенной установке kuma в секции инвентаря kuma\_core нужно указать хост, который есть в роли worker (один из двух) 4. ВАЖНО! Для успешной установки должны быть соблюдены следующие требования: - все машины кластера должны быть добавлены в `/etc/hosts`; - установлены пакеты в соответствии с: [https://support.kaspersky.com/help/KUMA/3.2/ru-RU/244399.htm](https://support.kaspersky.com/help/KUMA/2.1/ru-RU/244399.htm); - На Astra Linux на машине балансировщика нужно установить в дополнение пакету nginx еще один пакет **libnginx-mod-stream** - в `/var/lib/` должно быть не менее 32GB свободного места; 5. Значение переменных в инвентаре ansible: - `low_resources` – использовать минимальные ресурсы для разворачивания? Отсутсвует по умолчанию. (Достаточно ресурсов: 2 CPU 4 RAM, **НО при этом создается том хранения 4 Гб**, без этого параметра том создается 512 Гб) - для части инвентаря kuma\_k0s и переменных ansible\_host важно указывать IP адреса - `kuma_managed_lb: false` - если используется собственный (балансировщик организации, не KUMA) балансировщик, при этом указать FQDN этого балансировщика (для корректного формирования сертификата коры) - `no_firewall_actions: false` - инсталлятор будет пытаться открыть необходимые порты на МЭ данного хоста - Остальные значения переменных: [https://support.kaspersky.ru/help/KUMA/3.4/ru-RU/244406.htm](https://support.kaspersky.ru/help/KUMA/3.4/ru-RU/244406.htm) 6. Создайте резервную копию ресурсов и сертификатов, [см. советующий раздел в этой инструкции](https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/rezervnoe-kopirovanie-i-vosstanovlenie-kuma). 7. Распакуйте архив (операции выполняются на ядре системы KUMA): `tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz` 8. Перейдите в распакованную папку: `cd kuma-ansible-installer` 9. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key: `cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key` 10. Выполните команду копирования шаблона (пример заполненного файла в п. 0): `cp k0s.inventory.yml.template k0s.inventory.yml ` 11. ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды `hostname -f` 12. ВАЖНО! Хостнейм при команде `hostname -f` должен содержать хотя бы одну точку, пример: kuma.local 13. Входим в ОС из-под суперпользователя (root), если это не было сделано ранее: `sudo -i` 14. Запустите установку: `./install.sh k0s.inventory.yml` 15. Зайдите на веб интерфейс ядра KUMA по одному из адресов рабочих узлов или балансировщика, например, в нашем случае это - [https://192.168.0.153:7220](https://192.168.0.153:7220) Учетные данные для входа по умолчанию: `admin / mustB3Ch@ng3d!` 16. Для начального администрирования кластера воспользуйтесь командами [**этого раздела**](https://kb.kuma-community.ru/books/kuma-how-to/page/pervicnyi-trablsut-v-kuma-troubleshoot#bkmrk-%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B-%D1%8F%D0%B4).

В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить uninstall.sh и перезагрузить все узлы кластера. Если uninstall выполнить нельзя (идет миграция существующей установки в кластер), то перед повторной попыткой установки нужно вручную выполнить команду **sudo k0s reset** (если долгий reset, то **rm -rf /var/lib/k0s/containerd**, затем **k0s reset -d**) на всех узлах кластера и перезагрузить их

Перестроение между воркерами в кластере Kubernetes происходит с таймаутом ~ 5 мин

Отказоустойчивость балансировщиков, см. [**тут**](https://kb.kuma-community.ru/link/41#bkmrk-%C2%A0-3)

Для работы с кластером можно использовать команды и инструменты [**отсюда**](https://kb.kuma-community.ru/link/55#bkmrk-%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B-%D1%8F%D0%B4)

Видео установки в конфигурации AiO-1LB-1CP-2W [**тут**](https://box.kaspersky.com/f/92f75a82224746dfa0f1/)