Установка KeyStack LCM в режиме высокой доступности

Данная инструкция описывает установку LCM (Lifecycle Manager) в режиме высокой доступности. В этом режиме LCM развёртывается на трёх Control-узлах, образующих Kubernetes-кластер на базе k0s. Такая архитектура обеспечивает отказоустойчивость самой системы управления жизненным циклом платформы.

Описание базовой установки LCM на одном узле приведено в разделе Установка KeyStack LCM.

Настройка компонента VMHA для обеспечения отказоустойчивости виртуальных машин описана в разделе VMHA — Высокая доступность ВМ.

Примечание

На текущий момент поддерживаются два варианта инсталлятора:

  • Новый инсталлятор k0s (описан в данной инструкции) — рекомендуется для новых установок

  • Классический инсталлятор — поддерживается для обеспечения совместимости с существующими установками

Оба варианта будут поддерживаться в переходный период. Выбор инсталлятора зависит от требований вашей инфраструктуры и планов миграции.

Требования к инфраструктуре

Аппаратные требования для HA LCM

Для развёртывания LCM в режиме высокой доступности предъявляются специальные требования к LCM-узлам:

  • Количество узлов: ровно 3 (для обеспечения кворума)

  • Оперативная память: минимум 32 ГБ на узел

  • Процессор: минимум 16 ядер x86-64/AMD64 на узел

  • Дисковая подсистема:

    • Системные диски: 2×500 ГБ SSD в конфигурации RAID 1 для операционной системы и системных компонентов

    • Диск для Ceph: минимум 1×500 ГБ SSD без RAID для распределённого хранилища Ceph

    Предупреждение

    Важно использовать отдельные физические диски для системы и Ceph. Размещение системы и Ceph на одном диске существенно снижает производительность и надёжность кластера.

  • Сетевые интерфейсы: 2×10 ГБ NIC для обеспечения резервирования сетевых подключений

Аппаратные требования для остальных узлов

Требования к остальным типам узлов платформы:

Требование / Тип узла

Controller

Compute

Network

Storage

Обязательность

Да

Да

Да

Нет

Минимальное количество узлов

3

2

1

—

Оперативная память

256 ГБ

—

—

—

Процессор (ядер)

2×8

2×12

2×8

—

Архитектура процессора

x86-64 / AMD64

x86-64 / AMD64

x86-64 / AMD64

—

Место для хранения

2×512 ГБ SSD (RAID 1)

—

—

—

Сетевая карта

2×10 ГБ NIC

2×10 ГБ NIC

2× (2×10 ГБ NIC)

—

Программные требования

На всех узлах должна быть установлена ОС SberLinux. Требуется наличие непривилегированного пользователя с правами sudo для выполнения команд от имени root.

Примечание

Установщик автоматически применяет необходимые настройки ядра ОС и устанавливает требуемые системные пакеты в процессе развёртывания. Все необходимые оптимизации и зависимости включены в дистрибутив и применяются на этапе выполнения installer.sh.

Сетевые требования

Для работы LCM требуется настроенная DNS-зона со следующими записями:

  • gitlab.<доменная зона> — для управления жизненным циклом платформы (CI),

  • nexus.<доменная зона> — для хранения артефактов платформы,

  • vault.<доменная зона> — для хранения паролей и сертификатов,

  • netbox.<доменная зона> — для настроек Baremetal-узлов,

  • minio.<доменная зона> — для работы GitLab,

  • docker.<доменная зона> — для хранения контейнеров,

  • grafana.<доменная зона> — для мониторинга платформы,

  • k0s.<доменная зона> — для API Kubernetes.

Также для всех Baremetal-узлов инфраструктуры требуется создать DNS-записи вида <IP-адрес> <имя узла>-rmi.<доменная зона>.

Подготовительные шаги

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

