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

#Введение в

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

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

Канонические определения общеплатформенных терминов, таких как кластер global, кластер рабочих нагрузок и плагин кластера, см. в Глоссарии.

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

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

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

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

• Gateway
  Выступает основным входным узлом платформы. Он обрабатывает API-запросы из UI, CLI (kubectl) и инструментов автоматизации, направляя их к соответствующим backend-службам.
• Аутентификация и авторизация (Auth) Интегрируется с внешними Identity Providers (IdPs) для обеспечения Single Sign-On (SSO) и контроля доступа на основе RBAC.
• Web Console Предоставляет веб-интерфейс для . Он взаимодействует с API платформы через gateway.
• Управление кластерами Отвечает за регистрацию, provision и управление жизненным циклом кластеров рабочих нагрузок.
• Службы
• Operator Lifecycle Manager (OLM) и Cluster Plugins Управляет установкой, обновлениями и жизненным циклом operator'ов и расширений кластера.
• Внутренний image registry Предоставляет встроенный из коробки репозиторий container image с доступом на основе ролей.
• Наблюдаемость Обеспечивает централизованное логирование, метрики и tracing как для кластера global, так и для кластеров рабочих нагрузок.
• Cluster Proxy Обеспечивает защищенную связь между кластером global и кластерами рабочих нагрузок.

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

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

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

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

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

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

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

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

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

• Core

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

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

• Расширения

  Расширения в стэках Operator и Cluster Plugin можно классифицировать как:

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

  Дополнительные сведения о расширениях см. в Extend.

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

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

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

• Кластер global обычно состоит как минимум из трех узлов control plane и нескольких worker-узлов
• Высокая доступность etcd является ключевым фактором HA кластера; подробности см. в Key Component High Availability Mechanisms
• Балансировка нагрузки может обеспечиваться внешним load balancer или самостоятельно реализованным VIP внутри кластера

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

• Запросы клиентов сначала проходят через load balancer или самостоятельно реализованный VIP
• Запросы перенаправляются в ALB (Kubernetes Ingress Gateway платформы по умолчанию), работающий на выделенных ingress-узлах (или на узлах control-plane, если это настроено)
• ALB направляет трафик к pod'ам целевых компонентов в соответствии с заданными правилами

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

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

Отказоустойчивость и self-healing

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

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

• Конфигурация control plane и состояние платформы хранятся в etcd как ресурсы Kubernetes
• В случае катастрофических отказов восстановление может быть выполнено из snapshots etcd

Primary / Standby Disaster Recovery

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

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

etcd

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

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

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

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

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

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

• Kube-OVN / Calico / Flannel: обеспечивают HA с помощью stateless DaemonSet'ов или компонентов control plane с тремя репликами

ALB

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

Самостоятельно реализованный VIP

• Виртуальный IP высокой доступности на основе Keepalived
• Поддерживает обнаружение heartbeat и активный/резервный failover

Harbor

• Балансировка нагрузки на основе ALB
• PostgreSQL с HA на базе Patroni
• Режим Redis Sentinel
• Stateless-службы, развернутые в нескольких репликах

Registry и MinIO

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