Архитектура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• vSphere 6.7 update 3 или 7.0 и выше (п. С провайдером vSphere);
• oVirt (в т.ч. RedVirt, zVirt) с версией oVirt Engine API не ниже 4.4 (п. С провайдером oVirt);
• OpenStack (п. С провайдером OpenStack);
• Basis Dynamix (п. С провайдером BasisDynamix);
• Shturval v2 (п. С провайдером Shturval V2);
• Yandex Cloud (п. С провайдером Yandex Cloud).

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

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

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

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

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

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

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

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

Установка

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

Обновление

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

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

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

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

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

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

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

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

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

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

Описание запуска ручного обновления кластера или настройки автоматического обновления из графического интерфейса описано в п. Управление обновлением.

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

export SHTURVAL_VERSION="X.X.X"
kubectl -n shturval-update-system patch su shturval-update --type=merge -p '{"spec":{"version":"$SHTURVAL_VERSION"}}'

Рисунок 2 ‒ Поддержка релизов

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

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

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

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

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

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

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

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

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

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

Логирование и мониторинг

Для сбора метрик в клиентских кластерах и кластере управления поставляется VM Agent (п. Модуль мониторинга. Централизованный сбор метрик (Victoria Metrics)). Для сбора логов – Vector (п. Модуль локального сбора логов (Vector)). Метрики (п. Анализ состояния в Комплексе) доступны на предварительно настроенных дашбордах Grafana. Доступ в Grafana осуществляется по SSO с учетом ролевой модели.

Журналы (п. Анализ состояния в Комплексе) доступны в OpenSearch. Если кластер установлен в защищенной конфигурации, автоматически будет настроена Audit Policy (п. Audit Policy) и создан соответствующий индекс в OpenSearch. Доступ в OpenSearch осуществляется по SSO с учетом ролевой модели. Есть возможность гибкого управления оповещениями (п. Оповещения) из графического интерфейса Комплекса.

Графический интерфейс

Графический интерфейс Комплекса доступен на русском и английском языках в светлой или темной темах (п. Настройки пользовательского интерфейса). Он содержит подсказки и информационные сообщения для упрощения использования Комплекса. В графическом интерфейсе также доступно управление объектами с помощью импорта (п. Импорт манифестов) и редактирования YAML-манифестов. На страницах графического интерфейса доступен вызов документации соответствующей версии Комплекса.

Безопасность

В составе Комплекса поставляется встроенные инструменты (п. Инструменты ИБ) для обеспечения безопасности работы в кластере:

• Kyverno (п. Политики безопасности);
• Trivy Operator (п. Результаты сканирования);
• Графический редактор сетевых политик Cilium Network Policies (п. Сетевые политики Cilium).

Также есть возможность установить наложенные средства информационной безопасности, например Kaspersky Container Security.

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

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