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

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

Конфигурация кластера Kubernetes задается в файле инвентаря. Она должна включать один контроллер (выделенный или совмещенный с рабочим узлом), как минимум один рабочий узел (выделенный или совмещенный с контроллером), 0 и более выделенных рабочих узлов.

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-<номер сборки>.tar.gz.

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

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

Об отказоустойчивости KUMA

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

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

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

Подробнее о требованиях к узлам кластера.

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

В тех случаях, когда KUMA установлена для демонстрации, допускается использование узлов, которые совмещают роли контроллера и рабочего узла. Однако при расширении установки до распределенной необходимо переустановить кластер Kubernetes целиком, выделив 3 отдельных узла с ролью контроллера и, как минимум, 2 узла с ролью рабочего узла. Обновление 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 пропадает. Если утеряны все реплики, будет потеряна информация.

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

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

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

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

  Также для адресов этих блоков исключен трафик на прокси-серверы.

• Установлен и настроен балансировщик нагрузки nginx (подробнее о настройке nginx). Для установки можно воспользоваться, например,следующей командой:

  sudo yum install nginx

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

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

  # 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;     } }

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

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

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

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

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

• Установка 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

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

• iscsi-initiator-utils
• wireguard-tools

Перед установкой пакетов необходимо добавить репозиторий EPEL в качестве источника: sudo yum install oracle-epel-release-el8

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

sudo yum install iscsi-initiator-utils wireguard-tools

Управление 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).