Kubernetes Operator на Python: пишем AI Gateway Operator для LLM-моделей

В 2026 году Kubernetes окончательно превратился из "оркестратора контейнеров" в полноценную операционную систему для датацентра. Если в 2020-м все радовались автоматическому рестарту Pod'ов, то сейчас инфраструктурщики обсуждают GPU scheduling, inference gateway, multi-cluster federation и стоимость токена у LLM-моделей так, будто это курс нефти Brent.

И вот здесь появляется Kubernetes Operator.

Не просто очередной контроллер. Не просто "скрипт в контейнере". А полноценный способ научить Kubernetes понимать ваш бизнес-домен.

В этой статье мы напишем настоящий Kubernetes Operator на Python для одной из самых хайповых тем 2026 года - управления AI Gateway для больших языковых моделей.

Да-да. Будем делать оператор, который автоматически:

создает inference endpoint
подключает GPU
масштабирует модели
обновляет routing
следит за latency
выключает дорогие модели ночью, что бы бухгалтерию удар не хватил, а то кто зарплату будет выплачивать?

И самое приятное - все это на Python. Потому что Go любят все, но иногда хочется писать оператор без ощущения, что ты собираешь двигатель от вертолета ключом на 10.

Почему Kubernetes Operator вообще стал главным паттерном инфраструктуры

Раньше инфраструктура выглядела так:

kubectl apply -f deployment.yaml

Чуть позже:

helm install

Ну и потом:

terraform apply

А потом все поняли страшную вещь.

Инфраструктура перестала быть статичной.

Теперь кластеру нужно:

реагировать на события
принимать решения
автоматически чинить сервисы
управлять сложными зависимостями
учитывать стоимость GPU
мигрировать нагрузки
следить за SLA

И обычные YAML-файлы тут уже не помогают.

Operator - это способ встроить "мозг" прямо внутрь Kubernetes.

По сути Kubernetes Operator - это:

контроллер
бизнес-логика
автоматизация
реакция на события
цикл согласования

То есть система постоянно приводит реальное состояние к желаемому. Именно поэтому почти все современные платформы используют operators:

Red Hat OpenShift
Elastic Elastic Cloud
MongoDB Atlas
NVIDIA GPU Operator
Grafana Labs Loki Operator
DataStax Cassandra Operator

В 2026 году Operator - это уже не "продвинутый Kubernetes". Это стандарт инфраструктурной инженерии.

Почему Python для Operator - это уже нормально

Раньше все говорили:

Operator надо писать только на Go.

И это было логично:

Kubernetes написан на Go
client-go очень мощный
controller-runtime великолепен
ecosystem огромная

Но потом появился мегабум и хайп на AI. И внезапно выяснилось:

ML-инженеры живут в Python
AI SDK живут в Python
observability AI tooling живет в Python
inference API живут в Python

А еще оказалось, что писать цикл согласования на Python в 10 раз быстрее.

Особенно для:

AI infrastructure
DataOps
MLOps
GPU orchestration
AI gateways
vector database automation

И тут начал набирать популярность фреймворк Kopf.

Что такое Kopf

Kopf - Kubernetes Operator Framework на Python. (Kopf Github)

Очень приятная штука. Он позволяет писать operator почти как обычный Python backend.

Например:

@kopf.on.create('ai.platform.io', 'v1', 'aigateways')
def create_fn(spec, name, namespace, logger, **kwargs):
    logger.info(f"Creating AI Gateway {name}")

И все.

Без:

тонны boilerplate
controller-runtime магии
reconcile.Result
DeepCopyObject
client.ObjectKey
admission webhook страданий

Иногда после Go Operator'ов Kopf ощущается как отпуск в Провансе после аварии в production Ceph-кластере.

Что мы будем делать

Наш оператор будет управлять AI Gateway. Представим современную инфраструктуру LLM:

Users
  ↓
AI Gateway
  ↓
Routing Layer
  ↓
LLM Models
  ├── DeepSeek
  ├── Llama
  ├── Mistral
  ├── Qwen
  └── OpenAI-compatible API

Оператор будет:

создавать inference deployment
подключать GPU node selector
создавать Service
создавать HPA
управлять ingress
переключать модели
делать autoscaling

Архитектура

Вот как это будет выглядеть:

Custom Resource
      ↓
AI Gateway Operator
      ↓
Creates:
- Deployment
- Service
- HPA
- ConfigMap
- Ingress

Установка окружения

Создаем структуру проекта:

mkdir ai-gateway-operator
cd ai-gateway-operator

Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["kopf", "run", "--all-namespaces", "operator.py"]

requirements.txt

kopf
kubernetes
aiohttp
pyyaml
prometheus-client

Установка CRD

