Идея простая: вы описываете CRD Kroc, указываете, за какими объектами в Kubernetes нужно следить, и задаёте шаблон ресурса, который должен быть создан на основе найденного объекта.

Например, оператор может смотреть за Deployment, брать из него нужные поля и автоматически создавать связанные Pod, Service, ConfigMap или другие Kubernetes-объекты.

Внутри используется Go и Kubebuilder.

Самое интересное - реактивная модель.

Если исходный объект изменился, производные ресурсы пересоздаются.

Если кто-то вручную удалил созданный объект, оператор создаст его снова, чтобы вернуть кластер в нужное состояние.

По сути, это хороший минимальный пример того, как работает operator pattern в Kubernetes:

наблюдаем за состоянием
сравниваем с желаемым
создаём или пересоздаём ресурсы
держим систему синхронизированной

Архитектура тоже полезная для разбора: проект разделяет логику на несколько контроллеров.

Один отвечает за CRD и конфигурацию, второй наблюдает за внешними Kubernetes-объектами, третий создаёт производные ресурсы из шаблонов.

Для новичков в Kubernetes Operators это намного понятнее, чем сразу лезть в большие production-операторы.

Kroc хорошо показывает базовую механику: CRD, reconcile loop, watch, template rendering и управление жизненным циклом дочерних объектов.

Kubernetes — мощный инструмент, но устранение неполадок в живом кластере может быть мучительным. В сложном развертывании критические предупреждающие знаки часто скрываются в тысячах строк логов и событий. Что, если бы мы могли выявить эти проблемы с надежностью до того, как они приведут к остановке приложений?

Kubernetes поставляется со встроенной функцией отслеживания загрузки CPU и использования памяти, но большинство решений по масштабированию в реальных условиях зависят от сигналов, которые находятся за пределами этого узкого диапазона: сколько сообщений ожидает в очереди, сколько времени заняла последняя пакетная задача, сколько активных WebSocket-соединений поддерживает под. Когда встроенных метрик недостаточно, экспортер метрик восполняет этот пробел.

В этой статье подробно описано, как создать такой контейнер с нуля, упаковать его в подобие контейнера и подключить к кластеру, чтобы Prometheus — и в конечном итоге HorizontalPodAutoscaler — могли его использовать.

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go.

Кажется, в observability снова выбор без выбора: Grafana или ClickStack?

Статья разбирает вопрос выбора на примере ClickHouse. Если ClickHouse — центральное хранилище телеметрии, а инженеры чаще расследуют инциденты, чем смотрят на заранее созданные графики, авторы предлагают смотреть в сторону ClickStack: поиск, корреляция логов, метрик и трейсов, session replay и отдельный акцент на AI/SRE-агентов через MCP.

Grafana остаётся сильнее там, где инфраструктура неоднородная: Prometheus, ClickHouse и ещё десяток источников, которые нужно собрать на одном дашборде, добавить алертинг и не заставлять команду менять привычные процессы.

Так как статья опубликована в блоге Clickhouse, практичный вывод напрашивается сам собой: «А зачем выбирать?» Grafana можно оставить для дашбордов и мониторинга, а ClickStack использовать для глубоких расследований по данным ClickHouse. Причём данные и ingestion pipeline дублировать не придётся.