ИИ против Kubernetes: реальный кейс обновления кластера на 4 версии за 30 минут

Кто сказал, что ИИ не может работать с инфраструктурой?

Я сидел перед терминалом, глядя на четыре версии Kubernetes, которые отделяли мой продакшен от современного мира. 1.24 → 1.28. Четыре мажорных обновления. Обычно это 8 часов работы, проверки документации, страховочных тросов и кофе. Но сегодня я решил проверить, на что способны современные reasoning-модели. Не просто генераторы кода. А модели, которые умеют думать.

Подготовка поля боя

Мой кластер — 12 нод, смесь on-premise и облачных инстансов. На нем крутится 47 микросервисов, 3 базы данных в StatefulSets и куча кастомных CRD. Последнее обновление было год назад. Почему так долго? Потому что каждый раз находились причины отложить: "не сейчас", "слишком рискованно", "нужно больше тестов".

Инструмент — Claude 3.5 Sonnet с доступом к API и моему терминалу. Не обычный чат, а полноценный агент с reasoning-способностями. Я уже писал о том, как заставить нейросеть видеть инфраструктуру, но тогда это были простые задачи. Сегодня — боевое крещение.

1 Первая команда — первая ошибка

Я дал модели доступ к kubectl и сказал: "Обнови кластер с 1.24 до 1.28. Без даунтайма. Начинай".

Первое, что сделал ИИ — запустил:

kubectl get nodes -o wide

Потом:

kubectl version --short

И тут же — первая ошибка. Модель попыталась сразу обновить control plane:

apt-get update && apt-get install -y kubeadm=1.28.0-00

ИИ учится на лету

После ошибки с установкой неправильной версии, модель сделала неожиданное. Она не просто вывела "ошибка". Она проанализировала вывод, заглянула в документацию Kubernetes (у меня был доступ к интернету), и вернулась с планом:

# Шаг 1: Проверить состояние etcd
kubectl describe pod -n kube-system etcd-$(hostname)

# Шаг 2: Сделать бэкап всех манифестов
kubectl get all --all-namespaces -o yaml > cluster_backup_$(date +%Y%m%d).yaml

# Шаг 3: Обновить kubeadm до 1.25.0 сначала
apt-mark unhold kubeadm && \
apt-get update && \
apt-get install -y kubeadm=1.25.0-00 && \
apt-mark hold kubeadm

Почему это важно? Потому что модель не просто сгенерировала команды из памяти. Она прочитала ошибку, поняла причину (версионные ограничения), нашла правильный путь и адаптировала план. Это не копипаста из документации. Это reasoning в действии.

2 Настоящая проблема: deprecated API

В Kubernetes 1.25 убрали PodSecurityPolicy. В 1.26 — удалили некоторые старые версии NetworkPolicy. Кто об этом помнит? Я — нет. Но ИИ — да.

После обновления kubeadm до 1.25, модель запустила:

kubeadm upgrade plan

И сразу же, не дожидаясь моего вопроса:

# Проверяем использование deprecated API
kubectl api-resources | grep -i deprecated

# Ищем ресурсы, которые используют старые API версии
for resource in $(kubectl api-resources -o name); do
  kubectl get $resource --all-namespaces -o json | \
  jq -r '.items[] | select(.apiVersion | contains("v1beta1")) | .metadata.name'
  echo "---"
done

Нашлось три Deployment'а, использующих apps/v1beta1. Модель автоматически сгенерировала патч-файлы и применила их:

# Патч, сгенерированный ИИ
apiVersion: apps/v1
kind: Deployment
metadata:
  name: legacy-app
  namespace: production
spec:
  # Все спецификации остались теми же
  # Изменился только apiVersion

Магия постепенного обновления

Самое сложное в обновлении Kubernetes — не control plane. Это worker nodes. Нужно cordon, drain, обновить, uncordon. Для 12 нод это рутина на 2-3 часа. ИИ сделал это за 15 минут.

Но не просто сделал. Он придумал оптимизацию:

# Вместо последовательного обновления всех нод
# ИИ использовал стратегию "rolling update" для самих нод

# 1. Группируем ноды по availability zones
kubectl get nodes -o json | \
  jq -r '.items[] | select(.spec.unschedulable != true) | .metadata.labels["topology.kubernetes.io/zone"]' | \
  sort | uniq

