Как выглядит кластер, если смотреть на него целиком

Для тех, кто держит Kubernetes дома — на мини-серверах, Raspberry Pi или паре старых системников — привычный инструментарий обычно сводится к двум крайностям. Либо голый kubectl и простыни YAML, где сигнал тонет в managedFields и status.conditions, либо тяжёлые десктопные комбайны вроде Lens, требующие сотни мегабайт оперативной памяти и, в некоторых редакциях, аккаунта. Встроенный Kubernetes Dashboard обычно слишком скуден для реальной диагностики.

Radar — open-source UI для Kubernetes, распространяемый как один бинарник на Go. Не требует регистрации, работает бесплатно, потребляет менее 128 МиБ памяти и разворачивается либо локально с проброшенным kubeconfig, либо прямо в кластере через Helm. Для домашней лаборатории с ограниченными ресурсами узла это принципиально другой профиль по сравнению с Electron-приложениями.

Чем Radar отличается от привычных инструментов

Метрика	Radar	Kubernetes Dashboard	Lens	k9s
Тип	Бинарник / in-cluster	In-cluster web UI	Electron-приложение	TUI
RAM	< 128 МиБ	~100–200 МиБ	500+ МиБ	~50 МиБ
Аккаунт	Не нужен	Не нужен	Нужен для части функций	Не нужен
Топология ресурсов	Есть	Нет	Платно	Нет
Карта трафика	Есть	Нет	Нет	Нет
GitOps (FluxCD)	Есть	Нет	Частично	Нет
MCP-сервер для ИИ-агентов	Есть	Нет	Нет	Нет
Лицензия	Apache 2.0	Apache 2.0	Проприетарная	Apache 2.0

Radar не заменяет Grafana с дашбордами метрик и не выполняет роль лог-агрегатора. Его задача — за секунды ответить на вопрос «что вообще происходит в кластере прямо сейчас и почему», причём с нулевым порогом входа: не нужно ни настраивать data source, ни разбираться в PromQL, чтобы получить первую пользу.

Установка в домашнем кластере

Для in-cluster варианта достаточно Helm:

helm repo add skyhook https://skyhook-io.github.io/helm-charts
helm repo update

helm upgrade --install radar skyhook/radar --version 1.11.0 \
  -n radar --create-namespace -f radar-values.yaml \
  --wait --timeout 5m

Ключевой момент — RBAC-конфигурация. Чарт создаёт ClusterRole с read-only доступом к стандартным ресурсам и примерно 45 группам CRD (FluxCD, cert-manager, Istio, KEDA, Velero, CloudNativePG и другие), но все потенциально опасные права по умолчанию выключены и включаются явными флагами:

rbac:
  podLogs: true       # просмотр логов подов — включён по умолчанию
  podExec: false       # терминал в подах — включайте осознанно
  secrets: false        # чтение Secrets — выключено по умолчанию
  helm: false            # Helm write-операции — выключено по умолчанию
  portForward: false   # порт-форвардинг для сторонних источников
timeline:
  storage: memory

Для одиночного домашнего узла или маленького кластера на пару нод такой read-only профиль — разумная точка старта: Radar сразу показывает состояние кластера, а write-операции (терминал в подах, чтение секретов, Helm-апгрейды через UI) включаются по мере необходимости, а не по умолчанию.

Если Radar запускается локально, а не в кластере, достаточно указать kubeconfig — бинарник подключится напрямую и ничего дополнительно ставить не нужно.

Что реально помогает в эксплуатации

Issues — ранжированный поток проблем: CrashLoopBackOff, OOMKill, ImagePullBackOff, провалы readiness/liveness проб, зависшие Terminating с указанием finalizer’ов, недокатанные rollout’ы. Все находки сгруппированы по субъекту — одно упавшее приложение превращается в одну строку, а не в двадцать разрозненных событий. Отдельно вычисляются scheduling-проблемы: какая именно taint, affinity или ResourceQuota мешает поду попасть в Running.

Topology — интерактивный граф связей ресурсов в реальном времени, с двумя режимами: иерархия ресурсов (Deployment → ReplicaSet → Pod, плюс ConfigMap’ы, Secrets, HPA) и сетевой путь (Ingress → Service → Pod). Для незнакомого namespace это самый быстрый способ понять, кто на что ссылается, без последовательных kubectl describe.

Timeline — единая лента событий Kubernetes и diff’ов изменений ресурсов (какие именно поля поменялись — реплики, образ, лимиты) в реальном времени через SSE. По умолчанию in-cluster Radar хранит историю в памяти, и рестарт пода её стирает; для многодневного audit-trail включается SQLite на PVC с настраиваемым retention.

Traffic — живая карта сетевого трафика между сервисами. Источник данных Radar определяет автоматически: Hubble (если в кластере используется Cilium), Istio, Caretta или Grafana Beyla — последний даёт eBPF-видимость L4 и HTTP без установки полноценного service mesh, что для домашнего кластера часто избыточно. Дропнутые сетевые потоки отображаются на карте с указанием конкретной NetworkPolicy, которая их заблокировала, — отладка сетевых политик перестаёт быть гаданием.

Checks — 31 проверка best practices по безопасности, надёжности и эффективности: привилегированные контейнеры, отсутствующие probes, теги latest, деплойменты в одну реплику без PodDisruptionBudget, незаданные requests/limits. Каждая находка сопровождается описанием и рекомендацией по исправлению.

Upgrade Impact — отдельная проверка кластера перед апгрейдом control plane: удалённые API текущей версии, несовместимый kubelet-skew, пересекающиеся PDB. Для домашнего кластера, где апгрейд version control plane делается руками и без страховочной сети staging-окружения, это заметно снижает риск сломать кластер посреди апгрейда.

Встроенный MCP-сервер

Отдельная особенность Radar — встроенный сервер Model Context Protocol. ИИ-агенты (Claude, Cursor и другие) получают доступ к кластеру через token-оптимизированные структуры Radar: топологию, health-оценки, дедуплицированные события, отфильтрованные логи — вместо сырого вывода kubectl. Для read-only сценариев предусмотрен отдельный /mcp-readonly endpoint: write-инструменты (restart, scale, sync) в него просто не попадают в каталог, и агент физически не может их вызвать — граница строже, чем обычный отказ RBAC с кодом 403. Для домашнего кластера, где хочется дать ассистенту возможность диагностировать проблемы без риска что-то сломать, это удобная граница по умолчанию.

RBAC-граница, о которой стоит знать

Флаг rbac.viewRBAC заслуживает отдельного внимания: он не даёт возможности редактировать роли (write-глаголов у Radar в RBAC-группах нет вообще ни при каких настройках), но открывает просмотр Roles, RoleBindings, ClusterRoles и ClusterRoleBindings — то есть карту авторизации кластера: какие ServiceAccount’ы обладают wildcard-правами или глаголами escalate/impersonate. Сами секреты этот флаг не раскрывает, но в связке с публично открытым UI без аутентификации превращается в готовую разведку для потенциального атакующего. Если Radar выставлен наружу — через basic auth на ingress или встроенный OIDC-режим — включать viewRBAC разумно; если UI доступен без аутентификации, лучше оставить выключенным.

Итог

Для домашнего Kubernetes-кластера Radar закрывает нишу между «слишком бедным» Dashboard и «слишком тяжёлым» Lens: один бинарник, минимальное потребление памяти, разумные RBAC-настройки по умолчанию и функциональность, которой обычно не хватает именно в моменте инцидента — единый поток проблем, граф зависимостей и лента изменений вместо десятка вкладок kubectl get и kubectl describe.