Как создавать и кастомизировать Custom Resource Definitions (CRD) в Kubernetes?

CRD расширяет API Kubernetes, позволяя создавать свои типы ресурсов, которыми можно управлять через kubectl, как встроенными Pod'ами или Deployments. Это основа для операторов (Kubernetes Operators).

1. Создание базового CRD: Определяем схему ресурса в YAML-манифесте.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: webapps.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true  # API сервер будет обслуживать эту версию
      storage: true # Эта версия будет использоваться для хранения данных
      schema:
        openAPIV3Schema: # Схема валидации (обязательна с v1)
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
                image:
                  type: string
                port:
                  type: integer
  scope: Namespaced # Или Cluster
  names:
    plural: webapps       # Используется в URL: /apis/example.com/v1/namespaces/<ns>/webapps
    singular: webapp      # Используется в `kubectl get webapp`
    kind: WebApp          # Тип ресурса в YAML
    shortNames:
    - wa                  # Сокращение: `kubectl get wa`

Применяем: kubectl apply -f webapp-crd.yaml.

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

apiVersion: example.com/v1
kind: WebApp
metadata:
  name: my-test-app
spec:
  replicas: 3
  image: nginx:latest
  port: 8080

3. Кастомизация и создание оператора: Сам CRD — это лишь объявление структуры данных. Чтобы Kubernetes мог что-то делать с этими объектами (например, создавать Deployments и Services), нужен Контроллер (Оператор).

• Контроллер — это программа (часто на Go), которая следит за событиями CR (Create, Update, Delete) через watch API Kubernetes.
• В ответ на эти события он выполняет бизнес-логику, приводя реальное состояние кластера (фактические Pod'ы) к желаемому, описанному в CR (spec.replicas: 3).
• Для разработки операторов используются фреймворки: Kubebuilder или Operator SDK (часть от Red Hat). Они генерируют каркас кода, включая CRD-манифесты и boilerplate для контроллера.

Итог: CRD определяет "что", а Оператор (контроллер) реализует "как". Вместе они позволяют реализовать паттерн "Operator Pattern" для управления сложными stateful-приложениями (базами данных, message brokers) внутри Kubernetes.