#Архитектура

#Введение в

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

Архитектура построена по модели hub-and-spoke, состоящей из global кластера и множества кластеров рабочих нагрузок. Такая конструкция обеспечивает централизованное управление при сохранении независимого выполнения и масштабирования рабочих нагрузок.

#Основные архитектурные компоненты

#Глобальный кластер

global кластер служит централизованным узлом управления и контроля . Он предоставляет платформенные сервисы, такие как аутентификация, управление политиками, операции жизненного цикла кластеров и наблюдаемость. Также это центральный узел для управления мультикластерной средой и обеспечивает функциональность между кластерами.

Ключевые компоненты включают:

• Gateway
  Выполняет роль основной точки входа на платформу. Управляет API-запросами от UI, CLI (kubectl) и инструментов автоматизации, маршрутизируя их к соответствующим backend-сервисам.
• Аутентификация и авторизация (Auth)
  Интегрируется с внешними Identity Providers (IdPs) для обеспечения единого входа (SSO) и контроля доступа на основе RBAC.
• Веб-консоль
  Предоставляет веб-интерфейс для . Взаимодействует с API платформы через Gateway.
• Управление кластерами
  Обрабатывает регистрацию, подготовку и управление жизненным циклом кластеров рабочих нагрузок.
• Сервисы
• Operator Lifecycle Manager (OLM) и плагины кластера
  Управляют установкой, обновлениями и жизненным циклом операторов и расширений кластера.
• Внутренний реестр образов
  Предлагает встроенный репозиторий контейнерных образов с управлением доступом на основе ролей.
• Наблюдаемость
  Обеспечивает централизованный сбор логов, метрик и трассировок как для global, так и для кластеров рабочих нагрузок.
• Прокси кластера
  Обеспечивает безопасную связь между global кластером и кластерами рабочих нагрузок.

#Кластер рабочих нагрузок

Кластеры рабочих нагрузок — это среды на базе Kubernetes, управляемые global кластером. Каждый кластер рабочих нагрузок запускает изолированные приложения и наследует управление и конфигурацию от центрального управляющего уровня.

#Внешние интеграции

• Identity Provider (IdP)
  Поддерживает федеративную аутентификацию через стандартные протоколы (OIDC, SAML) для унифицированного управления пользователями.
• Доступ через API и CLI
  Пользователи могут взаимодействовать с через RESTful API, веб-консоль или командные инструменты, такие как kubectl и ac.
• Балансировщик нагрузки (VIP/DNS/SLB)
  Обеспечивает высокую доступность и распределение трафика для Gateway и ingress-точек доступа global и рабочих кластеров.

#Масштабируемость и высокая доступность

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

• Каждый компонент может быть развернут с резервированием для устранения единой точки отказа.
• global кластер поддерживает управление десятками и сотнями кластеров рабочих нагрузок.
• Кластеры рабочих нагрузок могут масштабироваться независимо в зависимости от нагрузки.
• Использование VIP/DNS/Ingress обеспечивает бесшовное маршрутизирование и переключение при сбоях.

#Функциональная перспектива

Полный функционал () состоит из Core и расширений на основе двух технических стеков: Operator и Cluster Plugin.

• Core

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

  • Соответствует самым высоким стандартам безопасности
  • Обеспечивает максимальную стабильность
  • Предлагает самый длительный жизненный цикл поддержки

• Расширения

  Расширения в стеках Operator и Cluster Plugin классифицируются на:

  • Aligned – стратегия жизненного цикла с несколькими потоками поддержки, согласованная с .
  • Agnostic – стратегия жизненного цикла с несколькими потоками поддержки, выпускаемая независимо от .

  Подробнее о расширениях см. в разделе Extend.

#Техническая перспектива

Выполнение компонентов платформы
Все компоненты платформы запускаются в контейнерах внутри управляющего Kubernetes-кластера (global кластера).

Архитектура высокой доступности

• global кластер обычно состоит минимум из трёх узлов управляющего плана и нескольких рабочих узлов
• Высокая доступность etcd является ключевой для HA кластера; подробности см. в разделе Key Component High Availability Mechanisms
• Балансировка нагрузки может обеспечиваться внешним балансировщиком или собственным VIP внутри кластера

Маршрутизация запросов

• Клиентские запросы сначала проходят через балансировщик нагрузки или собственный VIP
• Запросы перенаправляются на ALB (стандартный Kubernetes Ingress Gateway платформы), работающий на выделенных ingress-узлах (или управляющих узлах при соответствующей настройке)
• ALB маршрутизирует трафик к целевым подам компонентов согласно заданным правилам

Стратегия репликации

• Ключевые компоненты запускаются минимум с двумя репликами
• Важные компоненты (например, реестр, MinIO, ALB) запускаются с тремя репликами

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

• Обеспечивается взаимодействием kubelet, kube-controller-manager, kube-scheduler, kube-proxy, ALB и других компонентов
• Включает проверки состояния, переключение при сбоях и перенаправление трафика

Хранение данных и восстановление

• Конфигурация управляющего плана и состояние платформы хранятся в etcd как ресурсы Kubernetes
• При катастрофических сбоях восстановление возможно из снимков etcd

Основное / резервное аварийное восстановление

• Два отдельных global кластера: Primary Cluster и Standby Cluster
• Механизм аварийного восстановления основан на синхронизации данных etcd в реальном времени с Primary Cluster на Standby Cluster
• В случае недоступности Primary Cluster из-за сбоя сервисы быстро переключаются на Standby Cluster

#Механизмы высокой доступности ключевых компонентов

etcd

• Развернут на трёх (или пяти) узлах управляющего плана
• Использует протокол RAFT для выбора лидера и репликации данных
• Развёртывание на трёх узлах выдерживает отказ одного узла; на пяти — двух
• Поддерживает локальное и удалённое резервное копирование снимков в S3

Компоненты мониторинга

• Prometheus: несколько инстансов, дедупликация с Thanos Query, кросс-региональная избыточность
• VictoriaMetrics: кластерный режим с распределёнными компонентами VMStorage, VMInsert и VMSelect

Компоненты логирования

• Nevermore собирает логи и данные аудита
• Kafka / Elasticsearch / Razor / Lanaya развернуты в распределённом режиме с несколькими репликами

Сетевые компоненты (CNI)

• Kube-OVN / Calico / Flannel достигают HA через безсостояночные DaemonSet или компоненты управляющего плана с тройной репликацией

ALB

• Оператор развернут с тремя репликами, включён выбор лидера
• Проверки состояния на уровне инстансов и балансировка нагрузки

Собственный VIP

• Высокодоступный виртуальный IP на базе Keepalived
• Поддерживает обнаружение heartbeat и переключение active-standby

Harbor

• Балансировка нагрузки на базе ALB
• PostgreSQL с Patroni для HA
• Redis в режиме Sentinel
• Безсостояночные сервисы развернуты с несколькими репликами

Registry и MinIO

• Registry развернут с тремя репликами
• MinIO в распределённом режиме с кодированием с удалением, избыточностью данных и автоматическим восстановлением