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

#Введение в

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

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

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

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

#Кластер Global

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

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

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

#Workload Cluster

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

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

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

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

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

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

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

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

• Core

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

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

• Расширения

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

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

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

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

Runtime платформенных компонентов Все платформенные компоненты работают как containers внутри 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 направляет трафик к целевым component pods согласно настроенным правилам

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

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

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

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

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

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

Primary / Standby Disaster Recovery

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

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

etcd

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

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

• Prometheus: Несколько экземпляров, дедупликация с помощью Thanos Query и межрегиональная избыточность
• VictoriaMetrics: Cluster mode с распределенными компонентами 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
• Health checks на уровне экземпляров и балансировка нагрузки

Самостоятельно созданный VIP

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

Harbor

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

Registry и MinIO

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