CRD (Custom Resource Definition)

CRD (Custom Resource Definition) — механизм расширения API Kubernetes пользовательскими типами ресурсов. Вместо стандартных ресурсов (Pod, Deployment, Service) CRD позволяет определить собственный тип: например, Backup, PostgresCluster, Certificate. После создания CRD Kubernetes начинает принимать объекты нового типа через своё API.

Как работает CRD

Пример простого CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.myapp.example.com
spec:
  group: myapp.example.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              schedule:
                type: string
              target:
                type: string
  scope: Namespaced
  names:
    plural: backups
    singular: backup
    kind: Backup

После применения: kubectl apply -f backup.yaml создаёт объект типа Backup. Оператор (контроллер) отслеживает эти объекты через Watch API и выполняет соответствующие действия.

Оператор-паттерн

CRD без Оператора — просто хранилище данных. Оператор — контроллер, реализующий бизнес-логику для CRD: следит за состоянием объектов и приводит реальное состояние кластера к желаемому (reconciliation loop). Примеры: cert-manager (CRD: Certificate) выпускает TLS-сертификаты; Prometheus Operator (CRD: ServiceMonitor) конфигурирует мониторинг; Zalando Postgres Operator (CRD: PostgresCluster) управляет кластерами PostgreSQL.

История

ThirdPartyResource (TPR) — предшественник CRD — появился в Kubernetes 1.2 (2016). CRD как более стабильная замена введён в Kubernetes 1.7 (2017). В Kubernetes 1.16 (2019) CRD перешли в stable (GA). К 2024 году большинство крупных Kubernetes-расширений (Istio, Argo CD, Crossplane, Flux) реализованы через CRD. Каталог операторов: operatorhub.io — более 300 операторов.

На что обращать внимание

CRD хранятся в etcd как стандартные Kubernetes-объекты. При большом числе CRD (>100 типов) нагрузка на kube-apiserver растёт. Версионирование CRD критично: при изменении схемы v1 → v2 нужны conversion webhooks для миграции существующих объектов. Backup CRD-объектов обязателен: velero или kubectl get crds -o yaml > backup.yaml. CRD не удаляются автоматически при удалении Helm chart — это частая причина «мусора» в кластере.

История CRD в Kubernetes

CRD появились в Kubernetes 1.7 (2017) как замена TPR (Third Party Resources), введённым в Kubernetes 1.2. TPR имели ограниченные возможности валидации. CRD поддерживают OpenAPI v3 схему для валидации, несколько версий ресурса (conversion webhooks), субресурсы /status и /scale. CRD стали стабильными в Kubernetes 1.16 (2019). Концепция Kubernetes Operator, основанная на CRD, разработана CoreOS в 2016 году для автоматизации управления stateful-приложениями. Популярные операторы: Prometheus Operator, PostgreSQL Operator (Zalando Patroni), Cert-manager.

Создание CRD

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.myapp.io
spec:
  group: myapp.io
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              database:
                type: string
  scope: Namespaced
  names:
    plural: backups
    singular: backup
    kind: Backup

На что обращать внимание

Удаление CRD уничтожает все его объекты — это необратимо. Перед удалением: kubectl get crds и kubectl get backup -A — убедиться, что объекты не нужны. Backup CRD-объектов: velero или kubectl get backups -A -o yaml > backup.yaml. CRD не удаляются автоматически при удалении Helm chart — частая причина мусора в кластере. Для сложных CRD используй Operator SDK или Kubebuilder — генераторы controller кода для Go.