Как управлять десятком кластеров Kubernetes и не сойти с ума

Представьте ситуацию: ваш проект вырос из одного уютного кластера в распределенную систему. Теперь у вас есть кластер в локальном дата-центре для безопасности, пара в публичных облаках для масштабирования и еще несколько на «границе» (edge) для минимальной задержки. Знакомая головная боль? Начинаются танцы с бубном: как деплоить приложения везде одновременно, как не запутаться в конфигах и что делать, если один регион внезапно «прилег».

Обычно в таких случаях смотрят в сторону Federation v2, но там все быстро становится сложно. Ребята из сообщества CNCF решили пойти другим путем и сделали Karmada (Kubernetes Armada). Это система, которая превращает пачку разрозненных кластеров в одно логическое целое. Причем делает это так, что ваши приложения даже не замечают подвоха.

Что такое Karmada на самом деле

Если коротко — это «Kubernetes для Kubernetes». Вы работаете с Karmada точно так же, как с обычным кластером: используете те же kubectl, Helm-чарты и привычные манифесты. Но вместо того, чтобы запускать поды на нодах, Karmada запускает ресурсы в целевых кластерах.

Проект вырос из наработок Federation v1 и v2, вобрав в себя лучшее и отбросив излишнюю тяжеловесность. Сейчас это инкубационный проект CNCF, который поддерживают крупные игроки вроде Huawei и разработчики из финансового сектора. Это важно, потому что инструмент затачивали под реальные энтерпрайз-задачи, а не просто для красивых демо.

Почему это удобнее ручного управления

Главная фишка в том, что вам не нужно менять свои YAML-файлы. Если у вас есть рабочий Deployment для Nginx, он без правок залетит в Karmada. А дальше в дело вступают политики.

Умное распределение ресурсов

В Karmada есть концепция Propagation Policy. Вы один раз описываете правила: например, «раскатай это приложение на все кластеры в Европе» или «держи 70% реплик в облаке A и 30% в облаке B». Если один кластер упадет, Karmada сама перекинет нагрузку на живые мощности. Это избавляет от необходимости писать свои скрипты для отказоустойчивости.

Кастомизация без боли

Часто бывает, что в разных кластерах нужны разные настройки: где-то другой ImagePullPolicy, где-то специфический StorageClass. Для этого придумали Override Policy. Вы создаете одно основное описание приложения, а мелкие различия для конкретных площадок выносите в отдельные политики переопределения. Чисто, наглядно и никакой лапши в манифестах.

Никакой привязки к вендору

Karmada абсолютно все равно, где крутятся ваши кластеры. Это может быть bare-metal в офисе, управляемый сервис в AWS или маленькая железка на заводе. Она объединяет их в общую сеть управления, позволяя мигрировать нагрузки между провайдерами буквально одной командой.

Как это устроено внутри

Архитектура Karmada выглядит знакомо для любого, кто хоть раз заглядывал под капот K8s.

Architecture

В центре находится Control Plane, состоящий из API Server, Controller Manager и Scheduler. Работает это по цепочке:

Вы создаете Resource Template (обычный манифест).
Policy Controller подбирает подходящие кластеры.
Binding Controller связывает ресурсы с кластерами.
Execution Controller отправляет команды в конкретные API-серверы подчиненных кластеров.

Кстати, для взаимодействия с кластерами предусмотрено два режима. Push — когда Karmada сама стучится в кластеры, и Pull — когда в кластере стоит агент, который забирает задачи. Второй вариант идеален для закрытых контуров за фаерволом.

Быстрый старт: проверяем в деле

Разработчики подготовили скрипт для локального развертывания через kind (Kubernetes in Docker). Это самый простой способ пощупать инструмент, не тратя деньги на облака.

Сначала клонируем репозиторий:

git clone https://github.com/karmada-io/karmada
cd karmada

Запускаем установку:

hack/local-up-karmada.sh

Скрипт создаст «хост-кластер» для управления и несколько рабочих кластеров. После завершения вы получите конфиги для доступа. Чтобы развернуть приложение, достаточно пары шагов:

Создаем обычный Nginx: kubectl create -f samples/nginx/deployment.yaml
Применяем политику распространения: kubectl create -f samples/nginx/propagationpolicy.yaml

Все. Можно проверять статус — Karmada покажет агрегированную информацию по всем кластерам прямо в вашей консоли.

Demo

Кому стоит присмотреться к проекту

Я бы советовал изучить Karmada, если вы:

Устали синхронизировать конфиги между тестовым и продуктовым кластерами.
Строите гибридное облако (on-prem + public cloud).
Хотите настроить автоматический Disaster Recovery без лишней магии.
Работаете с Edge-вычислениями, где кластеров много, и они постоянно мигают.

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

Если вы чувствуете, что количество кластеров начинает управлять вашим временем, возможно, пора позвать на помощь «Армаду».