Настройка узлов

  1. Создайте узлы необходимых типов согласно аппаратным и программным требованиям.

  2. Убедитесь, что на всех узлах время в BIOS настроено в зоне UTC.

  3. На LCM-узлах под управлением ОС SberLinux выполните команду:

    $ timedatectl set-local-rtc 0

  4. Убедитесь, что у непривилегированного пользователя есть права sudo на выполнение команд от root.

  5. Убедитесь, что на всех узлах включена аппаратная виртуализация:

    $ egrep '(vmx|svm)' /proc/cpuinfo

    Вывод должен содержать параметр vmx или svm. Если он отсутствует, включите аппаратную виртуализацию в настройках BIOS.

  6. Получите дистрибутив KeyStack одним из вариантов поставки.

  7. Создайте SSH-ключ и разместите его на LCM-узлы, чтобы обеспечить беспарольный вход с первого узла на другие узлы.

  8. На всех LCM-узлах отключите фаервол и SELinux.

  9. На всех LCM-узлах настройте синхронизацию времени.

  10. Убедитесь, что на свободных дисках (особенно на дисках, предназначенных для Ceph) нет никакой информации, разделов и других данных. Диски должны быть полностью очищены.

Настройка сетевой связности

  1. На LCM-узле проверьте сетевую связность:

    • Настройте доступ до IPMI всех узлов инфраструктуры, MGMT-интерфейсов и VIP-адресов.

    • Проверьте доступность DHCP-сервера в сети PXE.

    • Включите поддержку Redfish всех узлов инфраструктуры.

  2. Для всех Baremetal-узлов создайте пользователя с правами administrator.

Установка инсталлятора

Установка выполняется на первом LCM-узле.

  1. Подключитесь по SSH к первому LCM-узлу.

  2. Скачайте архив с инсталлятором и распакуйте его:

    $ curl -O https://repo.itkey.com/repository/k-install/installer-k0s-ks2025.2.2-sberlinux-offline.tgz
$ tar -xf installer-k0s-ks2025.2.2-sberlinux-offline.tgz
$ cd installer
$ tar -xf mutiple-node-k0s-ks2025.2.2.tar.gz

  3. Откройте файл конфигурации:

    $ vi mutiple-node/lcm-config.yaml

  4. Настройте параметры установки. Основные параметры:

    • ssh_username — имя непривилегированного пользователя, от которого выполняется установка.

    • fqdn_cp1, fqdn_cp2, fqdn_cp3 — DNS-имена LCM-узлов.

    • domain_name — доменная зона для региона. В этой зоне должны быть зарегистрированы все сервисы LCM.

    • mgt_vip_address — VIP-адрес управления Kubernetes (K0s).

    • ext_vip_address — VIP-адрес доступа к сервисам LCM (GitLab, NetBox, Vault, Nexus). Должен быть зарегистрирован в DNS в зоне domain_name.

    • keepalived_passwd — пароль для keepalived (максимум 8 символов).

    • ironic_enable — управление сервисом Ironic для работы с Baremetal-узлами. При первичной установке укажите "false". Ironic можно будет включить позже через настройки мониторинга после развёртывания основных компонентов.

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

    ssh_username: "cloud-user"
fqdn_cp1: "cp-1.testdomain.local"
fqdn_cp2: "cp-2.testdomain.local"
fqdn_cp3: "cp-3.testdomain.local"
domain_name: "testdomain.local"
mgt_vip_address: "172.16.130.10"
ext_vip_address: "10.120.120.240"
keepalived_passwd: "8LJw251u"
ironic_enable: "false"

    Остальные параметры (размеры томов, настройки мониторинга) можно оставить по умолчанию или настроить согласно требованиям.

    Примечание

    В файле lcm-config.yaml доступны дополнительные параметры для настройки мониторинга и сервиса Ironic:

    • Мониторинг: параметры для настройки Grafana, Prometheus и алертинга можно найти в секции мониторинга файла конфигурации. По умолчанию включён базовый мониторинг компонентов LCM.

    • Ironic: после первичной установки платформы сервис Ironic можно активировать, изменив параметр ironic_enable на "true" и выполнив обновление конфигурации. Ironic необходим для управления Baremetal-узлами через IPMI/Redfish.

  5. Сохраните и закройте файл.

  6. Запустите установку:

    $ ./installer.sh mutiple-node/lcm-config.yaml

    Скрипт установит необходимые пакеты в систему и выполнит настройку ОС. На этом этапе применяются все необходимые настройки ядра и устанавливаются системные зависимости.

Этап установки order 1

На первом этапе устанавливается Kubernetes-кластер и система хранения данных Ceph.

