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-идентичности операции, пока имеет доступ к агенту. Сам приватный ключ через штатный протокол агента при этом не выдаётся.