Классический мониторинг отвечает на вопрос «что сломалось»: метрики показывают рост CPU, логи — стек ошибок, трейсы — медленный сервис. Но когда нужно ответить «почему именно этот сервис стал медленным», почти все инструменты пасуют. Вы видите, что контейнер потребляет 2 ядра CPU, но не видите, какая строка кода их загружает.

Coroot — open-source observability-платформа, которая из метрик, логов и трейсов делает выводы о том, что чинить. Её ключевая особенность — непрерывное профилирование без изменений кода: eBPF-профилировщик снимает CPU-профили всех процессов на ноде, а языковые профилировщики (Go, Java) добавляют память и блокировки. В результате флеймграф показывает нагрузку до точной строки кода, а предустановленные инспекции находят типовые проблемы — утечки памяти, лишние аллокации, блокировки.

Coroot ставится в любой Kubernetes-кластер. В этой статье мы развернём Coroot через официальный coroot-operator (Community Edition), а затем задеплоим четыре намеренно «сломанных» приложения — на Nuxt (Node.js), Python, Go и Java — и посмотрим, как их проблемы всплывают в профилировании.

Классическая ситуация: Go-сервис падает с panic: runtime error: invalid memory address or nil pointer dereference, Nuxt-фронтенд логирует NUXT_UNHANDLED: unhandled rejection. Клиент видит лишь общее «что-то сломалось» — точный текст ошибки остаётся только в логах.

Решение — алертинг по логам. Связка VictoriaLogs + Vector + vmalert + Alertmanager следит за потоком, и как только приложение пишет panic, log.Fatal или NUXT_UNHANDLED, в Telegram уходит алерт. Ниже — как поднять эту связку в Kubernetes без лишней нагрузки на хранилище.

В Kubernetes-кластере рано или поздно встаёт вопрос: где собирать Docker image приложений? Вариант «на своей машине разработчика» не масштабируется на команду. Вынос сборок на отдельную виртуальную машину решает эту проблему, но создаёт накладные расходы на обслуживание инфраструктуры и лишает ключевых преимуществ k8s: отдельная ВМ не масштабируется горизонтально под нагрузку, параллельные джобы конкурируют за общие CPU, RAM и диск, а накапливающийся кэш требует регулярной очистки.

Kubernetes executor с Kaniko, BuildKit или Buildah лишён этих недостатков: сборка происходит в изолированных подах прямо на нодах кластера, ресурсы динамически масштабируются, а виртуальные машины для Docker-демона больше не требуются.

Ситуация, знакомая многим командам: в кластере Kubernetes живут обычные бизнес сервисы, нагрузка на которые днём растёт, а ночью падает. Обычно используют два плохих варианта: держать статический пул нод под дневной пик, которые ночью простаивают и стоят денег, или положиться на cluster autoscaling — и тогда при дневном росте нагрузки бизнес-поды проведут в статусе Pending до создания новой ноды.

Проблема ожидания, пока Cluster Autoscaler развернёт новую ноду, решается паттерном node overprovisioning, настраиваемым через PriorityClass и механизмы Cluster Autoscaler: мы заранее запускаем ничего не делающие capacity-overprovisioning поды (в документации Kubernetes они называются placeholder-подами), которые занимают небольшую часть ресурсов нод. Когда приходит нагрузка и реплики бизнес-приложений увеличиваются — поды бизнес-приложений немедленно занимают освободившееся место, вытесняя capacity-overprovisioning под за секунды. Вытесненный capacity-overprovisioning под уходит в Pending, Cluster Autoscaler добавляет ноду.

Ключевая выгода паттерна — экономия. Ночью и утром, когда нагрузка падает, KEDA снижает число реплик бизнес-приложения, Cluster Autoscaler удаляет недозагруженные ноды, и кластер схлопывается до минимального числа нод. Утром при росте нагрузки capacity-overprovisioning поды отдают место мгновенно.

В этой статье разберём, как это устроено внутри, и развернём демо-стенд: от KEDA-автоскейлинга бизнес-приложения по RPS, который генерирует генератор нагрузки, до живого вытеснения capacity-overprovisioning подов, которое можно наблюдать своими глазами в kubectl get events.

Каждый разработчик сталкивался с проблемой хранения артефактов: Docker-образы, npm-пакеты, Maven-артефакты, Python wheels. Вариантов обычно два — использовать публичные реестры (Docker Hub, npmjs.org, PyPI) или поднимать Nexus / Artifactory / Harbor. Публичные реестры ненадёжны из-за rate limit и блокировок. А Nexus и Artifactory — это тяжёлая Java-платформа: JVM, отдельная СУБД (OrientDB/PostgreSQL), 2–4 ГБ RAM уже в простое и десятки минут на старт.

