Кратко о сути эксперимента

Мы проверили, способен ли ИИ участвовать в реальной инфраструктурной операции повышенного риска — обновлении Kubernetes-кластера сразу через несколько minor-версий.

Речь не про «сгенерировать YAML» или «написать Helm-чарт», а про полноценную операцию:

• несколько узлов,

• control-plane,

• worker-ноды,

• системные аддоны,

• ошибки по ходу,

• необходимость принимать решения по состоянию системы.

Результат — положительный, но с важными оговорками.

Зачем вообще это делать

Цель была не в том, чтобы «доказать, что ИИ м��жет всё».

Цели были инженерные:

1. Проверить, может ли ИИ удерживать сложное состояние системы.

2. Понять, как он ведёт себя при цепочке апгрейдов, а не одном шаге.

3. Посмотреть, что происходит, когда:

   • обновление идёт не по плану,

   • появляются конфликтующие состояния,

   • требуется ручное вмешательство.

4. Проверить, может ли ИИ работать сразу с несколькими серверами, не теряя контекста.

Важный дисклеймер

⚠️ Так нельзя обновлять production-кластер. Через 4 версии мажорных

Эксперимент проводился на stage-кластере:

• он почти не использовался,

• его планировали снести и развернуть заново,

• решили использовать как полигон для проверки возможностей ИИ.

Исходные данные

• Kubernetes: v1.29.10

• 1 × control-plane

• 5 × worker-нод

• ОС: Debian 12

• containerd: 1.7.22

Все ноды — Ready.

План обновления

Kubernetes не позволяет перескакивать через minor-версии, поэтому путь выглядел так:

1.29 → 1.30 → 1.31 → 1.32 → 1.33

Фактически это четыре полных цикла:

1. обновление control-plane,

2. обновление worker-нод по одной,

3. проверка системных аддонов,

4. валидация состояния кластера.

Какие модели использовались

• GPT-5.2 — основной рабочий инструмент

• Claude Sonnet 4.5 — для тестов

• Qwen-Max Preview — для тестов

Все модели в итоге справились, но:

• Qwen хуже всего работал с инструментами и длинными цепочками команд

• Sonnet — стабильнее

• GPT-5.2 лучше всего удерживал контекст и состояние системы

Как был устроен процесс

Обновление не выполнялось в одном контексте.

Использовались:

• несколько контекстов,

• саммаризация предыдущих шагов,

• передача состояния между контекстами.

Последний контекст специально прошёл два minor-апгрейда подряд, чтобы проверить, потеряет ли ИИ понимание текущего состояния кластера.

Не потерял, но периодически требовались:

• уточняющие вопросы,

• ручное подтверждение,

• действия оператора.
  

  

Работа с несколькими серверами (коротко)

ИИ одновременно:

• подключался по SSH к control-plane и worker-нодам,

• выполнял команды,

• анализировал вывод,

• сверял состояние кластера целиком.

Это важно: он работал не с одной нодой, а с системой как с целым объектом.

Реальная проблема по ходу обновления

После kubeadm upgrade apply:

• kube-apiserver обновился корректно

• kube-scheduler и kube-controller-manager остались старой версии

• при попытке перезапуска возникала ошибка:

bind: address already in use

Причина оказалась классической:

• старые static-pods ещё держали порты,

• новые не могли стартовать.

Решение:

• освобождение портов,

• пересоздание static-pod манифестов,

• перезапуск kubelet.

ИИ:

• корректно локализовал проблему,

• объяснил причину,

• предложил рабоч��й план действий.
  

  

Но инициатива и контроль оставались за инженером.

Финальный результат

• Kubernetes: v1.33.7

• Все ноды: Ready

• Control-plane: v1.33.7

• CoreDNS: v1.12.0

• kube-proxy: v1.33.7

• Пользовательские workload’ы — все поднялись

Вся операция заняла около 30 минут чистого времени.

1️⃣ ИИ — не автономен

Без человека он может:

• выполнить лишние действия,

• остановиться в неопределённом состоянии,

• принять рискованное решение.

Роль инженера — постоянный контроль, как у пилота в самолёте.

2️⃣ Нужен аналог terraform.tfstate

Для инфраструктурных операций ИИ критически важно видеть состояние системы:

• что уже обновлено,

• что находится в процессе,

• какие действия допустимы,

• какие запрещены.

Без явного состояния масштабирование такого подхода невозможно. И что самое сложное - стейт не должен быть подробным. Надо найти баланс - минимально достаточный для повторения. (и еще понятный человеку)

3️⃣ Контексты важнее модели

Один длинный контекст — плохая идея.

Нужны:

• передача состояния между контекстами,

• саммаризация шагов,

• контроль переходов между фазами.

Это важнее, чем «ещё больше токенов».

4️⃣ Подходящие модели — критичны

Не каждая модель способна:

• удерживать сложное состояние,

• работать с инструментами,

• принимать технические решения.

Для таких задач нужны сильные reasoning-модели, а не просто «чат-бот».