Три ошибки с метриками Kubernetes в PromQL, которые проще не допускать, чем исправлять

Запрос в PromQL может выглядеть просто, но скрывать подводные камни. Например, он должен возвращать сведения об использовании памяти пода, но выдает ошибку.

container_memory_working_set_bytes{pod="agency-dashboard-api-89b7f557c-xd4l7"}

Вот какие ошибки есть в этом запросе.

🔹 Дубликаты временных рядов. Если в запросе не учтены все метки, Prometheus может вернуть несколько значений вместо одного. Например, один и тот же под может быть измерен разными заданиями мониторинга. Решение — уточнять фильтрацию, добавляя ключевые метки.

🔹 Неверная агрегация. Попытка исправить дубли суммированием и усреднением (sum() by (pod) / 2) не решает проблему, а запутывает данные. Прежде чем агрегировать, стоит разобраться, почему появились дубликаты.

🔹 Pause-контейнеры. В Kubernetes у каждого пода есть вспомогательный контейнер Pause. Если запрос не фильтрует его, метрики будут включать лишние значения. Добавляем условие container!="" — и дубликаты исчезают.

Мы разобрали ошибки на конкретном примере, но эти же принципы можно использовать и в других запросах.

#DevOps #Kubernetes
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Почему стоит изучить туториалы перед работой с облаками, даже если вы опытный инженер

Российский рынок облачных услуг растет стремительно — только за 2024 год он прибавил 36,3% и достиг 165 млрд рублей. На фоне миграции бизнеса в облака все чаще возникает вопрос — как адаптироваться к новой платформе без сбоев и неожиданных ограничений?

Один из ответов — туториалы и обучающие материалы от облачных провайдеров.

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

Почему это важно даже опытным пользователям?

🔹 Разные облака — разные подходы. Даже если специалист много лет работал, скажем, в Azure, это не гарантирует безошибочную работу в другой среде. Отличия могут быть в терминологии, логике организации сервисов, поведении балансировщиков, принципах расчета ресурсов.

🔹 Комплексное понимание. Туториалы не просто дают обзор интерфейса, а объясняют, как лучше конфигурировать окружение, безопасно перенести данные, выстроить CI/CD или организовать хранение объектов с учетом нюансов платформы.

🔹 Практика и тест-драйв. В ряде туториалов есть практические задания — они позволяют протестировать функциональность до запуска проекта, убедиться в работоспособности и понять, какие сценарии действительно поддерживаются.

🔹 Сертификация. Многие провайдеры выдают сертификаты по итогам обучения. Это полезно как для личного профессионального роста, так и для валидации компетенций внутри команды. Особенно для интеграторов и пресейл-инженеров, которые работают с заказчиками.

Туториалы — это не курс «для начинающих». Обычно они рассчитаны на то, что у пользователя уже есть базовые знания: как устроены ВМ, что такое S3, какие задачи решает Kubernetes.

Задача туториала — не объяснить основы, а показать, как именно они реализованы в конкретном облаке.

Если вы хотите сэкономить время и ресурсы на этапе миграции или развертывания новых сервисов, лучше заранее изучить гайд от провайдера. Это не формальность, а база для продуктивной работы с инфраструктурой.

#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Как работать с Kubernetes и не тратить лишнего: чек-лист для ИТ-команд

По данным VK Cloud, K8s используют 56% компаний, работающих с оркестраторами, и 53% из них — в облаке. Но популярность не гарантирует экономичность: неоптимальная архитектура, неаккуратная работа с ресурсами и лишние нагрузки могут дорого обойтись. Делимся практиками, которые помогут сэкономить без потери стабильности.

🔹 Архитектура. Если приложение еще в разработке, заложите микросервисную архитектуру. Так K8s будет работать эффективно «из коробки». Следуйте рекомендациям The Twelve-Factor App: собирайте минимальные образы, тестируйте нагрузки, используйте облачные PaaS.

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

🔹 Автомасштабирование. Фиксированные мощности без нагрузки — главный источник перерасхода. Вместо этого используйте:

‎🔹 HorizontalPodAutoscaler (HPA) — функция автомасштабирования в K8s, которая подстраивает число подов под нагрузку.
🔹 Автомасштабирование worker-групп — регулирует количество нод в зависимости от активности. Не забудьте задать верхние лимиты, чтобы избежать скачкообразного роста расходов при ошибках или DDoS.

🔹 Режим Spot и работа с данными. Для разовых задач и stateless-сервисов лучше использовать Spot-инстансы. Экономия составит до 90%, если учесть риски отключения. Данные храните вне контура Kubernetes — например, в S3-хранилище, чтобы не переплачивать за ресурсоемкие объемы.

🔹 Оптимизация на уровне кластера

🔹Лимиты и requests для контейнеров — контроль потребления CPU и памяти.
🔹Квоты ресурсов по namespace — предотвращают перерасход на уровне команд.
🔹Правильный размер нод — минимизирует неиспользуемые мощности.
🔹Автоотключение простаивающих кластеров — экономия на ВМ и дисках.
🔹Удаление «мусора» — старые тесты и ненужные данные быстро съедают ресурсы.

🔹 Мониторинг. Используйте OpenCost — Open-Source-инструмент, который показывает, куда уходят ресурсы и как влияют изменения. Разбивка по кластерам, подам, сервисам, namespace — это must-have для контролируемой оптимизации.

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

#vkcloud #kubernetes #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров

Мультиклауд в 2025 году: как выстроить отказоустойчивую инфраструктуру без лишних затрат 🔹

Сегодня 45% российских компаний всё еще используют одну площадку — один ЦОД или одного облачного провайдера. Такой подход удобен, но рискован: единая точка отказа, отсутствие георезервирования, невозможность быстро масштабироваться.

Чтобы снизить риски, компании всё чаще создают «второе плечо» — площадку, на которую можно перенести часть нагрузки или переключиться в случае сбоя.

Вот какие есть варианты архитектур для построения «второго плеча».

🔹 Два физических ЦОДа. Максимальный контроль, но и максимальные затраты. Нужно покупать оборудование, синхронизировать площадки, поддерживать обе. Масштабироваться сложно — только за счет покупки «железа».

🔹 Гибрид: физическая площадка + облако. Один из самых популярных вариантов. Собственная инфраструктура остаётся, облако — как запасной и масштабируемый ресурс. Обеспечивается георезервирование, быстрое восстановление, резервное копирование и масштабирование.

🔹 Мультиоблако (Multicloud). Использование сразу нескольких облачных платформ позволяет избежать привязки к одному вендору, выбрать лучшие сервисы под конкретные задачи и получить отказоустойчивость на уровне провайдеров.

Переход к распределенной инфраструктуре чаще всего начинается именно с облака. И вот почему:

🔹 Развёртывание — за минуты, без закупки оборудования.
🔹 Масштабируемость. Без запасов — по потребности.
🔹 Доступность сервисов. Облачные платформы предоставляют IaaS, S3, базы данных, резервное копирование и средства мониторинга.
🔹 Безопасность и соответствие требованиям. Можно выстроить архитектуру, которая соответствует ФЗ-152, требованиям ФСТЭК, СКЗИ и другим нормативам.

Мультиклауд — не хайп, а необходимость. Построение распределённой инфраструктуры с использованием облака помогает снизить риски, повысить доступность и адаптироваться к любым нагрузкам.

#vkcloud #devops
@digitize_IT — мнения и управленческий опыт ИТ-лидеров