Внедрение 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 и т. д.
Спасибо за прочтение! Оставайтесь с нами, чтобы узнать больше.