NORA — open-source реестр артефактов на Rust, созданный как прямая альтернатива этим гигантам. Вместо Java-стека — один бинарник < 27 МБ. Вместо 2–4 ГБ RAM — < 50 МБ в простое, т.е. на порядок меньше. Вместо десятков минут на старт — 3 секунды. Внешних зависимостей нет вообще: ни Java 11+, ни отдельной СУБД — метаданные хранятся на файловой системе, а артефакты сразу можно отправлять в S3, чего бесплатные версии Nexus и Artifactory не умеют. При этом поддерживается 15 форматов: Docker, Maven, npm, PyPI, Cargo, Go, Raw, RubyGems, Terraform, Ansible Galaxy, NuGet, Pub (Dart/Flutter), Conan (C/C++), RPM (yum/dnf), Debian/APT. Плюс Helm-чарты через OCI, карантин свежих пакетов (Min Release Age), блокировка уязвимых версий (CVE Blocking) и лицензия MIT.

В этой статье мы развернём NORA в Kubernetes на Yandex Managed Kubernetes, а затем попробуем все основные сценарии использования.

У каждого, кто работает с Kubernetes, рано или поздно возникает потребность «посмотреть на кластер глазами»: кто с кем связан, почему под в CrashLoopBackOff, что изменилось за ночь, какие сертификаты истекают. Вариантов обычно два — Kubernetes Dashboard (слишком бедный) или Lens / Headlamp (десктопное приложение или тяжёлый стек с зависимостями). А kubectl-специалисты откапывают причины инцидентов в простынях YAML, где сигнал тонет в managedFields и status.conditions.

Radar — open-source UI для Kubernetes от Skyhook (YC W23). Один бинарник на Go, без регистрации и аккаунта, бесплатный навсегда. Топология кластера, браузер ресурсов, timeline событий, менеджер Helm-релизов, GitOps для FluxCD, карта трафика, аудит безопасности, анализ impact'а перед апгрейдом K8s и даже встроенный MCP-сервер, чтобы ИИ-агенты могли смотреть кластер глазами Radar вместо сырого kubectl.

В этой статье мы развернём Radar в Yandex Managed Kubernetes через Helm — с ingress-nginx и доменом из публичного IP — и разберём все основные экраны. Разворачиваемый инстанс — общий для команды разработчиков, поэтому конфигурация строго read-only: все write-права выключены, ИИ-агенты подключаются к read-only MCP.

Flux CD — это набор инструментов для GitOps в Kubernetes. Он следит за Git-репозиторием и автоматически приводит состояние кластера в соответствие с описанными в нём манифестами и Helm-чартами. Flux работает как контроллер внутри кластера: подтягивает изменения из Git, применяет их через Kubernetes API и отслеживает статус каждого ресурса. Проект является graduated-проектом CNCF.

Когда вы впервые поднимаете GitOps в Kubernetes, Flux CD кажется достаточным: flux bootstrap, манифесты в Git, контроллеры тянут состояние кластера.

Но лучше перейти на Flux Operator:

OpenCost — open-source проект для расчёта и визуализации стоимости ресурсов в Kubernetes. Он агрегирует данные об использовании CPU, памяти и диска (ноды, поды, PVC), применяет к ним тарифы и даёт метрики и API для отображения затрат по namespace, deployment, label и т.д. Изначально создан в Kubecost, затем выделен в отдельный проект под CNCF; поддерживает кастомные цены и интеграцию с разными облаками и он-прем-кластерами.

Цель проекта — проверить отказоустойчивость Strimzi Kafka в Kubernetes с помощью chaos-экспериментов (Chaos Mesh). Для этого разворачивается полный стенд: кластер Kafka (KRaft, 3 контроллера + 3 брокера), мониторинг (VictoriaMetrics K8s Stack, Grafana), сбор логов (VictoriaLogs), верификация сквозной доставки сообщений через Redis и Go-приложения producer/consumer. Затем последовательно применяются chaos-сценарии (pod-kill, network partition, CPU/memory stress, IO/DNS/JVM/HTTP chaos и др.) и проверяется, что кластер корректно восстанавливается без потери данных.

Цель этой статьи — восполнить пробел в документации связки Strimzi Kafka и мониторинга. У Strimzi есть раздел про метрики и Prometheus и примеры в репозитории (examples/metrics/prometheus-install), но они рассчитаны на общий Prometheus Operator; пошагового руководства именно под Helm-чарт kube-prometheus-stack (с порядком установки и нужными label’ами) в открытом доступе не нашлось. Ниже — собранный и проверенный вариант такой установки.

Цель статьи: Показать на практическом примере, как использовать один Load Balancer для приёма TLS-соединений и маршрутизации бинарного трафика к разным backend‑приложениям с терминацией (расшифровкой) TLS на Gateway — например, к Redis и другим TCP‑сервисам.