Custom Resource Definition - это способ объяснить Kubernetes новый тип ресурса.

Например:

apiVersion: ai.platform.io/v1
kind: AIGateway

Kubernetes из коробки такого не знает.

Создаем CRD.

crd.yaml

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: aigateways.ai.platform.io

spec:
  group: ai.platform.io

  names:
    kind: AIGateway
    plural: aigateways
    singular: aigateway

  scope: Namespaced

  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                model:
                  type: string
                replicas:
                  type: integer
                gpu:
                  type: boolean
                image:
                  type: string

Применяем:

kubectl apply -f crd.yaml

Пишем оператор

Теперь начинается магия.

operator.py

import kopf
import kubernetes
from kubernetes import client, config

config.load_incluster_config()

apps = client.AppsV1Api()
core = client.CoreV1Api()

@kopf.on.create('ai.platform.io', 'v1', 'aigateways')
def create_ai_gateway(spec, name, namespace, logger, **kwargs):

    image = spec.get("image")
    replicas = spec.get("replicas", 1)
    gpu = spec.get("gpu", False)

    deployment = {
        "apiVersion": "apps/v1",
        "kind": "Deployment",
        "metadata": {
            "name": name
        },
        "spec": {
            "replicas": replicas,
            "selector": {
                "matchLabels": {
                    "app": name
                }
            },
            "template": {
                "metadata": {
                    "labels": {
                        "app": name
                    }
                },
                "spec": {
                    "containers": [
                        {
                            "name": "gateway",
                            "image": image,
                            "ports": [
                                {
                                    "containerPort": 8080
                                }
                            ]
                        }
                    ]
                }
            }
        }
    }

    if gpu:
        deployment["spec"]["template"]["spec"]["nodeSelector"] = {
            "gpu": "true"
        }

        deployment["spec"]["template"]["spec"]["containers"][0]["resources"] = {
            "limits": {
                "nvidia.com/gpu": 1
            }
        }

    apps.create_namespaced_deployment(
        namespace=namespace,
        body=deployment
    )

    logger.info(f"AI Gateway {name} created")

И вот это уже полноценный Kubernetes Operator.

Да, настолько все просто.

Создаем Service автоматически

Добавляем в оператор:

service = {
    "apiVersion": "v1",
    "kind": "Service",
    "metadata": {
        "name": name
    },
    "spec": {
        "selector": {
            "app": name
        },
        "ports": [
            {
                "port": 80,
                "targetPort": 8080
            }
        ]
    }
}

core.create_namespaced_service(
    namespace=namespace,
    body=service
)

Создаем Custom Resource

Теперь пользователь кластера может написать:

apiVersion: ai.platform.io/v1
kind: AIGateway

metadata:
  name: deepseek-gateway

spec:
  image: ghcr.io/company/ai-gateway:latest
  replicas: 2
  gpu: true
  model: deepseek-r1

И оператор автоматически:

создаст deployment
создаст service
подключит GPU
выставит replicas

То есть Kubernetes начинает понимать AI-инфраструктуру как нативную сущность. И вот тут приходит очень странное ощущение. Ты больше не "деплоишь контейнеры". Ты создаешь платформу.

Добавляем autoscaling

AI без autoscaling - это билет в финансовую катастрофу. GPU стоят как подержанная машина.

Поэтому делаем HPA.

Создание HPA

autoscaling = client.AutoscalingV2Api()

hpa = {
    "apiVersion": "autoscaling/v2",
    "kind": "HorizontalPodAutoscaler",
    "metadata": {
        "name": name
    },
    "spec": {
        "scaleTargetRef": {
            "apiVersion": "apps/v1",
            "kind": "Deployment",
            "name": name
        },
        "minReplicas": 1,
        "maxReplicas": 10,
        "metrics": [
            {
                "type": "Resource",
                "resource": {
                    "name": "cpu",
                    "target": {
                        "type": "Utilization",
                        "averageUtilization": 70
                    }
                }
            }
        ]
    }
}

autoscaling.create_namespaced_horizontal_pod_autoscaler(
    namespace=namespace,
    body=hpa
)

А теперь самое модное - AI-aware scaling

Вот где начинается настоящий 2026 год. Оператор может масштабировать не CPU.

А:

queue depth
token latency
prompt throughput
GPU memory pressure
tokens/sec

Например:

if queue_size > 100:
    scale_to = 10

Или:

if gpu_memory > 90:
    move_model_to_another_node()

Вот это уже современный infrastructure engineering.

Добавляем reconciliation loop

Главная идея operator - не просто создать объект. А постоянно следить за состоянием.

Например:

