База знаний
Войти

Архитектура

Архитектура РОСА Кубис состоит из кластера управления (Cluster Management) и кластеров рабочих нагрузок (клиентских кластеров):

  • Кластер управления ‒ представляет из себя кластер оркестрации контейнеров Kubernetes, который позволяет создавать и управлять клиентскими кластерами оркестрации контейнеров. Может быть использован как отдельно стоящий кластер.
  • Клиентский кластер ‒ кластер оркестрации контейнеров, который может быть развернут под управлением кластера управления.

Структура Комплекса приведена на рисунке 1.

Рисунок 1 ‒ Структура Комплекса

Кластер управления

Кластер управления необходим для управления инфраструктурой клиентских кластеров, централизованного сбора и хранения логов и метрик мониторинга, управления доступами и пользователями. Кластер управления не предназначен для запуска и контроля нагрузок в клиентских кластерах. В случае отказа кластера управления, работа клиентских кластеров не прерывается. Восстановление работы кластера управления описано в Инструкции "Восстановить потерянный кластер". Возможность развертывания DR кластера управления описана в п. Начальная страница веб-интерфейса.

Установка может быть произведена только на ОС Linux.

Поддерживаемые версии ОС перечислены в таблице 1.

  • Перед запуском установки с провайдером Shturval v2 требуется отключить Firewalld на всех хостах.

Для создания кластера управления рекомендуется конфигурация:

  • три Control Plane-узла;
  • три Worker-узла (и более).

Кластер управления может быть развернут на одном Control Plane-узле. Подробнее см. в п. Минимальные системные требования для кластера управления.

Рекомендуемые системные требования применимы, если не используется кластер управления для развертывания кастомных нагрузок. В случае использования кластера управления как отдельно стоящего кластера, дополнительно к описанным требованиям следует выделять ресурсы для кастомных нагрузок (таблица 2).

Клиентский кластер

Клиентские кластеры могут быть созданы после успешного развертывания кластера управления. Есть возможность развертывания кластеров в защищенной конфигурации. Эта опция осуществляет установку защищенного соединения с Kubelet и автоматическую настройку политики аудита. Доступно создание клиентских кластеров различных версий Kubernetes в рамках одного кластера управления.

Доступно создание клиентских кластеров с использованием заранее подготовленных хостов или шаблонов провайдеров инфраструктуры:

  • oVirt (в т.ч. RedVirt, zVirt) с версией oVirt Engine API не ниже 4.4;
  • vSphere 6.7 update 3 или 7.0 и выше;
  • OpenStack;
  • Basis Dynamix;
  • Shturval v2;
  • Yandex Cloud;
  • VMware vCloud Director.

Рекомендуемые системные требования для клиентского кластера приведены в таблице 3.

Требование к Worker-узлам52 + WL применимо только при наличии в кластере Infra Worker-узлов и говорит о том, что к минимальному количеству (2 CPU) необходимо добавить количество CPU, требуемое для развертывания кастомных нагрузок. При отсутствии в кластере Infra Worker-узлов следует принимать рекомендуемое требование к Worker узлам в виде 16 + WL.

Создание кластеров и управление ими доступно:

  • в графическом интерфейсе;
  • интерфейсе командной строки и с использованием команд;
  • с использованием программного интерфейса (например, для встраивания запросов в конвейеры поставки (CI/CD pipelines)).

Взаимодействие кластера управления с клиентскими кластерами

Кластер управления:

  • управляет процессами создания кластеров и объектов инфраструктуры клиентских кластеров (в т.ч. machines, machinehealthchecks);
  • предоставляет централизованное управление доступом, в т.ч. правами и сессиями пользователей;
  • предоставляет централизованное хранение и графическое отображение метрик и журналов клиентских кластеров.

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

Установка

Для развертывания Комплекса используется утилита первоначального развертывания – stc. Она позволяет развернуть Комплекс в открытом и закрытом окружениях. .

Обновление

Обновление кластера управления и каждого клиентского кластера в РОСА Кубис происходят независимо друг от друга. Обновление доступно только по стабильному каналу (кастомный ресурс ShturvalUpdateChannel, updateChannel = stable). Все доступные обновления (стабильные версии) для версии, установленной в вашем кластере, отображаются в интерфейсе в блоке "Обновление" дашбордов кластера управления и клиентского кластера.

