Crossplane. Первый взгляд: модель и ключевые концепции

Адаптивный обзор по мотивам статьи A First Look at Crossplane — the Multi-Cloud Orchestration System (kaliarch, 28 октября 2025). Изложение своими словами; примеры YAML и команды — как в оригинале. Диаграммы — оригинальные (Mermaid), а не перенос картинок из статьи. Все права на исходный материал принадлежат автору.

Это вводная часть цикла: если Часть 1 и Часть 2 — про практику, то здесь — про модель понятий целиком, чтобы дальше не путаться в терминах.

Crossplane одной фразой

Crossplane — это расширение Kubernetes, которое превращает кластер в universal control plane: единую точку управления, откуда можно провижинить и держать в актуальном состоянии внешние ресурсы (AWS, Azure, GCP и не только) — теми же средствами, что и обычные объекты Kubernetes.

Идея в том, что внешний ресурс (например, S3-бакет) становится нативным объектом Kubernetes (CRD). А контроллер Crossplane непрерывно сверяет желаемое состояние (ваш YAML) с фактическим (что реально в облаке) и устраняет расхождения — тот же reconcile-цикл, что у любого Kubernetes-контроллера.

  flowchart LR
    subgraph K8s["Kubernetes (control plane)"]
        MR["Managed Resource<br/>(CRD)"]
        CTRL["Контроллер провайдера<br/>reconcile loop"]
    end
    subgraph Cloud["Облако (AWS / Azure / GCP)"]
        RES["Реальный ресурс<br/>(например, S3-бакет)"]
    end
    User["kubectl apply -f bucket.yaml"] --> MR
    MR <--> CTRL
    CTRL -- "создаёт / изменяет / сверяет" --> RES
    RES -- "фактическое состояние" --> CTRL

Модель понятий

У Crossplane две «половины». Первая — как дотянуться до облака (Provider, ProviderConfig, Managed Resource). Вторая — как из этого собрать собственный удобный API для команд (Composition, XRD, XR, Claim).

Как дотянуться до облака

Provider — cluster-scoped набор CRD, который расширяет Kubernetes для работы с конкретным внешним сервисом (AWS, Azure, GCP). Именно провайдер приносит в кластер типы ресурсов вроде Bucket.
ProviderConfig — конфигурация провайдера: как аутентифицироваться и с какими настройками работать.
Managed Resource (MR) — инстанс CRD провайдера, представляющий реальный внешний ресурс. За ним закреплён reconcile: Crossplane постоянно приводит облако к описанному состоянию.

Как собрать свой API

Composite Resource Definition (XRD) — определяет схему собственного API: какие поля есть у вашего кастомного ресурса (и, в v1-модели, у Claim).
Composition — переиспользуемый шаблон, который группирует несколько Managed Resources под одним XRD (cluster-scoped). Это «рецепт»: из каких MR собирается ваш сервис.
Composite Resource (XR) — конкретный инстанс Composition.
Claim (XC) — namespaced, «повёрнутый к разработчику» интерфейс, зеркалящий XR, для мультитенантности: команда в своём namespace запрашивает ресурс, не касаясь cluster-scoped объектов.

  flowchart TD
    subgraph Platform["Платформенная команда (cluster-scoped)"]
        XRD["XRD<br/>схема своего API"]
        COMP["Composition<br/>рецепт из MR"]
    end
    subgraph Dev["Разработчик (namespace)"]
        CLAIM["Claim (XC)<br/>namespaced-запрос"]
    end
    XR["Composite Resource (XR)"]
    subgraph MRs["Managed Resources"]
        MR1["Bucket"]
        MR2["BucketVersioning"]
        MR3["Encryption"]
    end
    PROV["Provider + ProviderConfig"]
    CLOUD["Облако"]

    XRD --> XR
    COMP --> XR
    CLAIM --> XR
    XR --> MR1 & MR2 & MR3
    MR1 & MR2 & MR3 --> PROV --> CLOUD

Итог: платформенная команда один раз описывает XRD + Composition, а разработчики потребляют готовый сервис простым namespaced-запросом — не зная деталей облака.

⚠️ Про версии. Модель с Claim и cluster-scoped XR — это подход Crossplane v1. В v2 её переработали: XR стали namespaced, а отдельные Claim по сути ушли (namespaced XR закрывает мультитенантность сам). Практику на v2 смотрите в Части 2 про Composition. Концепции же (Provider / MR / Composition / XRD) остаются актуальными в обеих версиях.

Осмотреться в кластере

Базовые команды, чтобы увидеть, что вообще есть:

BASH

kubectl get providers
kubectl get providerconfig
kubectl get managed        # все Managed Resources разом
kubectl get composition
kubectl get composite      # все XR
Нажмите, чтобы развернуть и увидеть больше

kubectl get managed особенно удобна — показывает все внешние ресурсы под управлением Crossplane одной командой, независимо от типа.

Мини-пример: свой API через XRD

XRD описывает схему кастомного ресурса. Здесь — myComputeResource с единственным полем storage, ограниченным перечислением:

YAML

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: mycomputeresources.test.example.org
spec:
  group: test.example.org
  names:
    kind: myComputeResource
    plural: mycomputeresources
  versions:
    - name: v1alpha1
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                storage:
                  type: string
                  enum: ["small", "medium", "large"]
Нажмите, чтобы развернуть и увидеть больше

После этого потребитель создаёт ресурс по новой, своей схеме — коротко и без деталей реализации:

YAML

apiVersion: test.example.org/v1alpha1
kind: myComputeResource
metadata:
  name: my-team-resource
spec:
  storage: "large"
Нажмите, чтобы развернуть и увидеть больше

Всю «магию» (что large означает конкретный тип диска/инстанса и какие MR создать) прячет привязанная к XRD Composition.

Что дальше

Теперь, когда модель понятий на месте, переходите к практике:

Часть 1. Основы: control plane, провайдеры и Managed Resources — установка Crossplane, интеграция с AWS через IRSA, первые Managed Resources.
Часть 2. Composition: собственные API без написания контроллеров — XRD, Composition, XR и Functions на реальном примере S3-сервиса (уже на модели v2).