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

#Введение в

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

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

Для канонических определений общеплатформенных терминов, таких как кластер global, workload cluster и cluster plugin, см. Глоссарий.

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

#Кластер Global

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

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

• Gateway
  Выступает основным точкой входа в платформу. Он обрабатывает API-запросы от UI, CLI (kubectl) и средств автоматизации, направляя их в соответствующие backend-сервисы.
• Authentication and Authorization (Auth)
  Интегрируется с внешними Identity Providers (IdPs) для обеспечения Single Sign-On (SSO) и контроля доступа на основе RBAC.
• Web Console
  Предоставляет веб-интерфейс для . Он взаимодействует с platform APIs через gateway.
• Cluster Management
  Отвечает за регистрацию, provisioning и управление жизненным циклом workload clusters.
• Services
• Operator Lifecycle Manager (OLM) and Cluster Plugins
  Управляет установкой, обновлениями и жизненным циклом operators и расширений кластера.
• Internal Image Registry
  Предоставляет встроенный out-of-box репозиторий образов контейнеров с доступом на основе ролей.
• Observability
  Обеспечивает централизованные logging, metrics и tracing для кластера global и workload clusters.
• Cluster Proxy
  Обеспечивает безопасную связь между кластером global и workload clusters.

#Workload Cluster

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

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

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

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

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

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

#Функциональный взгляд

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

• Core

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

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

• Extensions

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

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

  Подробнее о расширениях см. Расширить.

#Технический взгляд

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

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

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

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

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

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

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

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

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

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

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

Аварийное восстановление Primary / Standby

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

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

etcd

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

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

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

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

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

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

• Kube-OVN / Calico / Flannel: обеспечивают HA через stateless DaemonSets или control plane components с тремя репликами

ALB

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

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

• Высокодоступный virtual IP на базе Keepalived
• Поддерживает heartbeat detection и active-standby failover

Harbor

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

Registry и MinIO

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