Kubernetes ближе к Linux: много компонентов, контроллеров, CRD, операторов и внешних проектов собираются в живую экосистему. Сила там в открытом расширении и конкуренции подходов. Torque я пытаюсь делать ближе к FreeBSD и SQLite: меньше россыпи деталей наружу, больше «батарейки включены», единая система с документацией, доказательствами, логами и объяснениями внутри. Но начинался проект с инстурмента для дебега поэтому давайте рассмотрим как использовать Torque для отладки в k8s.
Для примера будем использовать Grafana, Fluent Bit, Loki canary и маленький вспомогательный chart с двумя репликами и двумя контейнерами, которые печатают JSON-логи. Такой набор удобен для отладки: есть нормальный веб-сервис, daemonset-сборщик, намеренно сломанная связь с Loki и структурированные ошибки приложения.
Я специально оставил в сценарии несколько неприятных условий: неприкрепленные digest-образы, отсутствующий Loki service, ранний readiness race у Grafana и шумный daemonset, читающий node logs. Поэтому статья показывает не идеальный happy path, а нормальную инженерную работу: найти риск до apply, увидеть план, затем доказать причину по логам.
Сначала verifier
Отладка начинается до мутации кластера. verifier рендерит chart теми же values, которыми потом будет пользоваться релиз, и проверяет Kubernetes-политику: securityContext, автомонтирование service account token, probes, ресурсы, RBAC и другие рискованные места. В этом прогоне отчеты были записаны для всех четырех чартов, а HTML-версии сохранены для Grafana и Fluent Bit. Это важно: когда релиз ломается, оператор видит не абстрактное “Helm failed”, а точный список допущений, с которыми chart пошел в кластер.
verifier --chart ./grafana --release wr-grafana -n torque-debug \
--values values/grafana-debug.yaml \
--mode warn --fail-on critical \
--format json --report reports/verifier-grafana.json
Потом Helmer-style план
Следующий слой - план. В текущей ветке Torque интерактивный Helmer-style отчет делается через torque apply plan --visualize. Он показывает, какие объекты будут созданы или обновлены, какие манифесты получились после values, и какие verifier-отчеты прикреплены к плану. Для отладки это полезнее, чем смотреть только live pods: план отвечает, почему Kubernetes вообще получил такой Deployment, DaemonSet, ServiceAccount или Service. В моем запуске были созданы HTML-планы для Grafana, Fluent Bit, Loki canary и JSON log lab.
torque apply plan --chart ./fluent-bit --release wr-fluent -n torque-debug \
--values values/fluent-bit-debug.yaml \
--verify-report reports/verifier-fluent-bit.json \
--visualize --format html --output reports/helmer-fluent-bit-plan.html
Apply с доказательствами
После проверки и плана я сделал apply для релиза через torque apply с --predict, --proof-bundle и --capture. Grafana поднялась за 21 секунду, Fluent Bit - примерно за 3 секунды, Loki canary был применен без ожидания готовности downstream Loki, а JSON log lab поднял две реплики. Torque заранее отметил риск из-за image references без digest pinning и сохранил apply-сессии в SQLite. Это дает точку возврата: если дальше логи покажут проблему, ее можно связать с конкретной версией chart, values, планом и фактическим apply.
torque apply --chart ./grafana --release wr-grafana -n torque-debug \
--values values/grafana-debug.yaml \
--predict \
--proof-bundle=reports/grafana-apply-proof.json \
--capture=captures/grafana-apply.sqlite \
--timeout 4m --yes
Пять сложных случаев логирования
Главная часть лабы - torque logs. Я собрал пять реальных кейсов. Первый: Grafana по label selector с --events и highlight, где Kubernetes-события показали ранний readiness failure, хотя deployment позже стал healthy. Второй: Fluent Bit DaemonSet, где логи плагина показали wr-fluent-loki:3100 DNS lookup failure и mem buffer pause. Третий: Loki canary, который печатал сообщения и одновременно показывал ошибку URL для tail/query к отсутствующему Loki. Четвертый: deploy/wr-grafana с --deploy-mode stable+canary, где Torque сам выбрал ReplicaSet по Deployment. Пятый: JSON workload с --filter level=error, где из двух pod и двух контейнеров остались только ошибки API 502 и worker dead-letter события.
torque logs -n torque-debug \
-l app.kubernetes.io/instance=wr-json \
--diff-container --filter level=error \
--highlight '"level":"error"|timeout|dead letter|502' \
--capture=captures/05-json-filter-errors.sqlite \
--tail 120 --timezone UTC
Почему capture важнее копипаста
Каждый log case был сохранен в SQLite через --capture, а потом разобран командой torque explain. Это меняет стиль отладки. Вместо того чтобы вставлять в чат 300 строк терминала, можно передать файл и короткое объяснение: primary cause, failure hints, affected pod/container и команду для повторного анализа. Для Grafana explain выделил readiness probe connection refused. Для Fluent Bit - ошибку отправки batch в несуществующий Loki service. Для JSON log lab - конкретные строки с level=error, статусом 502, trace id и dead-letter очередью.
torque explain
Практический порядок
Рабочий порядок получается простым. Сначала запускайте verifier и сохраняйте JSON/HTML, чтобы политика была видна до apply. Затем делайте Helmer-style план через torque apply plan --visualize и прикрепляйте verifier report, чтобы diff, ресурсы и риски были в одном HTML. Потом применяйте chart через torque apply --predict --proof-bundle --capture. Когда начинается отладка, используйте torque logs не как замену kubectl logs, а как контекстный инструмент: selector, events, deployment lens, JSON filter, highlight, timezone и capture. В конце всегда прогоняйте torque explain по SQLite-файлу. Тогда отладка Helm-релиза становится не воспоминанием оператора, а проверяемым артефактом.
PS. Torque умеет работать с MCP. Разработчик на Mac OSX может работать с удаленным сервером Linux на котором установлен Torque как сервис и закручены "гайки".
