Что такое CRD (Custom Resource Definition) в Kubernetes?

«Что такое CRD (Custom Resource Definition) в Kubernetes?» — вопрос из категории Kubernetes, который задают на 26% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

CRD (Custom Resource Definition) — это объект Kubernetes, который позволяет расширять API кластера, добавляя в него новые типы ресурсов (Custom Resources), специфичные для вашего приложения или инфраструктуры. Это фундаментальный механизм для операторов и управления сложными stateful-приложениями.

Зачем это нужно в DevOps?

  1. Декларативное управление сложными приложениями: Вместо набора разрозненных Deployment, Service, ConfigMap вы можете создать один доменный ресурс, например, PostgresCluster. Оператор (контроллер) будет наблюдать за этим ресурсом и сам создаст все необходимые объекты Kubernetes.
  2. Интеграция сторонних систем: Популярные DevOps-инструменты (Prometheus, Cert-Manager, Istio) используют CRD для своей работы в кластере. Например, Cert-Manager добавляет CRD Certificate для автоматического получения SSL-сертификатов от Let's Encrypt.

Пример CRD для простого ресурса CronJob (упрощённо):

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: cronjobs.example.devops.com
spec:
  group: example.devops.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                schedule:
                  type: string
                command:
                  type: string
  scope: Namespaced
  names:
    plural: cronjobs
    singular: cronjob
    kind: CronJob
    shortNames:
    - cj

После применения этого CRD вы сможете создавать свои объекты:

apiVersion: example.devops.com/v1
kind: CronJob
metadata:
  name: my-backup-job
spec:
  schedule: "0 2 * * *"
  command: "/bin/sh /scripts/backup.sh"

Важное ограничение: Сам CRD только определяет схему нового ресурса. Чтобы этот ресурс что-то делал (создавал Pod, менял конфиги), необходим контроллер (оператор), который будет следить за объектами этого типа и выполнять бизнес-логику.