Для первичной установки или переустановки этапа выполните:

$ cd mutiple-node/
$ ./offline-bundle/installer.sh --order 1

Проверка успешного завершения

  1. Проверьте состояние узлов кластера. Должны отобразиться три узла в статусе Ready:

    $ kubectl get nodes
NAME                            STATUS   ROLES           AGE     VERSION
<имя>-lcm-01.vm.lab.itkey.com   Ready    control-plane   7m14s   v1.31.5+k0s
<имя>-lcm-02.vm.lab.itkey.com   Ready    control-plane   6m41s   v1.31.5+k0s
<имя>-lcm-03.vm.lab.itkey.com   Ready    control-plane   6m41s   v1.31.5+k0s

  2. Проверьте состояние OSD-дисков Ceph. Должны отобразиться три пода в статусе Running:

    $ kubectl get pod -l app.kubernetes.io/name=ceph-osd -n ceph-cluster
NAME                              READY   STATUS    RESTARTS   AGE
rook-ceph-osd-0-6cb69b89b6-2n5fc  2/2     Running   0          60s
rook-ceph-osd-1-cf7476bcf-vnlj6   2/2     Running   0          60s
rook-ceph-osd-2-54884b7c48-2s746  2/2     Running   0          59s

  3. Проверьте состояние кластера Ceph. Должен отобразиться кластер в фазе Ready со статусом здоровья HEALTH_WARN:

    $ kubectl get -n ceph-cluster cephclusters.ceph.rook.io
NAME           DATADIRHOSTPATH   MONCOUNT   AGE     PHASE   MESSAGE                      HEALTH
ceph-cluster   /var/lib/rook     3          8m43s   Ready   Cluster created successfully HEALTH_WARN

Подключение к Active Directory

Для интеграции ролевой модели KeyStack с централизованным каталогом организации выполните настройку подключения к Active Directory или LDAP-серверу. Подробные сведения о ролевой модели и принципах её работы описаны в разделе Ролевая модель KeyStack.

Требования к LDAP-серверу

Для корректной работы интеграции требуется:

  • LDAP-сервер с поддержкой TLS (LDAPS).

  • Доступ к серверу исключительно по DNS-имени (для корректной проверки TLS-сертификатов).

  • Корневой сертификат центра сертификации в формате PEM.

  • Учётная запись для привязки (bind) с правами чтения каталога.

Настройка параметров

  1. Откройте файл конфигурации:

    $ vi mutiple-node/lcm-config.yaml

  2. Настройте блок Active Directory:

    # Active Directory
ldap_enable: "true"
ldap_host: "dc-01.domain.loc"
ldap_ca_cert_file: "ldap-root-cert.crt"
ldap_bind_dn: "CN=test,CN=Users,DC=domain,DC=loc"
ldap_user_search_basedn: "CN=Users,DC=domain,DC=loc"
ldap_group_search_basedn: "CN=Users,DC=domain,DC=loc"
ldap_reader_group_dn: "CN=KeyStack-Readers,CN=Users,DC=domain,DC=loc"
ldap_auditor_group_dn: "CN=KeyStack-Auditors,CN=Users,DC=domain,DC=loc"
ldap_admin_group_dn: "CN=KeyStack-Admins,CN=Users,DC=domain,DC=loc"

    Где:

    • ldap_enable — включение интеграции с LDAP ("true" или "false").

    • ldap_host — FQDN-имя сервера Active Directory. В SAN сертификата должно быть указано это имя.

    • ldap_ca_cert_file — имя файла с корневым сертификатом ЦА в формате PEM.

    • ldap_bind_dn — DN учётной записи для привязки к LDAP.

    • ldap_user_search_basedn — базовый DN для поиска пользователей.

    • ldap_group_search_basedn — базовый DN для поиска групп.

    • ldap_reader_group_dn, ldap_auditor_group_dn, ldap_admin_group_dn — DN групп AD, соответствующих ролям KeyStack.

  3. Создайте файл с корневым сертификатом CA:

    $ cat > mutiple-node/ca-cert.pem << EOF
