Управлять несколькими кластерами Kubernetes можно тремя способами: переключением контекстов в kubeconfig вручную, декларативной доставкой конфигураций через GitOps-репозиторий или через платформу мультикластерного управления с единой панелью. Первый вариант работоспособен до трёх-четырёх кластеров, дальше растёт риск ошибок. Второй и третий подходы обычно комбинируют: Git хранит желаемое состояние, а панель управления отвечает за развёртывание, обновление, масштабирование и наблюдаемость. Выбор зависит от того, сколько у вас окружений и насколько они разнесены по площадкам.
Содержимое обзора:
Что делать, если кластеров стало больше пяти
Ручное переключение контекстов (kubectl config use-context) на этом этапе перестаёт работать: администратор рано или поздно применит манифест продуктивного окружения к тестовому. Практический минимум — вынести конфигурации приложений в репозиторий и настроить синхронизацию контроллером вроде Argo CD или Flux, чтобы состояние кластера подтягивалось из Git, а не заливалось руками.
Дальше решается вопрос управляющего слоя. В hub-and-spoke-схеме один кластер играет роль хаба: в нём живёт кластерный API, реестр подключённых кластеров, единые политики RBAC и admission-контроллеры. Рабочие кластеры (spoke) регистрируются агентом и получают оттуда манифесты, секреты и правила размещения нагрузок. Такой слой избавляет от дрейфа конфигураций — расхождения версий CNI, операторов и системных namespace между площадками.
Отдельная задача — сеть и трафик. Межкластерное взаимодействие обычно строят через service mesh с общим корневым центром сертификации либо через шлюзы Ingress с внешней балансировкой и георезервированием DNS. Полная mesh-связность нужна не всегда: если сервисы не ходят друг к другу напрямую, достаточно репликации данных и общего мониторинга.
Какие инструменты закрывают мультикластерное управление
Набор задач у платформ примерно одинаков: инвентаризация кластеров, единая аутентификация и авторизация, раскатка обновлений control plane и рабочих узлов, резервное копирование etcd, сбор метрик и логов в общее хранилище, контроль соответствия политикам безопасности. Различаются они моделью установки (управляемый сервис против self-hosted), поддержкой bare-metal и тем, как решается вопрос локализации данных.
Среди российских решений этот класс задач закрывает отечественная платформа оркестрации контейнеризированных приложений — гибридная облачная система, построенная на базе Kubernetes, с единым интерфейсом для централизованной настройки, развёртывания, обновления и масштабирования множества кластеров и с задачами виртуального частного облака. В ней есть встроенные инструменты обнаружения, диагностики и исправления инцидентов, а также интеграции с продуктами экосистемы: ОС Astra Linux, GitFlic, Tantor, Astra Automation. Отдельно заявлена оптимизация использования ресурсов, в том числе под нагрузки машинного обучения и искусственного интеллекта. В партнёрском списке — РЕАК СОФТ, Luntry, Positive Technologies Container Security, VK Cloud, Контур Налоговый Мониторинг. Подробнее можно узнать на сайте.
Как организовать наблюдаемость и обновления
Метрики и логи со всех кластеров сводят в одну точку: Prometheus в каждом кластере плюс федерация или удалённая запись (remote write) в общее долговременное хранилище. Алерты лучше маркировать меткой кластера сразу на источнике — иначе дежурный не поймёт, какая площадка деградировала.
Обновления версий раскатывают волнами: сначала песочница, затем staging, затем часть продуктивных кластеров, и только потом остальные. Между волнами держат паузу, достаточную для проявления регрессий в операторах и CSI-драйверах. Резервные копии etcd и манифестов делают до начала обновления, а не после — восстановление control plane без свежего снимка превращается в пересборку кластера с нуля.
Типичные ошибки
- Один kubeconfig с правами администратора на все кластеры. Достаточно одной утечки файла или невнимательного применения манифеста — и продуктив получает конфигурацию тестового окружения.
- Разные версии Kubernetes и системных компонентов на площадках. Манифест, отработавший в одном кластере, падает в другом из-за удалённых API-групп; отладка занимает часы вместо минут.
- Настройка через kubectl apply мимо репозитория. Ручные правки затираются при следующей синхронизации GitOps-контроллера, а причину «самопроизвольного отката» ищут долго.
- Мониторинг, поднятый отдельно в каждом кластере. Нет сквозной картины: инцидент, затрагивающий несколько площадок, выглядит как набор несвязанных алертов.
- Отсутствие проверенной процедуры восстановления etcd. Бэкапы формально есть, но их ни разу не разворачивали, и в момент отказа выясняется, что снимок неполный или несовместим по версии.
