Как работает Kubernetes-оператор?

Как работает Kubernetes-оператор

Kubernetes-оператор — это паттерн проектирования и конкретная реализация для автоматизации управления пользовательскими приложениями (Custom Resources, CR) в кластере Kubernetes. По сути, это метод расширения возможностей Kubernetes для управления сложными, stateful—приложениями, которые требуют знания предметной области, выходящего за рамки стандартных контроллеров (например, Deployment или StatefulSet). Оператор инкапсулирует операционные знания (знание того, как развернуть, масштабировать, обновить и восстановить конкретное приложение) в программную логику.

Основные компоненты и принцип работы

Оператор состоит из двух ключевых частей: Custom Resource Definition (CRD) и Контроллера (Controller).

1. Custom Resource Definition (CRD) Это расширение API Kubernetes. CRD определяет новую схему объекта (ресурса), специфичную для вашего приложения.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myapps.example.com
spec:
  group: example.com
  versions:
    - name: v1alpha1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicaCount:
                  type: integer
                image:
                  type: string
            status:
              type: object
              properties:
                availableReplicas:
                  type: integer
  scope: Namespaced
  names:
    plural: myapps
    singular: myapp
    kind: MyApp
    shortNames:
    - ma

После применения этого CRD в кластере появляется новый тип ресурса, например, MyApp. Пользователи могут создавать его экземпляры (объекты):

apiVersion: example.com/v1alpha1
kind: MyApp
metadata:
  name: my-app-instance
spec:
  replicaCount: KeyError: 'replicaCount'
  image: nginx:latest

2. Контроллер (Controller) — "мозг" оператора Это цикл управления, постоянно работающая программа (часто развернутая как Pod в кластере), которая наблюдает за состоянием Custom Resources (CR) и других ресурсов Kubernetes (Pods, Services, ConfigMaps и т.д.), стремясь привести фактическое состояние системы к желаемому, указанному в спецификации CR.

Цикл управления (Reconcile Loop)

Это ядро работы любого оператора. Контроллер реализует бесконечный цикл:

1. Наблюдение (Watch): Контроллер подписывается на события Kubernetes API для интересующих его типов ресурсов (прежде всего — свои CR, а также связанные Pods, Deployments и др.).
2. Анализ (Analysis): При любом изменении (создание, обновление, удаление CR или изменение состояния связанного Pod) контроллер получает уведомление. Он извлекает из API желаемое состояние (Desired State), которое описано в .spec объекта CR (например, replicaCount: 3).
3. Сравнение (Comparison): Контроллер считывает фактическое состояние (Actual State) кластера, проверяя, какие Pods, Services и другие ресурсы уже существуют и в каком они состоянии.
4. Вычисление разницы (Diff Calculation): Логика оператора вычисляет разницу между желаемым и фактическим состоянием. Эта логика содержит экспертные знания о приложении ("для обеспечения 3 реплик моего приложения нужен StatefulSet с 3 pod'ами, headless Service и ConfigMap с особыми настройками").
5. Действие (Action): Контроллер через Kubernetes API выполняет необходимые действия для ликвидации разницы:

    *   Если Pod'ов меньше — создает новые (чаще через управление Deployment/StatefulSet).
    *   Если образ устарел — инициирует rolling update.
    *   Если Pod упал и не восстанавливается — пересоздает его на другой ноде.
    *   Обновляет **статус (Status)** объекта CR в поле `.status`, отражая текущее фактическое состояние (например, `availableReplicas: 2`), чтобы пользователь мог видеть прогресс.

1. Повтор (Repeat): Цикл начинается заново. Идеальное состояние оператора — когда разница между желаемым и фактическим состоянием равна нулю (реконсиляция не требует действий).

Ключевые инструменты для разработки

Написание оператора "с нуля" — сложная задача. На практике используют фреймворки:

• Kubebuilder / Controller Runtime: Самый популярный фреймворк от сообщества Kubernetes. Генерирует каркас проекта на Go, берет на себя работу с API-клиентом, кешированием, очередями событий.
• Operator SDK: Инструмент от Red Hat (часть OpenShift), поддерживающий Go, Ansible и Helm как языки для написания логики оператора.

Пример фрагмента логики реконсиляции на Go (Kubebuilder):

func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    // 1. Получить объект MyApp (желаемое состояние)
    myApp := &examplev1alpha1.MyApp{}
    if err := r.Get(ctx, req.NamespacedName, myApp); err != nil {
        return ctrl.Result{}, client.IgnoreNotFound(err)
    }

    // 2. Проверить фактическое состояние - есть ли нужный StatefulSet?
    foundSts := &appsv1.StatefulSet{}
    err := r.Get(ctx, types.NamespacedName{Name: myApp.Name, Namespace: myApp.Namespace}, foundSts)
    if err != nil && errors.IsNotFound(err) {
        // 3. Разница обнаружена: StatefulSet отсутствует -> создать
        sts := r.deploymentForMyApp(myApp) // Функция, строящая манифест
        if err := r.Create(ctx, sts); err != nil {
            return ctrl.Result{}, err
        }
        // Запланировать повторную реконсиляцию
        return ctrl.Result{Requeue: true}, nil
    } else if err != nil {
        return ctrl.Result{}, err
    }

    // 4. Проверить, совпадает ли кол-во реплик с желаемым
    if *foundSts.Spec.Replicas != myApp.Spec.ReplicaCount {
        foundSts.Spec.Replicas = &myApp.Spec.ReplicaCount
        if err := r.Update(ctx, foundSts); err != nil {
            return ctrl.Result{}, err
        }
    }

    // 5. Обновить статус CR
    myApp.Status.AvailableReplicas = foundSts.Status.ReadyReplicas
    if err := r.Status().Update(ctx, myApp); err != nil {
        return ctrl.Result{}, err
    }

    return ctrl.Result{}, nil
}

Преимущества использования операторов

• Автоматизация ручных операций: Заменяет скрипты и ручные вмешательства (backup, восстановление после сбоя, обновление схемы БД).
• Упакованное знание предметной области: Экспертиза по управлению конкретным ПО (например, PostgreSQL, Elasticsearch, Prometheus) становится частью кластера.
• Декларативное управление сложными приложениями: Пользователь лишь задает желаемое состояние в CR (spec.highAvailability: true, spec.backupSchedule: "0 2 * * *"), а оператор сам развертывает необходимую инфраструктуру.
• Самовосстановление (Self-healing): Оператор постоянно следит за здоровьем приложения и автоматически возвращает его в желаемое состояние.

Таким образом, Kubernetes-оператор — это реализация принципа "программируемого человеческого оператора", который, используя Kubernetes API как "платформу управления", обеспечивает полный жизненный цикл сложного приложения в кластере.