Мониторинг Kubernetes ingress и service mesh. Что смотреть кроме CPU и RAM

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

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

В современных Kubernetes-кластерах значительная часть проблем возникает на уровне сетевой инфраструктуры — ingress-контроллера и service mesh. Именно поэтому их мониторинг становится не менее важным, чем наблюдение за самими приложениями.

Почему CPU и RAM уже недостаточно

Представим ситуацию.

Все Pod'ы работают нормально:

• CPU — 30%;
• память — 50%;
• контейнеры не перезапускаются.

Однако пользователи получают ошибки 502 и 504, а время ответа API выросло в несколько раз.

Причина может находиться вовсе не в приложении.

Например:

• ingress перегружен;
• service mesh долго устанавливает соединения;
• часть запросов постоянно повторяется из-за retries;
• один из upstream-сервисов стал отвечать медленнее.

По системным метрикам подобные проблемы практически незаметны.

Что мониторить в Ingress

Ingress — первая точка входа HTTP-трафика в кластер.

Через него проходят практически все пользовательские запросы.

Поэтому в первую очередь полезно отслеживать:

• количество запросов;
• распределение HTTP-кодов ответов;
• latency;
• количество активных соединений;
• число открытых соединений;
• скорость обработки запросов.

Особое внимание стоит уделять росту ответов 5xx.

Если они появляются именно на ingress, проблема может находиться ещё до приложения.

Например, в балансировке, TLS или маршрутизации.

Latency важнее средней нагрузки

Даже если ingress успешно отвечает на все запросы, время их обработки может постепенно увеличиваться.

Причины бывают разными:

• перегрузка контроллера;
• медленные backend-сервисы;
• проблемы с DNS;
• нехватка сетевых ресурсов;
• большое количество одновременно открытых соединений.

Рост latency часто становится первым сигналом начинающейся деградации системы.

Что даёт Service Mesh

Service mesh (например, Istio или Linkerd) добавляет сетевой уровень между сервисами.

Он позволяет управлять:

• маршрутизацией;
• retries;
• circuit breaker;
• mTLS;
• балансировкой нагрузки;
• сбором телеметрии.

Благодаря этому появляется значительно больше информации о взаимодействии сервисов.

Какие метрики особенно полезны

При использовании service mesh стоит обратить внимание на:

• количество запросов между сервисами;
• процент ошибок;
• время ответа каждого сервиса;
• retries;
• timeout;
• количество разорванных соединений;
• успешность TLS-соединений.

Эти показатели помогают быстро понять, где именно начинается деградация.

Например, если frontend отвечает медленно, service mesh покажет, что проблема находится в сервисе авторизации, а не в самом frontend.

Следите за retries

Автоматические повторные запросы помогают пережить кратковременные сбои.

Но при неправильной настройке они способны значительно увеличить нагрузку.

Представим ситуацию.

Один сервис начинает отвечать медленно.

Service mesh автоматически запускает повторные запросы.

В результате вместо одного запроса появляется три.

Нагрузка возрастает ещё сильнее.

Если при этом мониторить только CPU, причина останется незаметной.

Именно поэтому количество retries считается одной из важных метрик распределённых систем.

Ошибки маршрутизации

Не все ошибки связаны с самим приложением.

Например:

• неверные правила ingress;
• ошибки VirtualService;
• неправильные DestinationRule;
• отсутствие доступных endpoint;
• проблемы с сертификатами.

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

Мониторинг сетевого слоя позволяет обнаружить подобные проблемы значительно быстрее.

Почему полезен внешний мониторинг

Даже самый подробный мониторинг Kubernetes показывает происходящее только внутри кластера.

Однако пользователя интересует совсем другой вопрос: открывается ли сервис и насколько быстро он отвечает.

Поэтому внутренние метрики полезно дополнять внешним мониторингом.

Например, с помощью Statuser можно регулярно проверять доступность HTTP API и веб-приложений из разных локаций, измерять время ответа и получать уведомления о росте latency или появлении ошибок. Такой подход помогает быстро определить, что проблема уже стала заметна пользователям, даже если внутри кластера все поды продолжают работать без перезапусков.

Какие алерты стоит настроить

Помимо CPU и памяти имеет смысл отслеживать:

• рост HTTP 5xx;
• увеличение latency;
• резкий рост retries;
• увеличение timeout;
• отсутствие доступных upstream;
• ошибки TLS;
• изменение доли успешных запросов.

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

Итоги

Ingress и service mesh давно стали важной частью Kubernetes-инфраструктуры, поэтому мониторинг только CPU и RAM уже не даёт полной картины состояния системы.

Метрики запросов, latency, HTTP-коды, retries, timeout, ошибки маршрутизации и взаимодействие между сервисами позволяют гораздо быстрее находить причины деградации и локализовать проблемный компонент.

А сочетание внутреннего мониторинга Kubernetes с внешними проверками доступности помогает видеть систему одновременно глазами инженера и глазами пользователя, что особенно важно для стабильной работы production-сервисов.