В конце прошлой статьи про Sextant был план на четыре версии: 0.12–0.15. Они вышли 19 октября, за одни сутки.

Потом в комментариях нас сравнили с Radar — ещё одним бесплатным UI для Kubernetes с MCP-сервером и попросили назвать функции для честного сравнения. Мы сравнили и составили список того, что у Radar есть, а у нас нет: живой трафик, просмотр файлов образа, проверки best practices, разделы для популярных операторов. Из него получился роадмап 0.16–0.19 — и к ночи 21 октября вышел и он, кроме пакета для winget.

Напомню, что это. Sextant — десктопный клиент Kubernetes на Rust и Tauri 2, замена Lens без аккаунта, подписки и телеметрии, со встроенным MCP-сервером для AI-агентов. Он бесплатный и таким останется. Весь его код сгенерирован ИИ (Claude Code): человек ставит задачи, принимает архитектурные решения и делает ревью, а каждое изменение проходит многократное тестирование.

Спасибо всем, кто читал, спорил и пробовал. @philyuchkoff прислал PR с поддержкой proxy-url (вошёл в 0.13.1), а сейчас работает над памятью на больших кластерах. @nd4y нашёл обрезанное меню на Windows — исправлено в 0.15.2.

Ниже — дайджест всех релизов и обзор новых функций по темам.

Дайджест: 16 релизов с 19 по 21 октября

Время московское, свежие версии сверху. У каждой функции есть issue с требованиями и страница в вики.

Обзор новых функций

Новое сгруппировано по задачам, а не по версиям. Общее правило для всех функций: если Sextant не уверен в ответе, он пишет «Неизвестно» с причиной, а не угаданное «всё в порядке», и ничего не меняет в кластере без вашего действия.

Найти причину

Лента изменений (0.12). Страница «История изменений» и вкладка «Изменения» у любого объекта: создан, изменён или удалён, с diff по путям полей вроде containers[web].image: nginx:1.25 → nginx:1.27. Кто поменял, видно по field manager. Блок «Вскоре после этого» показывает проблемы и Warning-события от минуты до изменения до 30 минут после него — на самом объекте и его зависимых. Это корреляция, а не причина, и интерфейс так и пишет.

Почему не отмасштабировалось (0.12). У HPA — вердикт одной фразой и что просит каждая метрика; расчёт повторяет формулы самого контроллера. У застрявшего в Pending пода — разобранное сообщение планировщика с числом нод на каждую причину. Разделы KEDA и Karpenter, Cluster Autoscaler читается из его статуса.

Best practices (0.16). 12 проверок на железобетонные ошибки: нет readiness- или liveness-пробы, образ без закреплённой версии, одна реплика, нет PodDisruptionBudget или он запрещает любое вытеснение и стопорит drain, все реплики на одной ноде, нет requests или memory limit, лимит вдвое выше рекомендации right-sizing. У каждой находки — поле, почему это важно и готовый YAML для исправления. CPU limit мы не требуем сознательно: он тротлит даже когда у ноды есть свободный CPU. В уведомления находки попадают, только если вы включили эту категорию.

Почему Service не получает трафик (0.16). Действие «Диагностика» у Service, Ingress, HTTPRoute и GRPCRoute проходит путь трафика звено за звеном и останавливается на первом сломанном. Проверяются IngressClass и поды контроллера, TLS-сертификат против хостов, правила и пути, селектор, Ready-поды, targetPort, EndpointSlices и сетевые политики. Если селектор ничего не выбирает, Sextant назовёт поды, у которых не хватает одной метки: «3 пода имеют все метки селектора, кроме tier=web». Никаких пробных подов и трафика — всё по объектам.

Проверка сетевой связности (0.12). Дойдёт ли под A до пода, сервиса или внешнего IP: egress и ingress по отдельности, плюс DNS. Kubernetes NetworkPolicy считается точно, Cilium и Calico — в части L3/L4, всё остальное даёт «Неизвестно» с причиной.

Очистка (0.12). Кандидаты на удаление — PVC без подов, PV в Released, сервисы без endpoints, старые ReplicaSet, завершённые поды и Job, пустые неймспейсы — с объяснением, почему и как давно. Правило «сомневаешь — не кандидат»: никогда не предлагается то, чем управляют Helm, Flux или Argo CD, объекты с владельцами и системные неймспейсы. Удаление идёт по одному объекту с предусловиями по uid и resourceVersion.