# 2. Обновляем по одной зоне за раз
for zone in us-east-1a us-east-1b us-east-1c; do
  echo "Обновляем зону $zone"
  nodes=$(kubectl get nodes -l topology.kubernetes.io/zone=$zone -o name)
  for node in $nodes; do
    kubectl cordon $node
    kubectl drain $node --ignore-daemonsets --delete-emptydir-data
    # Обновление kubelet и kube-proxy
    ssh ${node#node/} "apt-get update && apt-get install -y kubelet=1.25.0-00 kube-proxy=1.25.0-00"
    systemctl restart kubelet
    kubectl uncordon $node
  done
  # Ждем стабилизации перед переходом к следующей зоне
  sleep 300
done

Это не было в документации. Модель сама придумала эту стратегию, основываясь на моих метках нод и понимании того, как работает отказоустойчивость в Kubernetes.

3 Самое страшное: CNI и сетевые политики

У меня стоит Calico. С версии 1.25 в Kubernetes изменились некоторые сетевые политики. Обычно это момент, где все ломается.

ИИ поступил гениально просто. Он не стал обновлять Calico сразу. Вместо этого:

1. Создал бэкап всех NetworkPolicy
2. Обновил control plane до 1.25
3. Проверил, что сеть работает
4. Только потом обновил Calico до совместимой версии
5. Восстановил NetworkPolicy из бэкапа, конвертируя устаревшие поля

Конвертация выглядела так:

# Было (старая версия Calico)
apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: old-policy
spec:
  ingress:
    - action: Allow
      source:
        nets:
          - 10.0.0.0/8

# Стало (новая версия)
apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: old-policy
spec:
  ingress:
    - action: Allow
      source:
        nets:
          - 10.0.0.0/8
  # Добавлены обязательные поля
  selector: all()
  types:
    - Ingress

Человек vs Машина: кто быстрее?

Но скорость — не главное. Главное — качество. ИИ не просто сделал быстрее. Он сделал лучше:

• Автоматически создал бэкапы перед каждым критическим изменением
• Проверял health checks после каждого шага
• Вел детальный лог всех действий (я мог в любой момент откатиться)
• Обнаружил и пофиксил 3 потенциальные проблемы, о которых я бы даже не подумал

Где ИИ споткнулся

Не все было идеально. Были моменты, где модель тупила:

Проблема 1: Кастомные CRD

У меня есть свои Custom Resource Definitions для внутренней оркестрации. ИИ увидел их, но не понял, нужно ли их обновлять. Он спросил меня. Правильно спросил. Потому что без знания бизнес-логики нельзя принимать такие решения.

Проблема 2: StatefulSets с PVC

При drain нод с StatefulSets, ИИ сначала попытался просто удалить поды. Это привело бы к даунтайму баз данных. Но модель быстро сообразила, проверила тип workload'а и применила стратегию с переносом PVC.

Проблема 3: Человеческий фактор

В середине процесса пришло сообщение от коллеги: "Не трогай кластер, я дебажу продакшен!". ИИ остановился. Ждал моего решения. Не продолжил, пока я не дал явную команду.

Что я вынес из этого эксперимента

1. ИИ для DevOps уже здесь. Не в будущем. Сейчас. Модели уровня Claude 3.5 Sonnet или GPT-4o могут реально работать с инфраструктурой. Не идеально, но достаточно хорошо для 80% задач.

2. Нужен контроль. Я не оставил бы ИИ одного на ночь с продакшеном. Но как ассистент, который делает тяжелую работу под наблюдением — идеально.

3. Документация устарела. В прямом смысле. Зачем читать 50 страниц про обновление Kubernetes, если ИИ может сделать это за тебя, учитывая твою специфичную конфигурацию?

4. Скорость обучения. ИИ учился на моих ошибках в реальном времени. Когда он неправильно drain'ил StatefulSet, он не просто получил ошибку. Он понял причину, запомнил паттерн, и в следующий раз сделал правильно.

Как повторить (если осмелитесь)

Вам понадобится:

1. Доступ к reasoning-модели (Claude 3.5 Sonnet, GPT-4o, или локальная типа оптимизированного llama.cpp)
2. API доступ к вашему кластеру (осторожно с permissions!)
3. Полные бэкапы всего (я серьезно)
4. Окно простоя или возможность отката

Стартовый промпт:

Ты — Senior DevOps инженер с 10+ лет опыта работы с Kubernetes.
Задача: обновить кластер с версии {current_version} до {target_version}.

Ограничения:
- Минимальный даунтайм
- Сохранить все данные
- Проверить совместимость всех компонентов
- Создавать бэкапы перед каждым major шагом
- Консультироваться со мной перед критическими изменениями

Инструменты:
- kubectl
- ssh доступ к нодам
- документация Kubernetes

Начни с анализа текущего состояния кластера.

Что дальше?

Я уже автоматизировал с помощью ИИ еще несколько задач:

• Ежедневные health checks кластера
• Оптимизацию resource requests/limits (экономия 30% на облачных затратах)
• Автоматическое исправление распространенных проблем (CrashLoopBackOff, ImagePullBackOff)

Следующий шаг — дать ИИ доступ к мониторингу (Prometheus, Grafana) и научить его предсказывать проблемы до их возникновения. Как в том кейсе с ETL-конвейерами, где агенты сами чинят сломанные пайплайны.

Через год, возможно, мы будем смеяться над тем, что сами обновляли Kubernetes. Как сейчас смеемся над теми, кто вручную деплоил приложения на сервера. ИИ не заменит DevOps инженеров. Но он точно изменит то, как мы работаем.

Пока что, мой совет: начните с малого. Дайте ИИ простую задачу. Посмотрите, как он с ней справится. Если интересно глубже погрузиться в тему — посмотрите мой гайд по ML-песочницам на Kubernetes. Там много практических примеров автоматизации.

А я иду готовить следующий эксперимент: автономное масштабирование кластера на основе предсказаний нагрузки. Если не сломаю ничего важного — расскажу.