-----BEGIN CERTIFICATE-----
<содержимое сертификата>
-----END CERTIFICATE-----
EOF

  4. Сохраните корневой сертификат центра сертификации в формате PEM в файл с именем, указанным в параметре ldap_ca_cert_file:

    $ vi mutiple-node/ldap-root-cert.crt

    Вставьте содержимое сертификата и сохраните файл.

Создание секретов для NetBox

Создайте Kubernetes-секрет с паролем для учётной записи привязки к LDAP:

$ export config_file='charts-config.yaml'
$ export netbox_namespace=$(yq '.charts[] | select(.name == "netbox") | .namespace' "$config_file")
$ kubectl create namespace "${netbox_namespace}"
$ kubectl create -n "${netbox_namespace}" secret generic netbox-ldap \
  --from-literal=email_password='' \
  --from-literal=secret_key=$(python3 -c "import secrets; print(secrets.token_urlsafe(50))") \
  --from-literal=ldap_bind_password='<пароль учётной записи ldap bind dn>'

Создание секретов для GitLab

Создайте Kubernetes-секрет с паролем для учётной записи привязки к LDAP:

$ export config_file='charts-config.yaml'
$ export gitlab_namespace=$(yq '.charts[] | select(.name == "gitlab") | .namespace' "$config_file")
$ kubectl create namespace "${gitlab_namespace}"
$ kubectl create -n "${gitlab_namespace}" secret generic gitlab-ldap \
  --from-literal=ldap_bind_password='<пароль учётной записи ldap bind dn>'

Подробная информация о ролях KeyStack и их привилегиях описана в разделах Настройка интеграции с LDAP/AD и Описание ролевой модели.

Этап установки order 2

На втором этапе устанавливаются сервисы LCM: GitLab, NetBox, Nexus, Vault, мониторинг и другие компоненты.

Перед запуском команды убедитесь, что все поды из предыдущего этапа подняты и нет ошибок:

$ kubectl get pod -A

Запустите установку:

$ ./offline-bundle/installer.sh --order 2

Примечание

При использовании медленных дисков рекомендуется использовать опцию --helm-wait. Она обеспечивает последовательную установку компонентов:

$ ./offline-bundle/installer.sh --order 2 --helm-wait

Проверка успешного завершения

  1. Проверьте список установленных Helm-чартов:

        $ helm list -aA

Должны отобразиться все компоненты LCM в статусе ``deployed``:

* ``gitlab``
* ``netbox``
* ``nexus3``
* ``vault``
* ``metallb``
* ``nginx-ingress-controller``
* ``postgres-operator``
* ``redis-ha`` (для GitLab и NetBox)
* ``rook-ceph``
* ``rook-ceph-cluster``

  2. Проверьте состояние всех подов:

    $ kubectl get all -A

    Все поды должны быть в статусе Running или Completed.

Наполнение LCM данными

После успешной установки всех компонентов выполните наполнение LCM начальными данными:

$ bash upload.sh mutiple-node/charts-config.yaml

На каждый запуск скрипта создаётся лог-файл в формате upload_<дата>_<время>.log.

Обновление LCM

Для обновления LCM на новую версию выполните следующие действия:

  1. Перед обновлением создайте резервную копию конфигурации кластера:

    $ k0sctl backup

    Эта операция может занять продолжительное время. Для тестовых окружений этот шаг можно пропустить.

  2. Скачайте новую версию инсталлятора:

    $ curl -O https://repo.itkey.com/repository/k-install/mutiple-node-${RELEASE_TAG}.tar.gz

    Например:

    $ curl -O https://repo.itkey.com/repository/k-install/mutiple-node-k0s-ks2025.2.3-rc5.tar.gz

  3. Распакуйте архив:

    $ tar -xzvf mutiple-node-${RELEASE_TAG}.tar.gz
$ cd mutiple-node

  4. Скопируйте значения переменных из текущей инсталляции в новый файл конфигурации:

    $ vi charts-config.yaml

    Убедитесь, что все параметры (domain_name, mgt_vip_address, ext_vip_address, настройки LDAP и другие) соответствуют текущей установке.

  5. Перед запуском команды обновления убедитесь, что все поды подняты и нет ошибок:

    $ kubectl get pod -A

  6. Запустите процесс обновления:

    $ ./offline-bundle/installer.sh --upgrade

    Примечание

    При использовании медленных дисков рекомендуется использовать опцию --helm-wait:

    $ ./offline-bundle/installer.sh --upgrade --helm-wait