Как это работает:

Руководство по развёртыванию и использованию VictoriaLogs в Kubernetes. Документ фокусируется на практических шагах: установка через Helm, интеграция с cert-manager и Ingress, генерация логов, примеры запросов в LogsQL и интеграция с экосистемой наблюдаемости.

Настроить сервер FreeIPA (систему управления идентификацией) с использованием собственного (внешнего) корневого сертификата вместо самоподписанного.

Эта инструкция представляет собой полное руководство по развертыванию отказоустойчивого кластера HashiCorp Vault в Kubernetes и настройке двухуровневой Public Key Infrastructure (PKI). Корневой сертификат и промежуточный CA создаются через OpenSSL, но промежуточный импортируется и настраивается в Vault для повседневного выпуска сертификатов. Инфраструктура интегрируется с cert-manager для автоматического управления жизненным циклом TLS-сертификатов.

Эффективный мониторинг является краеугольным камнем надежности любой IT-системы, позволяя своевременно выявлять возникающие проблемы. Однако само по себе обнаружение проблемы – это лишь полдела. Не менее важна быстрая и скоординированная реакция команды. Инструменты вроде Alertmanager и Grafana OnCall играют ключевую роль в автоматизации процесса оповещения и управления инцидентами. В этой статье мы подробно рассмотрим, как выстроить цепочку взаимодействия между различными компонентами системы мониторинга и оповещения, чтобы каждый инцидент автоматически отслеживался от момента его фиксации правилом мониторинга до доставки уведомления ответственному инженеру в мессенджер, например, Telegram.

При работе с кластерами PostgreSQL, особенно в конфигурациях с высокой доступностью (High Availability, HA), разработчики часто сталкиваются с ошибками типа "cannot execute INSERT in a read-only transaction". Эти ошибки возникают, когда приложение пытается выполнить операцию записи на узел, который в данный момент является репликой (read-only). Особенно остро эта проблема проявляется в моменты переключения мастера: пул соединений вашего приложения может все еще содержать коннекты к бывшему мастеру, ставшему репликой, или же балансировщик может направить новый запрос на запись к реплике.

К счастью, драйверы PostgreSQL предоставляют элегантное решение этой проблемы – параметр строки подключения target_session_attrs. В версии PostgreSQL 14 были добавлены новые значения для target_session_attrs: read-only, primary, standby и prefer-standby. Этот параметр позволяет указать, какого типа сессию ожидает ваше приложение. Наиболее полезным значением для приложений, выполняющих операции чтения и записи, является read-write. В этой статье мы подробно разберем, почему это так важно, продемонстрируем проблему на практике и покажем, как target_session_attrs=read-write спасает ситуацию. Использование target_session_attrs=primary, включая его специфические отличия от read-write, будет подробно рассмотрено далее в статье.

При использовании GitLab CI/CD с Kubernetes возникает необходимость видеть связку между логами и конкретными CI job'ами или pipeline'ами. Это особенно полезно для отладки и мониторинга. Однако по умолчанию логи из подов не содержат этих связующих метаданных.

В данной статье мы покажем, как можно передавать метки job_id, pipeline_id, project_name и другие из GitLab Runner в систему логирования VictoriaLogs с помощью Promtail и систему мониторинга VictoriaMetrics.

Pyroscope — это мощный инструмент непрерывного профилирования, созданный для мониторинга производительности приложений в реальном времени. В этой статье мы рассмотрим, как быстро развернуть Pyroscope, подключить к нему Node.js приложение и проанализировать поведение кода без использования Grafana Alloy.

Sentry — это инструмент для отслеживания ошибок и производительности приложений в реальном времени.

Кратко о Sentry: что это, зачем он нужен

— Отслеживает баги и exceptions в бекенд, веб и мобильных приложениях.

Для кого этот пост

— Этот пост для тех кто хочет перейти с Sentry в docker‑compose

— Для тех кто хочет перейти с Nodestore в PostgreSQL

Elasticsearch — это распределённая поисковая и аналитическая система для обработки больших объёмов данных в реальном времени. В этом посте будет рассмотрено развертывание Elasticsearch в Kubernetes через оператор ECK (Elastic Cloud on Kubernetes), который упрощает управление жизненным циклом кластера. Для эффективного мониторинга работы Elasticsearch будет использоваться связка Prometheus и специального экспортёра метрик. Экспортёр собирает ключевые показатели (индексация, поисковые запросы, использование ресурсов) и делает их доступными для Prometheus через ServiceMonitor. Конфигурация включает настройку аутентификации, SSL-сертификатов для безопасного соединения и томов для хранения данных. Так же будет рассмотрен бекап и восстановление индексов.