@kopf.timer('ai.platform.io', 'v1', 'aigateways', interval=30)
def monitor_ai_gateway(spec, name, namespace, logger, **kwargs):

    logger.info(f"Checking gateway {name}")

    deployments = apps.list_namespaced_deployment(namespace)

    for deployment in deployments.items:
        if deployment.metadata.name == name:

            ready = deployment.status.ready_replicas

            if ready == 0:
                logger.warning("No ready replicas!")

Добавляем обновление модели

Самая модная тема 2026 года - hot model swapping.

То есть:

модель обновляется
inference не падает
traffic переключается постепенно

Добавляем handler:

@kopf.on.update('ai.platform.io', 'v1', 'aigateways')
def update_model(spec, old, new, name, namespace, logger, **kwargs):

    old_model = old.get("model")
    new_model = new.get("model")

    if old_model != new_model:
        logger.info(f"Switching model {old_model} -> {new_model}")

Добавляем Prometheus метрики

Инфраструктурщик без метрик - это археолог без кисточки.

metrics.py

from prometheus_client import Counter

gateway_requests = Counter(
    'gateway_requests_total',
    'Total requests'
)

Production deployment

Теперь собираем контейнер:

docker build -t registry.local/ai-operator:latest .

Публикуем:

docker push registry.local/ai-operator:latest

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-operator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ai-operator
  template:
    metadata:
      labels:
        app: ai-operator
    spec:
      serviceAccountName: ai-operator
      containers:
        - name: operator
          image: registry.local/ai-operator:latest

RBAC

И вот здесь многие начинающие operator-разработчики ловят экзистенциальный кризис от Kubernetes, а проще - бомбалейло. Потому что operator без RBAC работает примерно как DevOps без доступа в production. То есть чисто философски интересно, но бесполезно.

role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ai-operator

rules:
  - apiGroups: [""]
    resources:
      - services
      - pods
    verbs:
      - "*"

  - apiGroups: ["apps"]
    resources:
      - deployments
    verbs:
      - "*"

  - apiGroups: ["ai.platform.io"]
    resources:
      - aigateways
    verbs:
      - "*"

Что получится в итоге

В итоге пользователь сможет создавать AI Gateway буквально одной YAML-манифестацией:

apiVersion: ai.platform.io/v1
kind: AIGateway

metadata:
  name: qwen-production

spec:
  image: ghcr.io/platform/qwen-gateway:latest
  replicas: 4
  gpu: true
  model: qwen-3-235b

И вся инфраструктура поднимется автоматически. Вот это и есть настоящий Platform Engineering.

Почему Operator'ы стали новой Terraform

Очень интересный тренд последних лет. Terraform отлично создает инфраструктуру.

Но Operator:

живет внутри Kubernetes
реагирует на события
автоматически исправляет проблемы
умеет reconciliation
знает runtime state

То есть Terraform создает. А Operator управляет жизнью системы. Именно поэтому в 2026 году почти каждая серьезная платформа имеет:

Terraform для provisioning
Kubernetes Operator для lifecycle management

А стоит ли вообще писать Operator на Python?

Да. Но есть нюансы.

Когда Python Operator - отличная идея

AI infrastructure
MLOps
внутренние платформы
автоматизация
GPU orchestration
data pipelines
интеграции с AI SDK

Когда лучше Go

ultra high scale
сложные CRD
admission webhook
production-grade ecosystem operator
open source CNCF project

Главный инженерный вывод

Самое интересное в Operator'ах даже не автоматизация. А то, что Kubernetes начинает понимать предметную область бизнеса.

Например:

kind: PostgreSQLCluster

или:

kind: KafkaTopic

ну или:

kind: AIGateway

Кластер начинает мыслить бизнес-сущностями. И вот это уже не "оркестратор контейнеров". Это распределенная операционная система датацентра.

С очень нервным DevOps-инженером где-то рядом, который все еще боится делать kubectl delete pod в пятницу вечером.

Почему Kubernetes Operator вообще стал главным паттерном инфраструктуры

Почему Python для Operator - это уже нормально

Что такое Kopf

Что мы будем делать

Архитектура

Установка окружения

Dockerfile

requirements.txt

Установка CRD

crd.yaml

Пишем оператор

operator.py

Создаем Service автоматически

Создаем Custom Resource

Добавляем autoscaling

Создание HPA

А теперь самое модное - AI-aware scaling

Добавляем reconciliation loop

Добавляем обновление модели

Добавляем Prometheus метрики

metrics.py

Production deployment

deployment.yaml

RBAC

role.yaml

Что получится в итоге

Почему Operator'ы стали новой Terraform

А стоит ли вообще писать Operator на Python?

Когда Python Operator - отличная идея

Когда лучше Go

Главный инженерный вывод

Оцените статью