Резервное копирование LCM

Для хранения резервных копий LCM используется система Velero, которая сохраняет копии в объектном хранилище S3. Предполагается, что S3-совместимое хранилище предоставляется заказчиком.

Ниже описан процесс настройки резервного копирования на примере тестового развёртывания с использованием Minio.

Настройка Minio для тестирования

Для тестирования работы Velero можно развернуть Minio в Docker на отдельном узле.

  1. Создайте файл minio.yml для Docker Compose:

    services:
  minio:
  image: quay.io/minio/minio
  container_name: minio
  ports:
    - "9000:9000"
    - "9001:9001"
  environment:
    MINIO_ROOT_USER: minio
    MINIO_ROOT_PASSWORD: passw0rd
  volumes:
    - "${PWD}/data:/data"
  command: server /data --console-address ":9001"

  2. Создайте директорию для данных:

    $ mkdir data

  3. Запустите контейнер с Minio:

    $ docker compose -f minio.yml up -d

  4. Откройте веб-интерфейс Minio по адресу http://<IP-адрес>:9001 и создайте бакет с именем lcm.

Настройка Velero

  1. Создайте конфигурационный файл авторизации для доступа к Minio:

    $ cat << EOF > ./credentials-velero
[default]
aws_access_key_id=minio
aws_secret_access_key=passw0rd
EOF

  2. Установите Velero в Kubernetes:

    $ velero install \
  --features=EnableCSI \
  --provider aws \
  --plugins docker.io/velero/velero-plugin-for-aws:v1.12.1 \
  --bucket lcm \
  --secret-file ./credentials-velero \
  --backup-location-config region=minio,s3ForcePathStyle="true",s3Url=http://172.16.130.156:9000

    Где:

    • --plugins — образ плагина для работы с AWS S3 (указан в custom-images-list.txt).

    • --bucket — имя бакета для хранения резервных копий.

    • --backup-location-config — параметры подключения к S3:

      • region — регион S3 (можно посмотреть в GUI Minio).

      • s3Url — URL API Minio.

  3. Удалите файл с учётными данными:

    $ rm -f ./credentials-velero

    Настройки доступа хранятся в Kubernetes-секрете.

  4. Проверьте установку Velero. Должен отобразиться под в статусе Running:

    $ kubectl get pod -n velero
NAME                      READY   STATUS    RESTARTS   AGE
velero-75b867769d-gxh5s   1/1     Running   0          4h29m

Создание резервной копии

Velero поддерживает различные варианты создания резервных копий: по расписанию, с ротацией, с выбором компонентов для включения в копию.

Создайте резервную копию компонента LCM GitLab:

$ velero backup create gitlab --include-namespaces lcm-gitlab

В случае успешного завершения вы увидите:

NAME     STATUS      ERRORS   WARNINGS   CREATED                          EXPIRES   STORAGE LOCATION   SELECTOR
gitlab   Completed   0        0          2025-02-11 14:40:54 +0000 UTC    29d       default            <none>

Для получения подробной информации о резервной копии выполните:

$ velero backup describe gitlab --details

Восстановление из резервной копии

В качестве примера удалите namespace компонента LCM GitLab:

$ kubectl delete namespaces lcm-gitlab

Примечание

Удаление namespace занимает продолжительное время. Дождитесь завершения операции перед переходом к следующему шагу.

Восстановите namespace из резервной копии:

$ velero restore create --from-backup gitlab

Должно отобразиться состояние:

NAME                    BACKUP   STATUS      STARTED                          COMPLETED                        ERRORS   WARNINGS   CREATED                          SELECTOR
gitlab-20250211151000   gitlab   Completed   2025-02-11 15:10:00 +0000 UTC    2025-02-11 15:12:21 +0000 UTC    0        6          2025-02-11 15:10:00 +0000 UTC    <none>

Если восстановление завершилось с ошибками, изучите логи пода Velero:

$ kubectl logs -n velero <имя пода velero>

Для получения имени пода выполните команду:

$ kubectl get pod -n velero