В этой статье в блоге VictoriaMetrics рассказывают про путь записи логов: от приёма и преобразования в единый внутренний формат до размещения в потоках, дневных партициях и неизменяемых частях на диске и объясняют, как VictoriaLogs группирует логи по полям потока, разбивает данные на блоки и хранит каждое поле в отдельной колонке. Также разбирается назначение основных файлов внутри партиций, работа bloom-фильтров, двухуровневых индексов и механизмов слияния небольших частей в более крупные.

Главная идея архитектуры: сначала прочитать небольшой объём метаданных и исключить ненужные данные, а уже затем обращаться к конкретным блокам, колонкам и значениям. За счёт этого запросы не сканируют весь объём логов, а читают только необходимые данные.

Идея простая: вы описываете 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 и управление жизненным циклом дочерних объектов.