Karmada выпустился из CNCF: оркестрация поверх нескольких кластеров Kubernetes

Karmada перешёл в статус graduated — высший уровень зрелости в CNCF. Формально это случилось 3 сентября 2026, публично объявили 8 сентября на KubeCon в Китае.

Повод разобраться, что это за инструмент, потому что задача, которую он решает, возникает у всех, кто дорос до второго кластера, а вариантов решения немного.

Факты — из анонса CNCF , документации и репозитория проекта . Разбор мой.

Какую задачу решает

У вас несколько кластеров: разные регионы, разные облака, отдельный кластер под GPU. Приложение нужно раскатать в несколько из них, пережить отказ любого и не дублировать при этом манифесты.

Karmada добавляет к стандартному Kubernetes API централизованное размещение, распространение, аварийное переключение и мультикластерное автомасштабирование — причём без изменения самих приложений.

Последнее и есть главная идея дизайна, и её стоит подчеркнуть.

Ключевое решение: приложение остаётся обычным

Ваш Deployment остаётся ровно тем же Deployment, каким был:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

Ничего мультикластерного в нём нет. Всё, что касается распределения по кластерам, живёт в отдельном объекте:

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames:
                - member1
            weight: 1
          - targetCluster:
              clusterNames:
                - member2
            weight: 1

Читается просто: взять Deployment по имени nginx, разложить по кластерам member1 и member2, реплики разделить между ними (Divided) в пропорции весов.

Почему это важно: разделение манифеста приложения и политики размещения означает, что разработчик не обязан знать про мультикластерность. Он пишет обычный манифест, а платформенная команда отдельно описывает, куда это едет. Тот же принцип разделения ответственности, что и у NetworkPolicy или ResourceQuota.

Есть и второй тип политики — OverridePolicy, позволяющий менять отдельные поля для конкретных кластеров: другой реестр образов, другие переменные окружения, другое число реплик.

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

Цепочка от политики до пода в целевом кластере:

  flowchart LR
    RT["Deployment<br/>+ PropagationPolicy"] --> PC["Policy controller"]
    PC --> RB["ResourceBinding"]
    RB --> BC["Binding controller"]
    BC --> W["Work<br/>(по объекту на кластер)"]
    W --> EC["Execution controller"]
    EC --> M1[("member1")]
    EC --> M2[("member2")]

Компоненты управляющего слоя:

• karmada-apiserver — точка входа, с которой общаются все остальные компоненты;
• etcd — хранит объекты Karmada API;
• karmada-scheduler — решает, в какие кластеры и в какой пропорции поедет нагрузка;
• karmada-controller-manager — набор контроллеров, выполняющих основную работу.

Контроллеров четыре, и по их именам легко читается вся логика:

1. Cluster controller — подключает кластеры Kubernetes к Karmada и ведёт их жизненный цикл.
2. Policy controller — следит за PropagationPolicy и создаёт ResourceBinding для каждого подходящего ресурса.
3. Binding controller — следит за ResourceBinding и создаёт объект Work для каждого кластера.
4. Execution controller — следит за Work и раскладывает ресурсы по кластерам-участникам.

Красота здесь в том, что вся схема — это обычные контроллеры Kubernetes, работающие по привычному циклу согласования. Никакой отдельной «магии оркестрации»: та же модель, только уровнем выше.

Push и pull

Подключить кластер можно двумя способами:

• Push — управляющий слой Karmada сам обращается к API кластера-участника. Проще в настройке, но требует сетевой доступности кластера из центра.
• Pull — в кластере-участнике работает агент karmada-agent, который сам забирает задания. Нужен, когда кластер за NAT, в закрытом контуре или на периферии.

Для парка из площадок с разной сетевой доступностью это принципиальная развилка: pull-режим позволяет держать в общем парке кластеры, до которых центр «не дотягивается».

Кто и зачем это использует

Цифры из анонса CNCF:

Среди пользователей — Bloomberg (автоматизация аварийного восстановления и утилизация ресурсов), Trip.com (объединение ресурсов нескольких кластеров, переключение при отказе, миграция нагрузок), Wellhub, DaoCloud (мультиоблако и мультикластерный инференс), Alibaba Cloud, Huawei, Bilibili, Kuaishou, SenseTime, vivo, ZTO.

Сценарии повторяются: аварийное восстановление, региональная устойчивость, объединение мощностей и всё чаще — инфраструктура для AI.

Что означает graduated

Не маркетинговый ярлык, а набор конкретных требований:

• пройден сторонний аудит безопасности;
• создан формальный руководящий комитет — то есть управление проектом прозрачно и не зависит от одной компании;
• принят кодекс поведения CNCF;
• поддерживается бейдж CII Best Practices.

Для тех, кто выбирает инструмент в долгую, это и есть содержательная разница между incubating и graduated: вендоронейтральное управление и проверенная безопасность.

Куда движется

В версии 1.19 появилось планирование многокомпонентных задач для распределённого обучения, а приоритетное планирование доведено до беты и включено по умолчанию.

Дорожная карта 2026 показывает общий вектор — от простого «разложить нагрузку по кластерам» к управлению ресурсами всего парка:

• вытеснение по приоритетам;
• мультикластерные очереди для AI- и батч-задач;
• мультикластерная поддержка Dynamic Resource Allocation (DRA) для GPU и других ускорителей.

Последний пункт объясняет всплеск интереса. Когда ускорители дороги и дефицитны, а обучение идёт на нескольких площадках, вопрос «в каком кластере сейчас есть свободные GPU» становится главным — и решать его вручную невозможно.

Когда всё это вам не нужно

Честная часть, потому что мультикластерная оркестрация — тяжёлая машинерия со своей ценой.

Не нужно, если:

• у вас один кластер и вы решаете задачи изоляции — для этого есть namespace, квоты и сетевые политики (см. задачу про общий кластер);
• отказоустойчивости в пределах одного кластера достаточно — зоны доступности, topologySpreadConstraints и PDB закрывают куда больше сценариев, чем кажется (задача 8);
• второй кластер существует как staging — ему не нужны общие политики с продом;
• у вас нет платформенной команды. Karmada добавляет ещё один управляющий слой, который нужно разворачивать, обновлять, мониторить и бэкапить. Знакомая логика: чтобы обслуживать распределённую систему, вы заводите ещё одну распределённую систему.

Нужно, когда кластер целиком становится доменом отказа: регион лёг, облако недоступно, мощности одной площадки исчерпаны, а нагрузку надо разложить по парку GPU-кластеров. Вот тогда альтернатива Karmada — самописные скрипты поверх нескольких kubeconfig, и она заметно хуже.

Итог

Karmada решает реальную задачу и делает это, не заставляя переписывать приложения: манифест остаётся стандартным, мультикластерность выносится в отдельную политику. Статус graduated добавляет к этому аудит безопасности и нейтральное управление.

Вопрос, который стоит задать себе перед внедрением, простой: отказ целого кластера входит в вашу модель угроз? Если нет — вам пока рано, и это нормально.