Трафик и метрики запросов

CPU и память говорят, насколько нагружен сервис, но не говорят, хорошо ли он отвечает. В 0.17 Sextant научился читать то, что уже собирают ваши Istio, Linkerd, ingress-nginx, Grafana Beyla или Cilium Hubble в Prometheus (с 0.18.1 — и в VictoriaMetrics). Сам он ничего не устанавливает и не включает, а запросы к Prometheus собираются только в ядре, из фиксированного набора.

Граф трафика. У карты кластера появился режим «Трафик»: слева те, кто вызывает, справа — те, кого вызывают. Толщина линии — число запросов в секунду, цвет — доля ошибок: меньше 1%, 1–5%, больше 5%. Клик по линии показывает RPS, ошибки, задержку p50 и p95 и ответы по классам статусов. Окно — 5 минут или час, до 5 неймспейсов сразу. Если один вызов видят два источника (скажем, Istio и Hubble), цифры не складываются.

Метрики запросов. У Deployment, StatefulSet, DaemonSet и пода — секция «Запросы»: число запросов, доля ошибок, задержка p50/p95/p99 и графики за час, с пометкой, откуда цифры и что именно они считают. Задержка, которую нельзя посчитать, будет «неизвестна», а не 0. Сюда же вошли метрики Linkerd, которые не успели в 0.15.

CPU throttling. Доля периодов, в которые контейнер упирался в лимит, по счётчикам cAdvisor. Если это 25% и больше, Sextant прямо скажет, что медленные ответы скорее всего из-за CPU limit, и предложит лимит из right-sizing.

Экосистема

Любой CRD Sextant показывал и раньше, но из YAML редко понятно, работает ли объект. Теперь у популярных проектов есть свои разделы в боковой панели: они появляются, только если кластер отдаёт их виды, и объясняют статус словами оператора, а не своими догадками.

• Argo Rollouts (0.18): шаг, вес канарейки, ReplicaSet и анализ. Роллаут можно promote, full promote, abort и retry — теми же изменениями, что отправляет плагин kubectl argo rollouts, сам плагин не нужен.

• Argo Workflows (0.18): дерево шагов с упавшим шагом и его логами, CronWorkflows.

• Knative, Crossplane, Kyverno, External Secrets, CloudNativePG, Strimzi, Prometheus Operator (0.18): статус с причиной первого упавшего условия, связи между объектами и счётчик проблем на заголовке раздела. Например: «Последняя ревизия web-00004 упала (ContainerMissing), трафик остаётся на web-00003». Действий тут нет — только обычные Edit и Delete. Секреты External Secrets не показываются никогда.

• Istio и Linkerd (0.15): все их ресурсы, страница «Маршрутизация запросов», на нагрузке — кто может её вызывать, какой режим mTLS действует и в mesh ли она (sidecar, native sidecar, ambient).

• Helm (0.16): сравнение любых двух ревизий — values, манифест по объектам и notes, кнопка «Что изменилось в последнем upgrade». Колонка «Новейший чарт» и фильтр «Есть обновления» по вашим репозиториям через helm search; OCI-чарты пока показываются как «неизвестно»: Helm не умеет списывать их теги без скачивания.

Рабочее место

• Сохранённые виды и рабочие пространства (0.13). Вид запоминает вид ресурса, неймспейсы, поиск, label selector, сортировку и колонки. Рабочее пространство фильтрует список кластеров. Экспорт для коллег не содержит ни учётных данных, ни секретов, ни токена MCP.

• kubeconfig (0.13, 0.19). Переименовать контекст, задать неймспейс по умолчанию, дублировать, удалить, слить до 32 файлов — с предпросмотром, резервной копией и проверкой, что файл не поменяли снаружи. ~/.kube/config редактируется, только если вы это разрешили. Срок действия сертификата и токена виден за 14 дней, exec-плагины для этого не запускаются. В 0.19 kubeconfig кластера можно посмотреть и скопировать, а настройки кластера разложены по вкладкам.

• Свои колонки (0.18) в любой таблице: из метки, аннотации или поля (.spec.nodeName, .spec.containers[0].image). Сортируются и ищутся как встроенные. Это намеренно не JSONPath: без [*], фильтров и функций. Ширина всех колонок меняется и запоминается (0.15.1).

