Kubernetes наказывает за неточность: забыл resources.requests — под выселили, ошибся в livenessProbe — контейнер в бесконечном рестарте, скопировал чарт из туториала — получил CrashLoopBackOff на проде. LLM здесь не заменит kubectl, но снимает рутину: разбирает вывод describe, объясняет странный статус, собирает черновик values.yaml и подсказывает, каких полей не хватает.
Ниже — 12 промтов, которые я гоняю в работе. Каждый — с реальным примером и пояснением, для какой задачи он годится. Формулировки проверены: модель отвечает по делу, а не пересказывает документацию.
Важно понимать границу: LLM не видит ваш кластер. Всё, что она знает, — то, что вы вставили в промт. Поэтому половина приёмов — про то, как правильно скормить ей контекст: вывод команды, манифест, лог. Если контекст неполный, ответ будет уверенным и неверным.
kubectl describe pod и последних строк лога. Модель начнёт гадать про образ и сеть, хотя причина в квоте namespace или в несуществующем Secret.
Как пользоваться подборкой
Промты разбиты на четыре блока: диагностика, ресурсы и надёжность, Helm и деплой, сеть и service mesh. Копируйте целиком, подставляйте свои значения в квадратных скобках. Если ответ получился общим — почти всегда не хватает входных данных, а не «плохого промта».
| Блок | Промты | Типовая задача |
|---|---|---|
| Диагностика | 1–4 | Разбор статусов и логов |
| Ресурсы и надёжность | 5–7 | requests/limits, probes, HPA |
| Helm и деплой | 8–10 | Чарты, values, rollout |
| Сеть и mesh | 11–12 | Service, Ingress, Istio |
Диагностика: превращаем вывод kubectl в план
Промт 1. Разбор CrashLoopBackOff
Ты SRE. Ниже вывод `kubectl describe pod` и последние 40 строк лога.
Определи наиболее вероятную причину CrashLoopBackOff, отсортируй
гипотезы по вероятности и для каждой дай одну команду проверки.
Не предлагай перезапускать под, пока причина не установлена.
Вывод describe:
[вставить]
Лог:
[вставить]
Пример: под с приложением на Go падал каждые 20 секунд. Модель по Last State: Terminated, Reason: OOMKilled и Exit Code: 137 сразу указала на лимит памяти, а не на ошибку в коде. Дальше — команда kubectl top pod для проверки фактического потребления.
Почему работает: Exit Code 137 — это 128 + 9 (SIGKILL), классический признак OOM. Модель, которой дали код выхода, не гадает про конфиги.
Промт 2. Pending: почему под не планируется
Под в статусе Pending. Вот вывод `kubectl describe pod` (секция Events)
и `kubectl describe node [имя]`. Найди, какой планировщик-фильтр
отклонил под (ресурсы, taints, affinity, PVC), и предложи минимальное
изменение манифеста. Покажи diff, а не весь YAML заново.
[вставить]
Pending почти всегда означает, что под не прошёл один из фильтров планировщика. Секция Events в describe прямо называет причину: Insufficient cpu, node(s) had untolerated taint, pod has unbound immediate PersistentVolumeClaims. Промт заставляет модель привязать вывод к конкретному фильтру, а не перечислять всё подряд.
replicas: 0 или селектор не совпадает с метками шаблона. Модель это заметит, только если вы вставите и манифест Deployment.
Промт 3. ImagePullBackOff и приватные реестры
Образ не пуллится. Вот Events из describe и вывод
`kubectl get secret [имя] -o yaml` без полей data.
Объясни, что именно ломается: имя образа, тег, imagePullSecrets,
права service account или сетевой доступ к реестру.
Дай пошаговый чек-лист из 4 пунктов максимум.
ImagePullBackOff часто путают с ошибкой авторизации. Признак разницы: manifest unknown — проблема в теге или имени, unauthorized/403 — в credentials. Промт с явным запретом на длинные чек-листы отсекает воду.
Промт 4. Чтение логов без шума
Вот 200 строк лога приложения. Сгруппируй сообщения по типу,
выдели первую ошибку по времени и цепочку событий после неё.
Не пересказывай каждую строку — только то, что ведёт к сбою.
Лог:
[вставить]
Приём работает на логах любого размера: модель ищет паттерн, а не читает построчно. Экономит время, когда нужно понять, что случилось до всплеска ошибок.
Ресурсы и надёжность: где LLM реально экономит часы
Промт 5. Подбор requests и limits
Приложение [язык, фреймворк] обслуживает [N] rps, средний ответ [X] мс.
Фактическое потребление по `kubectl top`: [CPU] и [память] на под.
Предложи requests и limits с обоснованием, объясни риск OOMKill
и риск CPU throttling. Покажи YAML-фрагмент resources.
Правило, которое модель обычно воспроизводит корректно: requests — для планировщика (гарантия), limits — потолок. По памяти лимит выше запроса в 1,5–2 раза даёт запас, но не спасает от утечек. По CPU лимит жёсткий и приводит к throttling — многие команды ставят только requests, а лимит CPU не задают вовсе.
Это и есть trade-off: без CPU-лимита под может «съесть» узел при всплеске, с лимитом — получить throttling в пике. Промт заставляет модель озвучить оба риска, а не выбрать один молча.
Промт 6. Настройка probes
Сервис стартует [T] секунд, healthcheck на /healthz.
Предложи startupProbe, readinessProbe и livenessProbe:
пути, пороги, periodSeconds, failureThreshold.
Объясни, почему livenessProbe не должна зависеть от внешней БД.
Классическая ловушка: livenessProbe, которая ходит в базу. База моргнула — Kubernetes начал рестартить здоровые поды и устроил каскад. readinessProbe убирает под из балансировки, livenessProbe перезапускает контейнер — это разные инструменты, и промт фиксирует разницу.
Промт 7. HPA и когда он не спасёт
Есть Deployment с HPA по CPU. Опиши, при каких условиях HPA
не поможет (I/O-bound нагрузка, очередь, память),
и предложи альтернативную метрику. Дай фрагмент HPA-манифеста.
HPA по CPU плохо работает для сервисов, упирающихся в диск или в очередь сообщений: CPU низкий, а latency растёт. Модель подскажет метрику по памяти или внешнюю через external.metrics, но напомнит, что для кастомных метрик нужен адаптер.
Helm и деплой: от пустого чарта до безопасного rollout
Промт 8. Генерация Helm-чарта
Сгенерируй структуру Helm-чарта для stateless-сервиса:
Deployment, Service, Ingress, HPA, ServiceAccount.
Все параметры — через values.yaml с комментариями.
Не хардкодь namespace и image tag, используй .Values и .Chart.AppVersion.
Модель выдаёт дерево файлов и содержимое шаблонов. Проверять нужно три вещи: корректность helm template (шаблоны с include/toYaml ломаются чаще всего), отсутствие захардкоженных значений и совпадение селекторов Deployment и Service.
Промт 9. Ревью values.yaml перед деплоем
Проверь values.yaml на типичные ошибки Helm-деплоя:
несоответствие типов, отсутствие дефолтов, случайный override
прод-значений, отсутствие imagePullSecrets. Дай список замечаний
с приоритетом и предложи исправленный фрагмент.
[вставить values.yaml]
Самый частый дефект — пустая строка вместо числа или null вместо списка: Helm молча подставит дефолт из шаблона, и под уедет с неверным портом. Промт ловит это до helm upgrade, а не после.
Промт 10. Стратегия rollout и откат
Нужен безопасный rollout для сервиса с [N] репликами.
Предложи strategy (RollingUpdate с maxSurge/maxUnavailable)
и значения, при которых не будет простоя. Опиши,
как откатиться через `helm rollback` и что проверить после.
maxUnavailable: 0 и maxSurge: 1 дают деплой без потери ёмкости, но требуют свободных ресурсов на узлах. Если кластер плотный — поды повиснут в Pending, и это заметят по метрике доступных реплик, а не по ошибке в CI.
helm upgrade всегда гоняйте helm diff upgrade (плагин) или helm template с прод-values. LLM покажет, что изменится, но рендер чарта — единственный надёжный источник правды.
Сеть и service mesh: где диагностика сложнее всего
Промт 11. Service не доходит до подов
Service не отвечает. Вот YAML Service, YAML Deployment и вывод
`kubectl get endpoints [имя]`. Найди причину: селектор,
порты targetPort/port, readiness подов. Дай diff исправления.
Если kubectl get endpoints показывает пустой список — Service не находит поды по селектору. Если endpoints есть, а трафик не идёт — смотрите targetPort и readiness. Промт с выводом endpoints отсекает половину гипотез сразу.
Промт 12. Отладка Istio и mTLS
Запрос между сервисами падает в Istio. Вот вывод
`istioctl analyze` и `kubectl get peerauthentication,destinationrule -A`.
Проверь конфликт mTLS (STRICT vs PERMISSIVE), ошибки в VirtualService
и DestinationRule. Предложи минимальное исправление.
Типичный режим отказа: включили PeerAuthentication в STRICT, а часть сервисов без sidecar — трафик между ними рвётся с connection reset. istioctl analyze это подсвечивает, но не всегда объясняет связь с режимом mTLS — модель связывает вывод с конфигом.
Как не получить уверенно неверный ответ
Три правила, которые я выработал на практике.
- Всегда давайте вывод команды, а не пересказ. «Под падает» — бесполезно.
kubectl describe+ лог — полезно. - Просите diff, а не полный YAML. Полный манифест модель перепишет с изменениями, которые вы не заметите при ревью.
- Проверяйте версии. Поля API меняются: то, что работало в старом чарте, в новой версии кластера может быть deprecated. Спрашивайте у модели, для какой версии Kubernetes валиден манифест, и сверяйте с документацией.
LLM хорошо работает как второй глаз: объясняет статус, предлагает структуру, ловит пропущенные поля. Решение и ответственность за деплой остаются за вами — helm diff, kubectl apply --dry-run=server и staging-кластер никто не отменял.
Если хотите глубже разобраться, как встраивать такие промты в ежедневную работу, — посмотрите программу по автоматизации собственной работы с ИИ. А если ваш фронт работы — интерфейсы и тексты, пригодятся промты для UX-копирайтинга и accessibility.
Начните с одного промта — разбора текущего инцидента. Через неделю вы заметите, что вставляете вывод describe в модель раньше, чем открываете дашборд.