Если Комплекс эксплуатируется в закрытом контуре, то доступные версии будут отображаться после добавления .bundle с новой версии в registry. Для обновления в закрытых установках следует выполнить шаги, описанные в п. Обновление в закрытом контуре.

Выпускается 2 вида версий (п. Обновление):

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

Для каждого вида версии доступно ручное и автоматическое обновление кластеров . Обновление каждого кластера происходит независимо друг от друга. Обновление доступно в закрытом и открытом окружениях.

Обновление версии кластера управления и клиентского кластера может проходить с помощью графического интерфейса, консоли или скрипта в режимах:

  • ручной запуск;
  • автоматический запуск по расписанию с указанием окна времени обновления;

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

  • минорная версия ‒ происходят значительные изменения: обновляется версия Kubernetes, могут быть изменены компоненты или версии компонентов;
  • патч-версия ‒ выпускаемые багфиксы, устранения уязвимостей компонентов.

В установках в открытом контуре при наличии активной лицензии версии для обновления становятся доступными сразу после релиза совместимой версии. В закрытом контуре для установки используется .bundle с обновлением. Инструкция по обновлению зеркала репозитория приведена в базе знаний на портале технической поддержки.

Из графического интерфейса

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

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

Из интерфейса командной строки

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

Для ручного запуска обновления в кластере нужно указать необходимую версию в кастомном ресурсе ShturvalUpdate. В команде используются свои значения параметров.

Пример команды запуска обновления

kubectl -n shturval-update-system patch su shturval-update --type=merge -p '{"spec":{"version":"ВВЕДИТЕ-ВЕРСИЮ-ДЛЯ-ОБНОВЛЕНИЯ"}}'

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

  1. создать YAML-файл update-schedule.yaml с манифестом объекта ShturvalUpdateSchedule. Пример ShturvalUpdateSchedule для настройки отложенного обновления (параметры описаны в таблице 4):
apiVersion: update.shturval.tech/v1beta1
kind: ShturvalUpdateSchedule
metadata:
name: <имя объекта>
namespace: shturval-update-system
spec:
allowMinorVersion:  <ваше значение параметра>
pauseIfUpdatePeriodExceed:  <ваше значение параметра>
schedule:  <ваше значение параметра>
updatePeriod:  <ваше значение параметра>
  1. применить созданный ShturvalUpdateSchedule в кластере.

Команда применения update-schedule.yaml:

kubectl apply -f update-schedule.yaml
  1. когда ShturvalUpdateSchedule применен в кластере, добавить имя созданного ShturvalUpdateSchedule и версию для обновления в кастомный ресурс ShturvalUpdate. В команде используются свои значения параметров.

Пример команды инициирования обновления по расписанию:

kubectl -n shturval-update-system patch su shturval-update --type=merge -p '{"spec":{"followSchedule":"УКАЖИТЕ-ИМЯ-СОЗДАННОГО-ShturvalUpdateSchedule"}}'

Аутентификация и авторизация

Комплекс не использует и не хранит пользователей. Исключением является встроенная (резервная) учетная запись с административными правами. Эта УЗ которая создается по умолчанию в процессе установки Комплекса.

Для аутентификации пользователей Комплекс взаимодействует с централизованной службой каталогов (п. Интеграция с LDAP). Поддерживаются каталоги:

  • Active Directory;
  • OpenLdap;
  • FreeIPA;
  • ALDPro;
  • SambaDC.

По умолчанию используется внутренний сервис аутентификации. Есть возможность подключения внешнего сервиса (Инструкция "Как подключить внешний сервис аутентификации"), поддерживающего протокол OIDC OAuth 2.0, например, Blitz или Keykloak.

В Комплексу есть предустановленный набор ролей (п. Менеджер доступов), позволяющих гибко настроить доступ на различных уровнях:

  • к кластеру управления и всем клиентским кластерам;
  • к кластеру управления или конкретному клиентскому кластеру;
  • к конкретным объектам кластеру управления или клиентского кластера;
  • к конкретному неймспейсу кластеру управления или клиентского кластера;
  • к конкретным объектам неймспейса кластеру управления или клиентского кластера.

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

Использование сервисов

При установке Комплекса и клиентских кластеров есть возможность выбора сервисов, которые будут развернуты автоматически. Все используемые сервисы сканируются на уязвимости для безопасного использования в составе Комплекса.