• Set image (0.18) — как kubectl set image: все контейнеры с текущими образами, проверка имени образа при вводе (опечатка не превратится в ImagePullBackOff), предпросмотр через dry-run на сервере. Отправляется один патч только полей образов.

• YAML-редактор по схеме кластера (0.14): автодополнение полей и значений, подчёркивание ошибок, панель Explain. Схема берётся из /openapi/v3 вашего кластера, включая CRD. Документ api/v1 при наивном разборе занимает около 118 МБ, поэтому ядро читает его потоком.

• Терминал (0.14): до 8 панелей в вкладке, сниппеты с {{namespace}} и {{pod}}, экранируемыми по правилам оболочки. Broadcast выключен по умолчанию, панели других кластеров сами не выбираются, а первое нажатие открывает подтверждение: случайный rm в проде из вкладки с девом не уйдёт. В логах — перенос строк и ANSI-цвета (0.15.3).

• Сравнение и дрейф (0.15): объект с таким же в другом кластере или неймспейсе, с last-applied или с манифестом Helm; страница «Сравнить неймспейсы» находит расхождения staging и prod целиком. Secret сравниваются по SHA-256 внутри ядра, в окно не попадают ни значения, ни хеши.

• Мелочи: кластеры в боковой панели перетаскиваются (0.15.6), «Скопировать namespace/name» у любого объекта (0.19), шрифты Fira или системные (0.15.3), SOCKS5 в proxy-url (0.15).

Хранилища, стоимость и файлы образа

Хранилища (0.14). Колонка «Заполнение» у PVC, занятое место и inodes у заявки и пода — из kubelet или Prometheus, раз в минуту и только пока это на экране. Разделы VolumeSnapshot и Velero с действиями «Создать снапшот», «Восстановить в новый PVC», «Сделать бэкап неймспейса». Эти действия только создают новые объекты и никогда не меняют существующие.

Стоимость (0.14). Если в кластере есть OpenCost или Kubecost: страница «Стоимость» за 24 часа, 7 или 30 дней с группировкой по неймспейсу, нагрузке, поду, ноде или метке и отдельной стоимостью простоя. У Deployment — оценка в месяц и экономия от рекомендации right-sizing. Запросы идут через service proxy API-сервера, без port-forward и сохранённых паролей.

Файлы образа (0.19). Файловая система образа читается прямо из registry: без exec в контейнер, без pull на ноду и без локального docker. Открывается кнопкой «Файлы образа» у контейнера или по ссылке на образ. Видно собранное дерево файлов так, как его увидит контейнер, слои с командами, которые их создали, поиск по пути, просмотр и скачивание файла. Для доступа берутся pull secrets пода, а ваши Docker-учётные данные — только если включите это сами. Учётные данные не покидают ядро.

Раз Sextant сам ходит по адресу из ссылки на образ, тут много защиты: только HTTPS, отказ от loopback, link-local и адресов облачных metadata-сервисов (и так же для редиректов и сервера токенов), токен только на pull одного репозитория. От «бомб» стоят лимиты: до 128 слоёв, 300 000 записей и 8 ГБ скачивания за открытие. Симлинки следуют только внутри образа, ничего не запускается и не распаковывается на диск.

Большие кластеры и доступность

Очень большие кластеры (0.15). Списки грузятся по 500 объектов и показываются сразу. Таблица держит до 20 000 объектов и честно пишет «показаны первые N из M», поиск по меткам уходит на API-сервер. Замеры на фейковом API-сервере с подами по ~2,5 КБ, release-сборка:

В окне на 50 000 подов сортировка по имени ускорилась с 258 до 15 мс, поиск по метке — с 53 до 2 мс. Где ещё есть куда расти: ядро пока хранит объект как JSON-дерево, это примерно вчетверо больше самого JSON. PR с компактным хранением уже прислал @philyuchkoff, мы его разбираем.

Доступность (0.15, 0.15.4). Вся работа с клавиатуры: стрелки по строкам таблиц, Shift+F10 — меню строки, Ctrl+Shift+E — выйти из терминала. Размер текста, уменьшение анимации, режим терминала для скринридера. Контраст обеих тем проверяется тестом, axe-core проходит все страницы в тестах и отдельно — настоящий WebKit в e2e.

AI-агенты

В 0.16 MCP-сервер получил шесть инструментов диагностики, и теперь их у агента 35. Агент спрашивает то же, что вы видите в окне, и получает ответ тех же движков:

• get_problems — проблемы кластера или неймспейса;

