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

Вы можете обеспечить отказоустойчивость 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 в отказоустойчивом варианте, должны выполняться следующие требования:

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

• На сервере балансировщика добавлен ключ доступа с устройства, с которого осуществляется установка 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 - для 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

   airgap: true

   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

   airgap: true

   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, airgap: true, 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

   airgap: true

   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 или при новой установке программы. В файле инвентаря k0s.inventory.yml необходимо указать параметры deploy_to_k8s: true, need_transfer:true, airgap: 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.

3. Запустите установщик, находясь в папке с распакованным установщиком:

   sudo ./install.sh k0s.inventory.yml

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

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

Компоненты KUMA будут установлены. На экране будет отображен URL веб-интерфейса KUMA и указано имя пользователя и пароль, которые необходимо использовать для доступа к веб-интерфейсу.

По умолчанию адрес веб-интерфейса KUMA – https://<FQDN или IP-адрес компонента core>:7220.

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

Мы рекомендуем сохранить файл инвентаря, который вы использовали для установки программы. С его помощью вы можете дополнить систему компонентами или удалить 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 или при новой установке программы. В файле инвентаря необходимо присвоить параметрам deploy_to_k8s, need_transfer и airgap значение true. Параметру deploy_example_services необходимо присвоить значение false.

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

2. Выполните шаги распределенной установки с использованием подготовленного файла инвентаря k0s.inventory.yml.

Процесс переноса Ядра KUMA в новый кластер Kubernetes

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

Доступность Ядра 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 на корпоративный сертификат:

1. Подключитесь к главному контроллеру кластера по ssh:

   ssh <имя пользователя>@<FQDN главного контроллера>

2. Перейдите в домашний каталог пользователя или создайте новый каталог для дальнейших операций и перейдите в него.
3. Скопируйте действующие сертификат и ключ в качестве резервной копии в текущий каталог на контроллере кластера следующими командами:

   export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")

   sudo k0s kubectl cp --no-preserve -c core kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.cert ./external.cert.old

   sudo k0s kubectl cp --no-preserve -c core kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.key ./external.key.old

4. Подготовьте пользовательские сертификат и ключ для замены.

   В OpenSSL конвертируйте файл PFX в сертификат и зашифрованный ключ в формате PEM:

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

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

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

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

5. Поместите полученные файлы сертификата external.cert и ключа external.key в текущий каталог на контроллере кластера и, затем, скопируйте их в файловую систему пода ядра KUMA следующими командами:

   export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")

   sudo k0s kubectl cp --no-preserve ./external.cert kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.cert -c core

   sudo k0s kubectl cp --no-preserve ./external.key kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.key -c core

6. Перезапустите ядро KUMA следующей командой:

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

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

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

Отмена внесенных изменений

Чтобы отменить внесенные изменения и вернуться к использованию прежнего сертификата и ключа:

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

   sudo export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}")

   sudo k0s kubectl cp --no-preserve ./external.cert.old kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.cert -c core

   sudo k0s kubectl cp --no-preserve ./external.key.old kuma/$POD:/opt/kaspersky/kuma/core/certificates/external.key -c core

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

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

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

Изменения отменены, используется прежний сертификат и ключ веб-консоли.