Внедрение Murre для непрерывного мониторинга контейнеров Kubernetes.

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

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

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

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

Инструменты мониторинга обычно сосредоточены на сборе и агрегировании метрик. Но для получения информации об использовании ЦП и МЭМ узлами, модулями и контейнерами в кластере Murre, инструмент мониторинга Go с открытым исходным кодом, не зависящий от зависимостей, работает лучше, чем инструменты в этом списке.

Прежде чем мы изучим Murre, давайте возьмем команды Prometheus + Grafana и kubectl Top в качестве примеров, чтобы увидеть, как работают инструменты мониторинга, не зависящие от зависимостей, и каковы преимущества Murre.

Инструменты мониторинга без зависимостей

Прометей + Графана

Как самое популярное решение для мониторинга Kubernetes, оно помогает нам получить данные об использовании ЦП и памяти соответствующего узла, например node_memory_Buffers_bytes, как показано ниже:

Однако метрики Prometheus должны сопоставлять каждый модуль/контейнер/узел один за другим, а разные ключи показателей для ЦП и MEM делают невозможным интуитивное определение взаимосвязи между модулем и контейнером.

Например, чтобы наблюдать за MEM и ЦП контейнера, вам необходимо настроить container_memory_working_set_bytes и container_cpu_usage_seconds_total соответственно. Кривая обучения для Prometheus также очень крутая, поскольку она требует, чтобы пользователи были знакомы с его ключами метрик и агрегированными функциями (sum, rate и т. д.).

Помимо необходимости установки и настройки, Prometheus и Grafana слишком велики и сложны для мониторинга использования ресурсов.

Кубектл Топ​

Классическая команда kubuctl top позволяет нам просматривать использование ресурсов узла/модуля.

Эта команда требует, чтобы metrics-server был правильно настроен и работал на сервере.​

Во-первых, нам нужно установить метрик-сервер, которого нет в Kubernetes. Но у большинства облачных провайдеров он уже есть по умолчанию, поскольку он необходим для работы как Horizontal Pod Autoscaler, так и Vertical Pod Autoscaler. Однако вам все равно придется установить сервер метрик, если вы вручную настроили кластер Kubernetes.

Теперь мы можем получить раздельное использование ресурсов с помощью kubectl top node и kubectl top pod соответственно.

Что касается дефектов, один из них заключается в том, что он зависит от сервера метрик или команда выдает ошибку Metrics API not available. А установка по умолчанию 100 м ЦП и 200 МБ памяти может работать без сбоев только в том случае, если в кластере менее 100 узлов и 70 модулей на узел. Во-вторых, он не показывает использование ресурсов контейнера; он каждый раз отображает только последнее использование ресурсов модуля и узла и не может постоянно обновляться.

Как собираются показатели

И Prometheus, и kubectl top могут в определенной степени удовлетворить наши потребности. Но если копнуть глубже, то видно, что Prometheus зависит от kube-state-metrics, а top зависит от metrics-server, оба из которых используют API метрик. Что касается их различий, metrics-server фокусируется на чтении данных на уровне кластера, а kube-state-metrics фокусируется на чтении данных для разных типов ресурсов, например, развертываний и реплик.

Мониторинг без зависимостей с помощью Murre с открытым исходным кодом

Я использовал команду top для отладки использования ресурсов узла и модуля, прежде чем нашел Murre, инструмент с открытым исходным кодом без зависимостей, который определенно более эффективен.

Murre показывает использование ресурсов модулями и контейнерами в каждом пространстве имен и обновляет их в режиме реального времени. И он также поддерживает сортировку по CPU/MEM.​

Единственное, что нужно, это установить Murre, но не какие-либо зависимости, в кластер. Поскольку он не полагается на APIServer, а получает информацию о модулях/контейнерах в режиме реального времени через client-go, он форматирует и отображает то, что он получает в терминал (точно так же, как реализованы плагины kubectl). Установка очень проста:

go install github.com/groundcover-com/murre@latest

Код легко разжевывается и усваивается: логика получения метрик заключается в функции GetContainers в fetcher.go, получении PodList и обходе контейнеров.​

Регулярные обновления делаются с помощью Go timer.Ticker + select и могут быть настроены с помощью параметра --interval. ​

Заключение

В этой части мы рассмотрели мониторинг K8s без зависимостей и его сравнение с мониторингом без зависимостей. Murre — эффективный инструмент для наблюдения за использованием ресурсов модулями и контейнерами без установки каких-либо зависимостей в кластере. Хотя он все еще находится на начальном этапе и ожидает доработки, я могу представить, что он станет более мощным, когда будет добавлено больше функций, таких как отображение показателей развертывания, реплик, APIServer и т. д.​

Спасибо за прочтение! Оставайтесь с нами, чтобы узнать больше.