• diagnose_service — почему Service, Ingress или route не получает трафик;

• check_connectivity — дойдёт ли A до B;

• get_permissions — что может субъект и кто может сделать действие;

• get_recent_changes — недавние изменения из ленты;

• get_autoscaling_status — вердикт HPA и KEDA, причины Pending.

Все шесть — только чтение, по тем же правилам доступа, что и остальные, с записью в журнал. Ответ строится только из того, что агенту разрешено читать, и перед отдачей перепроверяется в Rust по каждому упомянутому объекту. На этом мы сами поймали утечку до релиза: сетевые политики читались шире прав агента и только потом фильтровались (#221).

Закрытым для агента осталось то, что ему лучше не давать: массовая очистка, правка kubeconfig, broadcast в терминалы, файлы образа с чужими pull secrets. Изменения по-прежнему идут только через правила на кластер, подтверждение в окне Sextant и журнал. А кнопка «Разрешить» в диалоге первую секунду игнорирует клавиатуру, чтобы случайный Enter не одобрил чужое действие.

Как 16 релизов поместились в двое суток

Между тегами v0.11.1 и v0.19.0 прошло около 50 часов: 83 коммита и примерно 176 тысяч новых строк. Из них 57 тысяч — переводы на 14 языков, 34 тысячи — Rust, 71 тысяча — TypeScript вместе с тестами. Для меня это самая наглядная демонстрация того, на что способны современные модели, — и главный повод для скепсиса. Поэтому расскажу, что стоит за этими цифрами.

Код по-прежнему целиком пишет Claude Code. Каждая функция проходит один и тот же путь:

1. Issue с требованиями — его утверждает человек.

2. Архитектурное решение (ADR) с границами: что читается, сколько watch открывается, что никогда не делается и получает ли доступ агент. За эти дни их появилось 27, всего их 105.

3. Код и тесты вместе. Тестов на Rust стало 1429 вместо 989, на vitest — 3092 вместо 1629.

4. Проверки на настоящем kind-кластере и CI на Linux, macOS и Windows; тег ставится, только когда CI зелёный на именно этом коммите.

5. Ревью: соответствует ли результат задуманному, а для чувствительных частей — отдельное ревью безопасности. Оно нашло замечания в просмотре kubeconfig и в файлах образа, их исправили до релиза 0.19.

Быстро не значит без ошибок. Пользователи нашли две: не работал proxy-url (#175, исправлено в 0.13.1) и на Windows обрезалось меню строки (#176, в 0.15.2). Не всё вошло как задумано: пакет для winget ещё не опубликован, новые версии OCI-чартов Helm не определяются. И новые функции — первые версии: проверены тестами и на тестовом кластере, но ещё не вашими продакшенами. Именно такие отзывы сейчас самые ценные.

Что дальше и как попробовать

Оба роадмапа закрыты, и уже есть следующий — про то, что ещё живёт в кластерах:

Планы могут меняться по вашим запросам: идеи пишите в Discussions → Ideas или в комментарии.

Два отличия от Radar мы оставляем сознательно. Режима в кластере для команды (веб + OIDC) не будет: Sextant работает локально, и ваш kubeconfig не покидает машину. Встроенных AI-расследований тоже: агент остаётся вашим и подключается через MCP, а данные кластера никуда не уходят сами.

Что мы знаем сами и не прячем:

• Установщики не подписаны сертификатами Apple и Microsoft (#20), поэтому macOS и Windows предупреждают при первом запуске.

• macOS и Windows проверяются в CI, но не на живых машинах (#21); облачные кластеры — на поддельных CLI, а не на реальных аккаунтах (#82). Если вы на одной из этих платформ — отзыв особенно ценен.

• Память на больших кластерах ещё можно уменьшить (#170), и для этого уже есть внешний PR (#203).

Как поставить:

brew install --cask friendsofkubernetes/sextant/sextant      # macOS
scoop bucket add sextant https://github.com/FriendsOfKubernetes/sextant-scoop
scoop install sextant/sextant                                # Windows

Или скачайте .deb, .rpm или .AppImage (x86_64 и arm64), .dmg или .msi из последнего релиза; как открыть их на macOS и Windows — в инструкции. Установленный из AppImage, .dmg или .msi Sextant обновляется сам. Документация — в вики, баги — в issues. Если проект пригодился, поставьте звезду на GitHub: так его найдут другие.