Klarity: архитектура дашборда наблюдаемости для Kubernetes в парадигме GitOps

В современных инфраструктурных командах внедрение методологии GitOps давно стало отраслевым стандартом. Инструменты вроде ArgoCD и Flux гарантируют, что единственным источником истины для состояния кластера Kubernetes является Git-репозиторий. Любое изменение в продакшене должно оформляться через pull request, проходить автоматические проверки и рецензирование кода.

Однако популярные инструменты визуализации — официальный Kubernetes Dashboard, Lens или Headlamp — проектировались в парадигме прямого администрирования. Они предлагают удобные кнопки редактирования манифестов, масштабирования реплик и ручного удаления подов. Для дежурного инженера велик соблазн быстро «поправить конфигурацию руками» во время инцидента. В итоге возникает дрейф конфигурации (configuration drift): реальное состояние кластера расходится с репозиторием, ломается аудит изменений, а следующий запуск GitOps-пайплайна либо затирает срочный хотфикс, либо приводит к аварийному конфликту синхронизации.

Открытый проект Klarity решает это фундаментальное противоречие, предлагая бескомпромиссную концепцию наблюдаемости: «Наблюдай всё, не меняй ничего» (Observe everything. Change nothing).

Архитектурная философия: наблюдай всё, не меняй ничего

Архитектура Klarity изначально спроектирована так, чтобы исключить любую возможность случайной или намеренной мутации ресурсов кластера через графический интерфейс. В бэкенде дашборда просто отсутствуют API-эндпоинты, принимающие методы POST, PUT, PATCH или DELETE для ресурсов Kubernetes.

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

Стек технологий Klarity оптимизирован для минимального потребления ресурсов и быстрого старта:

• Бэкенд на Go: компилируется в единый статический бинарник без внешних рантайм-зависимостей. Он взаимодействует с Kubernetes API через официальный клиент client-go, агрегирует метрики и кэширует информацию о ресурсах.
• Интерфейс на Next.js: современное легковесное SPA-приложение с реактивными графиками потребления ресурсов и встроенным эмулятором терминала на базе библиотеки xterm.js.
• Колоночная СУБД ClickHouse: опциональный, но рекомендуемый компонент для долговременного хранения телеметрии, исторических метрик и аналитики системных событий без нагрузки на хранилище etcd кластера.

Автообнаружение ресурсов и глубокая диагностика

В отличие от традиционных решений, требующих ручной настройки отображения каждого типа объектов, Klarity реализует механизм динамического автообнаружения (Auto-discovery).

При старте бэкенд обращается к служебному эндпоинту GET /apis API-сервера и строит граф всех зарегистрированных в кластере API-групп и версий. Klarity автоматически распознает более 60 стандартных типов ресурсов Kubernetes и мгновенно адаптируется под пользовательские определения ресурсов (Custom Resource Definitions, CRD).

Если в кластере развернуты сервисы ArgoCD, контроллеры Istio, менеджер сертификатов Cert-Manager или операторы баз данных, соответствующие разделы автоматически появляются в боковом меню дашборда с отображением их специфических статусов и связей.

Для оперативной отладки сервис предоставляет развитый набор инструментов:

1. Потоковый стриминг логов: передача журналов контейнеров в реальном времени через протокол WebSockets с мгновенной фильтрацией по уровням логирования (ERROR, WARN, INFO, DEBUG) и регулярным выражениям.
2. Веб-терминал (kubectl exec): безопасное подключение к интерактивной сессии пода через браузер с поддержкой автопереподключения при разрывах сети, не требующее установки локального бинарника kubectl на компьютере разработчика.
3. Проксирование портов (Port-Forwarding): прямой доступ к внутренним веб-сервисам и метрикам подов прямо из браузера через защищенный SPDY HTTP-прокси.
4. Панель постоянных сессий (Activities Panel): возможность закрепить открытые терминалы и окна мониторинга логов в нижней панели интерфейса, сохраняя сессии активными при переходе между разными экранами и неймспейсами.

Корпоративная безопасность: RBAC и интеграция с SSO

Для использования в enterprise-среде Klarity предоставляет гибкую ролевую модель и интеграцию с корпоративными провайдерами идентификации (Identity Providers).

Встроенный механизм авторизации поддерживает три базовые роли:

• viewer: просмотр манифестов, топологии сервисов и графиков метрик;
• editor: доступ к просмотру логов и пробросу портов;
• admin: управление учетными записями пользователей, аудит сессий и доступ к веб-терминалу.

Хеширование локальных паролей выполняется алгоритмом bcrypt с фактором стоимости 12, а механизм защиты от перебора блокирует учетную запись на 15 минут после пяти неудачных попыток входа подряд. Сессионные токены JWT выпускаются со сроком жизни 8 часов для access-токена и 7 дней для refresh-токена.

Для крупных организаций поддерживается сквозная аутентификация через протокол OIDC/SSO (Keycloak, Okta, Dex, Google Workspace, GitHub и GitLab).

Пошаговое развертывание через Helm

Развертывание Klarity не требует установки тяжелых операторов или демонов на каждом рабочем узле кластера. Достаточно запустить один под приложения в изолированном пространстве имен.

Ниже приведен пример конфигурационного файла values.yaml для Helm, настраивающего безопасный запуск с подключением к внешней базе ClickHouse и ограничением прав сервисного аккаунта:

# values.yaml — конфигурация деплоя Klarity в production
replicaCount: 1

image:
  repository: selvarajmurugesan90/klarity
  tag: latest
  pullPolicy: IfNotPresent

config:
  authMode: internal
  logLevel: info
  sessionTimeout: 8h

# Настройки подключения к колоночной базе для долговременного хранения метрик
clickhouse:
  enabled: true
  host: clickhouse.monitoring.svc.cluster.local
  port: 9000
  database: klarity_telemetry
  auth:
    existingSecret: klarity-clickhouse-credentials
    userKey: username
    passwordKey: password

# Сервисный аккаунт с правами строгого read-only доступа к API кластера
rbac:
  create: true
  readOnly: true
  clusterRole: true

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

После подготовки конфигурации развертывание выполняется стандартными командами Helm:

# Добавление официального репозитория чартов Klarity
helm repo add klarity https://selvarajmurugesan90.github.io/klarity
helm repo update

# Установка релиза в изолированный namespace с передачей настроек
helm upgrade --install klarity klarity/klarity \
  --namespace monitoring \
  --create-namespace \
  -f values.yaml

# Проверка статуса запуска пода и проброс локального порта
kubectl get pods -n monitoring -l app.kubernetes.io/name=klarity
kubectl port-forward svc/klarity 8080:8080 -n monitoring

После запуска веб-интерфейс становится доступен по адресу http://localhost:8080. Первичный вход осуществляется с учетными данными по умолчанию (admin / admin@123), после чего система принудительно запросит установку нового надежного пароля.

Сравнение с существующими решениями

Klarity органично вписывается в инфраструктуру команд, стремящихся к прозрачности процессов и строгому соблюдению принципов GitOps.