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

Вы можете обеспечить отказоустойчивость 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).