Возможности:
— работа в терминале: Позволяет ставить задачи, инспектировать файлы, запускать команды и редактировать код в рабочей директории.
— поддержка множества провайдеров: Интегрируется с 15+ платформами, включая OpenAI, Anthropic, Google, Mistral, Groq и локальные модели через Ollama.
— древовидная история сессий: Сессии сохраняются в виде деревьев с возможностью ветвления и продолжения работы.
— система навыков (Skills): Поддерживает загрузку дополнительных возможностей, инструкций и кастомных инструментов на лету.

Kubernetes Events — это ресурсы типа Event в Kubernetes, которые информируют вас о том, что происходит в вашем кластере. Это похоже на новостную ленту для компонентов кластера: они фиксируют всё — от запуска Pod'ов до ошибок в работе контроллеров.

Каждое событие в Kubernetes содержит:

* message: краткое описание произошедшего
* reason: код причины события
* type: Normal или Warning
* involvedObject: объект, к которому относится событие (например, Pod или Node)
* firstTimestamp, lastTimestamp, count: время и количество повторений

🔎 Как посмотреть события:


kubectl get events


Или для конкретного Pod'а:


kubectl describe pod <pod-name>


Kubernetes сам удаляет события через час. Это значит, что они не предназначены для долговременного хранения.

📤 Хранение событий

Если вам нужно сохранить события дольше, можно:

* Настроить аудит в Kubernetes
* Использовать внешние системы логирования (например, Elasticsearch + Fluentd)
* Подключить event exporters

Распространение Pod-модулей играет гораздо большую роль в обеспечении надежности, чем вы могли бы подумать. Добавив несколько строк в свой манифест, вы можете обеспечить зональную избыточность и равномерную масштабируемость ваших развертываний. Эта функция называется topology spread constraints, и в этом блоге мы подробно объясним, как она работает.

Главная идея проекта: кластер нужно наблюдать через панель, а изменять — через Git, pull request и привычный CI/CD-процесс. Поэтому в Klarity нет универсального редактора ресурсов, позволяющего незаметно изменить YAML в обход GitOps.

Возможности:
— автоматически обнаруживать более 60 типов Kubernetes-ресурсов и установленные CRD;
— показывать Pods, Deployments, StatefulSets, Services, Ingress, PVC, RBAC, события и другие объекты;
— выводить CPU и память узлов, Pod и отдельных контейнеров через metrics-server;
— ранжировать основные потребители ресурсов;
— транслировать логи контейнеров через WebSocket;
— открывать веб-терминал в контейнере через kubectl exec;
— организовывать port forwarding прямо из браузера;
— искать ресурсы сразу по нескольким категориям;
— формировать HTML-отчёт о состоянии кластера.

Отдельно приятна автоматическая интеграция с Argo CD и Flux. Klarity обнаруживает их CRD и показывает состояние Applications, ApplicationSets, Kustomizations, HelmReleases и Git-репозиториев без дополнительной настройки.

Для нескольких кластеров можно загрузить набор kubeconfig-файлов и переключаться между контекстами из интерфейса.

Backend написан на Go, frontend — на React и TypeScript. Интерфейс встраивается в один исполняемый файл. Развернуть приложение можно через Helm или Kustomize.

Klarity — это скорее альтернатива Headlamp, Lens или веб-вариант k9s, а не полноценная observability-платформа. Здесь нет долговременного хранения метрик, централизованного хранилища логов и трассировки. Метрики берутся из metrics-server, логи транслируются напрямую, а журнал аудита хранится в ограниченном буфере памяти.

Примонтировать ~/.ssh в контейнер с флагом :ro — и вроде как позаботился о безопасности. Только приватный ключ при этом всё ещё можно прочитать и утащить. От этого read-only не спасает.

В этом разборе на Хабре рассказывают о том, как дать rootless-контейнеру SSH-доступ через ssh-agent, оставив сам ключ на хосте. Пригодится для автоматизации, работы с приватными репозиториями и ИИ-агентов, которым нужен Git.

Rootless Docker имеет свои нюансы: UID пользователя внутри контейнера преобразуется в другой UID на хосте, поэтому просто пробросить сокет агента недостаточно.

Оказывается, доступ к сокету всё ещё позволяет пользоваться загруженным ключом. Если контейнер взломали, злоумышленник сможет выполнять доступные этой SSH-идентичности операции, пока имеет доступ к агенту. Сам приватный ключ через штатный протокол агента при этом не выдаётся.

Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра.

Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AST,оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ.

Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно.