мониторинг k8s (3) prometheus-adapter

Эта статья относится к серии мониторинга k8s, остальные статьи:

мониторинг k8s (1) Установить Prometheus
Мониторинг k8s (2) Мониторинг компонентов и модулей кластера
k8s мониторинг (4) мониторинг хоста

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

хорошо, давайте сразу к тексту.

kubernetes apiserver предоставляет два API для мониторинга операций, связанных с метриками:

resource metrics API: предназначен для предоставления показателей мониторинга основным компонентам k8s, таким какkubectl top;
custom metrics API: предназначен для предоставления метрик контроллеру HPA.

kubernetes apiserver используется для предоставления функций kubernetes через restapi для использования другими компонентами, но он предоставляет основные функции. Некоторые функции полезные, но неосновные, что если apiserver должен предоставлять такие функции?

Учитывая эту ситуацию, аписервер kubernetes предоставляет соответствующий апи, но для запроса, дошедшего до этого апи, не обрабатывает его, а перенаправляет на расширенный аписервер. Интересно, что это расширение apiserver может быть разработано кем угодно, если оно соответствует спецификации.

Когда пользователи используют расширенный apiserver, им нужно только зарегистрировать его в kube-aggregator (функция apiserver kubernetes), и агрегатор перенаправит запрос на этот api на этот расширенный apiserver. Конечно, взаимодействие между API-сервером kubernetes и расширенным API-сервером включает в себя множество деталей, поэтому я не буду упоминать об этом здесь.

API метрик ресурсов и API пользовательских метрик являются такими примерами. Kubernetes apiserver предоставляет эти два API, но конкретная реализация не имеет значения.

И цель этой статьи — реализовать их через адаптер Prometheus.

группа API и версия API

Прежде чем внедрять эти два API, давайте поговорим о группах API и версиях API.

Так называемая группа API — это то, что вы выполняетеkubectl api-versionsВозникновение значений, состоящих из группы API и версии API.

# kubectl api-versions
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
...

Их слишком много, здесь перечислены только 5. При первом поступлении регистрация.k8s.io/v1beta1,admissionregistration.k8s.ioгруппа API,v1beta1Указывает свою версию.

Если группа API пуста, это означает основной API, а ресурсы kubernetes предоставляются группой API. Так как же узнать, какие ресурсы предоставляются какими группами API?

воплощать в жизньkubectl api-resourcesВы сможете узнать:

# kubectl api-resources
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                      true         Binding
componentstatuses                 cs                                          false        ComponentStatus
configmaps                        cm                                          true         ConfigMap
endpoints                         ep                                          true         Endpoints
events                            ev                                          true         Event
limitranges                       limits                                      true         LimitRange
namespaces                        ns                                          false        Namespace
nodes                             no                                          false        Node
...

Контента много, здесь перечислены лишь немногие. Вывод - 5 столбцов,NAMEСтолбец — это имя ресурса, и его функция определяетсяAPIGROUPГруппа API для столбца предоставляет.SHORTNAMESСтолбцы — это аббревиатуры для этих ресурсов, а аббревиатуры очень полезны при использовании kubectl.

Из всех результатов, перечисленных выше,APIGROUPВсе пустые, что указывает на то, что эти ресурсы предоставляются основным API. Когда вы видите какую-то роль или clusterRole вapiGroupзначение""Когда , вы должны знать, что все ресурсы, к которым он хочет получить доступ, предоставляются основным API.

Для двух API, которые мы хотим реализовать:

Группа API для API метрик ресурсов:metrics.k8s.io, версия естьv1beta1;
Группа API для пользовательского API метрик:custom.metrics.k8s.io, версия естьv1beta1.

Их группа API и версия API будут использоваться позже для регистрации.

custom metrics API

Давайте сначала поговорим об API пользовательских метрик, а API метрик ресурсов будет размещено позже. Если вы говорите, что вам нужен только API метрик ресурсов, то вы должны посмотреть и на него, потому что оба API реализуются адаптером Prometheus.

API пользовательских метрик полностью подготовлен для HPA v2, потому что v1 может использовать ЦП только в качестве индикатора для горизонтального масштабирования подов, что явно не может удовлетворить потребности пользователей.

Существует несколько реализаций пользовательского API метрик, мы выбрали адаптер Prometheus, потому что у нас уже установлен Prometheus. С адаптером Prometheus, поскольку индикаторы, существующие в Prometheus, можно использовать в качестве условий для HPA, он может удовлетворить все сценарии использования.

В kubernetes 1.14 API-сервер включил уровень агрегации, поэтому нам нужно только установить адаптер Prometheus.

Мы развернем адаптер Prometheus с помощью развертывания и, конечно же, привяжем различные роли к сервисному аккаунту, который его запустил. Поскольку это сам apiserver, он будет прослушивать порт и предоставлять HTTP-сервисы внешнему миру.

Также нам нужно создать для него сервис, когда kubernetes apiserver перенаправит запрос, он отправит запрос в сервис и через сервис доберется до адаптера Prometheus.

Все файлы yml в этой статье сохранены вGitHub, здесь не указан. Файлы, относящиеся к адаптеру Prometheus, находятся в каталоге адаптера. Файлы, используемые API пользовательских метрик:

prometheus-adapter-apiServiceCustomMetrics.yml
prometheus-adapter-apiServiceMetrics.yml
prometheus-adapter-clusterRoleAggregatedMetricsReader.yml
prometheus-adapter-clusterRoleBindingDelegator.yml
prometheus-adapter-clusterRoleBinding.yml
prometheus-adapter-clusterRole.yml
prometheus-adapter-configMap.yml
prometheus-adapter-deployment.yml
prometheus-adapter-roleBindingAuthReader.yml
prometheus-adapter-serviceAccount.yml
prometheus-adapter-service.yml

в:

apiServiceCustomMetrics: используется для предоставления API регистрации, группа APIcustom.metrics.k8s.io, версия естьv1beta1;
apiServiceMetrics: используется для предоставления API регистрации, группа APImetrics.k8s.io, версия естьv1beta1. Это для показателей ресурсов;
roleBindingAuthReader: позволяет расширенному аписерверу читать configMap для проверки подлинности аписервера kubernetes, это не требует подробного изучения;
clusterRoleAggregatedMetricsReader: даmetrics.k8s.ioиcustom.metrics.k8s.ioЛюбой из следующих ресурсов имеет произвольные разрешения;
clusterRoleBindingDelegator: разрешение на привязку, чтобы у адаптера Prometheus было разрешение на отправку запроса SubjectAccessReview на kubernetes apiserver;
clusterRole: адаптер Prometheus должен получить доступ к ресурсам в кластере;
configMap: конфигурационный файл адаптера Prometheus, который является одним из ключевых моментов;
service: kubernetes apiserver сначала отправляет запрос в этот сервис, а затем перенаправляет его в следующий модуль адаптера Prometheus.

Развернуть и протестировать

Многие люди используют ЦС kubernetes для подписи сертификата, а затем используют этот сертификат для предоставления https для адаптера Prometheus. На самом деле в этом нет необходимости, при запуске адаптера Prometheus, если вы не предоставите ему сертификат, он сгенерирует самоподписанный сертификат для предоставления https.

Не имеет значения, является ли этот сертификат доверенным, потому чтоprometheus-adapter-apiServiceCustomMetrics.ymlсуществует в файлеinsecureSkipTLSVerify: trueэтот вариант.

клонировать и развернуть:

git clone https://github.com/maxadd/k8s-prometheus
kubectl apply -f k8s-prometheus/adapter

Проверьте, все ли в порядке с развертыванием, напрямую обратившись к API (возможно, вам придется немного подождать):

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/" | python -mjson.tool
kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytes" | python -mjson.tool

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

Вторая команда выведет все модули в пространстве имен мониторинга.fs_usage_bytesЗначение метрики, если у вас его нет, то тоже проблема с деплоем.

Потому что я внес некоторые изменения в некоторые индикаторы и метки в Prometheus в своей предыдущей статье об установке Prometheus, поэтому, если вы непосредственно используетеофициальныйконфигурации, то проблема точно будет. Содержимое, связанное с конфигурацией, будет упомянуто ниже.

Кроме того, параметры запуска адаптера Prometheus в-vЭквивалентно уровню отладки, чем больше значение, тем более подробным будет выходной журнал, максимальное значение равно 10? Но кажется, что этот журнал не имеет никакого эффекта. .

конфигурационный файл

Формат файла конфигурации адаптера Prometheus следующий (потому что он слишком длинный, поэтому часть перехватывается). Он разделен на две части: первая — это правила, используемые для пользовательских метрик, а другая — resourceRules, используемые для метрик. Если вы используете адаптер Prometheus только для HPA, то resourceRules можно не указывать, и наоборот.

Начнем с правила rules.Под этим правилом существует множество операторов запроса.Функция этих операторов запроса состоит в том, чтобы получить как можно больше индикаторов, чтобы эти индикаторы можно было использовать для HPA.

Другими словами, через адаптер Prometheus вы можете использовать любой индикатор в Prometheus для HPA, но предпосылка заключается в том, что вы должны получить его через оператор запроса (включая имя индикатора и его соответствующее значение). То есть, если вам нужно использовать только одну метрику для HPA, вы можете написать только один запрос вместо использования нескольких запросов, как показано ниже.

rules:
  - seriesQuery: '{__name__=~"^container_.*",container_name!="POD",namespace!="",pod!=""}'
    seriesFilters: []
    resources:
      overrides:
        namespace:
          resource: namespace
        pod: # 官方示例中的这个值为 pod_name，由于我之前将 pod_name 改为了 pod，所以这里也为 pod
          resource: pods
    name:
      matches: ^container_(.*)_seconds_total$
      as: ""
    metricsQuery: sum(rate(<<.Series>>{<<.LabelMatchers>>,container_name!="POD"}[1m])) by (<<.GroupBy>>)
---
resourceRules:
  cpu:
    containerQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>}[1m])) by (<<.GroupBy>>)
    nodeQuery: sum(rate(container_cpu_usage_seconds_total{<<.LabelMatchers>>, id='/'}[1m])) by (<<.GroupBy>>)
    resources:
      overrides:
        instance:
          resource: nodes
        namespace:
          resource: namespace
        pod:
          resource: pods
    containerLabel: container_name

Далее мы объясним его ключевые слова:

seriesQuery: оператор запроса Prometheus, все индикаторы, запрошенные с помощью этого оператора запроса, могут использоваться для HPA;
seriesFilters: запрошенные индикаторы могут быть ненужными и могут быть отфильтрованы. Существует два способа фильтрации:
- is: <regex>: Получить только имя индикатора, соответствующее регулярному выражению;
- isNot: <regex>:
ресурсы: единственное, что запрашивается с помощью seriesQuery, — это индекс. Если я хочу запросить индекс модуля, я должен запросить его имя и пространство имен, в котором он расположен, в качестве метки индекса. Ресурсы — это связать метку модуля. index с типом ресурса k8s. Наиболее часто используемые — это pod'ы и пространства имен. Есть два способа добавить теги, один из нихoverrides, другойtemplate.
- overrides: связывает теги в метриках с ресурсами k8s. В приведенном выше примере метки пода и пространства имен в индикаторе связаны с подами в k8s (и подами, и подами, что совпадает с вашим kubectl get pod/pods) и пространствами имен, поскольку поды и пространства имен принадлежат основному API. group, так что нет необходимости указывать группу API. Когда вы запрашиваете метрики модуля, он автоматически добавит имя модуля и пространство имен в качестве метки к критериям запроса;
  - microservice: {group: "apps", resource: "deployment"}Это означает связать метку микросервиса в индикаторе с ресурсом развертывания в группе приложений API;
- шаблон: в виде шаблона go.
  - template: "kube_<<.Group>>_<<.Resource>>"Написано так, если<<.Group>>для приложений,<<.Resource>>развертывание, то это показательkube_apps_deploymentМетки связаны с ресурсами развертывания;
name: используется для переименования индикатора. Причина переименования метрик заключается в том, что некоторые метрики являются только добавочными, например, метрики, оканчивающиеся на итог. Использовать эти индикаторы как HPA бессмысленно, мы вообще рассчитываем его скорость и используем скорость как значение, тогда название в это время не может заканчиваться на total, поэтому его нужно переименовать.
- совпадения: Сопоставьте имя индикатора с помощью регулярного выражения, которое можно сгруппировать;
- как: значение по умолчанию$1, это первая группа. пустой означает использовать значение по умолчанию.
metricsQuery: это для запроса Prometheus, предыдущий запрос seriesQuery предназначен для получения метрик HPA. Когда мы хотим проверить значение индикатора, нам нужно использовать указанный им оператор запроса. Видно, что оператор запроса использует скорость и группировку, что должно решить проблему добавления только индикаторов, упомянутых выше, а также использует шаблоны.
- Серия: название индикатора;
- LabelMatchers: дополнительные метки, в настоящее время только pod и пространство имен, поэтому нам нужно использовать ресурсы для связывания;
- GroupBy: это имя пода, которое также необходимо связать с ресурсами.

доступ спереди/apis/custom.metrics.k8s.io/v1beta1/Все индикаторы, которые появляются, в этих правилах опрашивается с помощью seriesQuery.Конечно, имена могут быть не совсем такими, как в Prometheus, потому что имя используется здесь для переименования.

На самом деле нет необходимости использовать много индикаторов для HPA, таких как индикаторы самого Prometheus и индикаторы компонентов k8s, но адаптер Prometheus определенно хочет выставить все индикаторы, чтобы вы могли использовать все, что хотите, поэтому его seriesQuery будет столько.

доступ/apis/custom.metrics.k8s.io/v1beta1/namespaces/monitoring/pods/*/fs_usage_bytesЭто запрос через metricsQuery для получения значения метрики каждого модуля.

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

Остальные правила resourceRules используются для метрик ресурсов, есть только два атрибута, cpu и memory, которые делятся на node и pod, которые легко понять. при исполненииkubectl top pods/nodesЭти два оператора запроса выполняются.

На этом пользовательские метрики заканчиваются, и содержание HPA здесь не рассматривается.

resource metrics API

Официальное заявление API метрик ресурсов состоит в том, чтобы предоставить индикаторы мониторинга для основных компонентов k8s, но он предоставляет только индикаторы ЦП и памяти модулей и узлов, и его функции действительно ограничены.

Официально указано, что он может выполнять следующие работы:

HPA: для HPA можно использовать показатели ЦП. Версия HPA v1 может зависеть от этого, сейчас это не имеет значения;
Планирование подов: официальное значение состоит в том, что это расширенная функция, потому что текущее планирование подов вообще не учитывает использование узлов;
Кластерная федерация: то же использование ресурсов, но не используется сейчас;
Dashboard: Drawing, я никогда не пользовался дашбордом и не знаю, насколько он эффективен;
kubectl top: это самая практичная функция.

Подводя итог, можно сказать, что самая большая роль API ресурсных метрик заключается в том, что он позволяет вам использоватьkubectl topЗаказ? Конечно, нам все равно, полезно это или нет, одна из наших целей — развернуть расширенный аписервер для его реализации, а следующим шагом будет выбор расширенного аписервера.

многие люди будут использоватьmetrics serverПредоставьте API метрик ресурсов, а затем используйтеPrometheus adapterПредоставляет API пользовательских метрик. Но на самом деле адаптер Prometheus может полностью поддерживать эти два API, поэтому нам вообще не нужен сервер метрик, достаточно развернуть один адаптер Prometheus.

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

# kubectl -n monitoring top pods
NAME                                  CPU(cores)   MEMORY(bytes)
alertmanager-c8d754fbc-2slzr          1m           15Mi
grafana-74bf6c49f6-lf7vw              7m           50Mi
kube-state-metrics-856448748c-xtdxl   0m           24Mi
prometheus-adapter-548c9b9c4c-mr9zq   0m           39Mi

но выполнитьkubectl top nodeБудет проблема, потому что я будуid='/'Индикаторы были удалены, если вы не хотите восстанавливать эти индикаторы, вы можете прочитать мою следующую статью о сборе индикаторов хоста.

Вот и все для этой статьи, спасибо за прочтение, спасибо!