мониторинг k8s (1) Установить Prometheus

Kubernetes

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

  1. Мониторинг k8s (2) Мониторинг компонентов и модулей кластера
  2. мониторинг k8s (3) prometheus-adapter
  3. k8s мониторинг (4) мониторинг хоста

Для мониторинга k8s нам необходимо выполнить следующие пункты:

  • контролировать сам мастер/узел;
  • Мониторинг компонентов кластера apiServer, etcd и т.д.;
  • Отслеживайте модули, которые требуют внимания;
  • Пользовательский мониторинг, включая jmx и т.д.

С этими индикаторами мониторинга нам также необходимо сделать следующее:

  1. Сформулировать соответствующие правила тревоги;
  2. Предоставьте соответствующий веб-хук для подачи сигнала тревоги;
  3. Разверните grafana для графического отображения;
  4. Мониторинг высокой доступности связанных компонентов;
  5. Объединить с k8s metrics-server.

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

Почему бы не использовать prometheus-operator

Для удобства coreos предоставляетprometheus-operatorТакой продукт, который обертывает Prometheus, а также предоставляет четыре настраиваемых типа k8s (CustomResourceDefinitions), позволяя вам завершить добавление новых правил мониторинга (задания) и предупреждений путем определения манифестов без ручного управления Prometheus. Файл конфигурации делает весь процесс более k8s.

И на этой базе тоже запустили coreoskube-prometheusЭта обновленная версия, основанная на prometheus-operator, обеспечивает высокую доступность Prometheus и Alertmanager, предоставляет node-exporter для мониторинга узлов, а также адаптер Prometheus и графаны API-интерфейсов Kubernetes Metrics, позволяющие реализовать развертывание в один клик.

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

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

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

Вы можете использовать kube-prometheus напрямую, если используете его просто. Но если вы хотите понять его принципиальную часть или иметь свои собственные индивидуальные требования, тогда делайте это нативно.Все, что может реализовать prometheus-operator, может быть реализовано нативно.

Как это сделать

Эта статья начнется с 0 и постепенно завершит начальные требования к мониторингу. Даже если вы все еще хотите использовать kube-prometheus, после того, как вы прочитаете все мои статьи, у вас не будет препятствий для его использования.

Все, что нам нужно сделать, это развернуть образ Prometheus на k8s и использоватьkubernetes_sd_configПолный мониторинг k8s. Конечно, prometheus-operator делает то же самое.

Хотя Prometheus может обнаружить все поды в кластере k8s, ip у подов изменится в любой момент, и если вы обнаружите все поды, вы не сможете их классифицировать и управлять ими, что будет очень грязно.

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

Я загрузил все файлы в статье наGitHub, вы можете клонировать его напрямую, без частого копирования и вставки.

Версия k8s в этой статье — 1.14.2, которая устанавливается вместе с kubeadm. Кроме того, эта статья не будет слишком много вводить в Prometheus, а это значит, что вам нужно иметь определенную основу Prometheus.

Страница метрик запроса kubelet

Всем должно быть ясно, что если приложение хочет, чтобы Prometheus отслеживал его, оно должно предоставить URL-адрес. После доступа к этому URL-адресу все элементы мониторинга будут напечатаны построчно в виде текста, и Prometheus получит доступ к этому URL-адресу для получения все данные мониторинга. , этот uri по умолчанию имеет значениеhttp[s]://IP:PORT/metrics.

Поскольку Prometheus стал стандартом, все компоненты k8s обеспечивают/metricsэтот URL. Для некоторых мониторинга на уровне хоста или приложений, которые не предоставляют этот URL-адрес, вы можете использовать промежуточный продукт, который собирает метрики мониторинга, связанные с приложением, а затем предоставляет этот URL-адрес для сбора Prometheus.

Этот продукт называется XXX_exporter, например, node_exporter, jmx_exporter и т. д., официальныйзаписаноСуществует множество экспортеров, как официальных, так и неофициальных, и вы также можете реализовать их самостоятельно с помощью клиентской библиотеки, которую они предоставляют.

Так как Prometheus может собирать через http, это можно сделать и через curl. Поэтому, прежде чем использовать Prometheus для сбора, я воспользуюсь командой curl для вывода всех данных индикатора, которые необходимо собрать, чтобы у всех было хорошее представление.

Конечно, поскольку он находится в среде k8s, некоторые метки будут прикреплены к индикаторам мониторинга после их сбора, например, пространство имен, в котором он находится, служба, к которой он принадлежит, имя пода и ip-порт. и т. д. Вы также можете добавлять или не добавлять эти метки.

Без лишних слов давайте взглянем на данные метрик kubelet. Сначала создайте каталог для хранения всех последующих файлов манифеста:

mkdir -p /opt/kube/prometheus

Сначала создайте пространство имен, в котором будут размещены все ресурсы, связанные с мониторингом:

# vim 00namespace.yml
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring

# kubectl apply -f 00namespace.yml

Мы знаем, что модули создаются kubelet, поэтому kubelet предоставляет соответствующие показатели модулей (включая используемый процессор, память, трафик и т. д.) Теперь мы можем посетить страницу показателей kubelet, чтобы узнать, какие показатели доступны.

Как демон, kubelet по умолчанию прослушивает порт 10250, поэтому к нему можно получить доступ непосредственно на мастере или узле:

# curl https://127.0.0.1:10250/metrics/cadvisor -k
Unauthorized

в:

  • должен использовать https;
  • metrics/cadvisorэто индикатор мониторинга, связанный с kubelet pod, он также имеетmetrics, который является индикатором мониторинга самого kubelet;
  • -kУказывает, что сертификат kubelet не проверен, так как весь кластер использует самоподписанные сертификаты, поэтому нет необходимости в проверке;

Вышеизложенное говорит о том, что у нас нет аутентификации и мы не можем видеть данные индикатора. Аутентификация очень проста, достаточно использовать токен, поэтому сначала нам нужно создать этот токен. Всем должно быть понятно, что когда мы создаем serviceAccount, k8s автоматически сгенерирует для него секрет, и этот секрет имеет информацию о токене.

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

Затем нам нужно создатьprometheus-clusterRole.yml,prometheus-clusterRoleBinding.ymlиprometheus-serviceAccount.ymlЭти три файла, их содержимое следующее.

prometheus-clusterRole.yml:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-k8s
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/metrics
    verbs:
      - get
  - nonResourceURLs:
      - /metrics
    verbs:
      - get

prometheus-clusterRoleBinding.yml:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-k8s
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-k8s
subjects:
  - kind: ServiceAccount
    name: prometheus-k8s
    namespace: monitoring

prometheus-serviceAccount.yml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-k8s
  namespace: monitoring

Таким образом, мы создали ServiceAccount с именем prometheus-k8s.Этот ServiceAccount можно использовать не только для получения метрик мониторинга kubelet, но и Prometheus будет использовать этот serviceAccount для запуска позже.

kubectl apply -f prometheus-clusterRole.yml
kubectl apply -f prometheus-clusterRoleBinding.yml
kubectl apply -f prometheus-serviceAccount.yml

После завершения создания будет автоматически сгенерирован секрет, содержащий токен:

# kubectl -n monitoring get secret
NAME                         TYPE                                  DATA   AGE
prometheus-k8s-token-xmkd4   kubernetes.io/service-account-token   3      3h26m

Получить токен:

token=`kubectl -n monitoring get secret prometheus-k8s-token-xmkd4 -o jsonpath={.data.token} | base64 -d`

Затем используйте этот токен для доступа к странице метрик kubelet:

curl https://127.0.0.1:10250/metrics/cadvisor -k -H "Authorization: Bearer $token"

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

Вы можете видеть, что в нем много индикаторов таких меток:

{container="",container_name="",id="/system.slice/tuned.service",image="",name="",namespace="",pod="",pod_name="",state="stopped"}

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

кубелет кроме/metrics/cadvisorВ дополнение к этому URL есть еще один/metrics, который является собственной метрикой мониторинга, а не pod'а. Честно говоря, не могу разобраться в данных в нем, и раздумываю, получать или нет.

Таким образом, вы сможете получить доступ к нескольким другим компонентам k8s, но etcd не сможет, ему необходимо проверить сертификат клиента.

Страница метрик запроса etcd

URL-адрес страницы метрик etcd также/metrics, но вам нужно будет предоставить сертификат, если вы хотите получить к нему доступ, так как он проверит сертификат клиента. Конечно, вы можете передать его параметры запуска--listen-metrics-urls http://ip:portСделайте так, чтобы страница показателей мониторинга использовала http вместо https, чтобы вам не нужно было предоставлять сертификат.

Хотя etcd развернут в контейнере, но из-за использованияhostNetwork, поэтому мы можем получить к нему доступ, напрямую обратившись к порту 2379 мастера. По умолчанию он использует https, поэтому нам нужно предоставить его одноранговый сертификат. Если k8s установлен с помощью kubeadm, сертификат etcd находится в/etc/kubernetes/pki/etcd/Под содержанием.

Итак, команда для доступа к etcd:

curl https://127.0.0.1:2379/metrics --cacert /etc/kubernetes/pki/etcd/ca.crt --cert /etc/kubernetes/pki/etcd/healthcheck-client.crt --key /etc/kubernetes/pki/etcd/healthcheck-client.key

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

Установить Прометей

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

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

Конфигурационный файл прометея

Сначала создайте файл конфигурации Prometheus configmapprometheus-config.yml, его содержание следующее:

apiVersion: v1
data:
  prometheus.yml: |
    global:
      evaluation_interval: 30s
      scrape_interval: 30s
      external_labels:
        prometheus: monitoring/k8s
    rule_files:
    - /etc/prometheus/rules/*.yml
    scrape_configs:
    - job_name: prometheus
      honor_labels: false
      kubernetes_sd_configs:
      - role: endpoints
        namespaces:
          names:
          - monitoring
      scrape_interval: 30s
      relabel_configs:
      - action: keep
        source_labels:
        - __meta_kubernetes_service_label_prometheus
        regex: k8s
      - source_labels:
        - __meta_kubernetes_endpoint_address_target_kind
        - __meta_kubernetes_endpoint_address_target_name
        separator: ;
        regex: Pod;(.*)
        replacement: ${1}
        target_label: pod
      - source_labels:
        - __meta_kubernetes_namespace
        target_label: namespace
      - source_labels:
        - __meta_kubernetes_service_name
        target_label: service
      - source_labels:
        - __meta_kubernetes_pod_name
        target_label: pod
      - source_labels:
        - __meta_kubernetes_service_name
        target_label: job
        replacement: ${1}
      - target_label: endpoint
        replacement: web
kind: ConfigMap
metadata:
  name: prometheus
  namespace: monitoring

Кратко объясните содержание этого файла конфигурации: этот файл конфигурации является лишь предварительной версией, вы можете видеть, что в нем есть только одна работа, которая заключается в мониторинге самого Prometheus. Как видите, здесь используетсяkubernetes_sd_configs, используйте эту конфигурацию для автоматического обнаружения узла, службы, модуля, конечной точки, входа в k8s и добавления к нему мониторинга, больше контента можно просматривать напрямуюофициальная документация.

Здесь метод конечной точки используется для обнаружения самого Prometheus.У вас могут возникнуть сомнения.Почему бы напрямую не собрать свой 127.0.0.1:9090? Потому что, учитывая, что Прометеев может быть несколько, даже если их несколько, все они находятся под одной работой.

Конечно, если вам это покажется хлопотным, вы можете напрямую собрать сами без проблем. Затем есть куча конфигураций relabel_configs, и я объясню, что делают эти конфигурации одна за другой.

Сначала посмотрите на первую конфигурацию:

- action: keep
  source_labels:
    - __meta_kubernetes_service_label_prometheus
  regex: k8s

Вы должны знать, что каждый раз, когда создается служба, будет создаваться соответствующая конечная точка, но обнаружение конечных точек prometheus обнаружит все конечные точки в пространстве имен, указанном k8s, так как же убедиться, что Prometheus находит только нужные нам конечные точки? Ответ черезrelabel_configs, вот продолжайте это делать.

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

Здесь не указан URL-адрес, Prometheus соберет URL-адрес по умолчанию./metrics.

Затем посмотрите на следующую конфигурацию:

- source_labels:
    - __meta_kubernetes_endpoint_address_target_kind
    - __meta_kubernetes_endpoint_address_target_name
  separator: ;
  regex: Pod;(.*)
  replacement: ${1}
  target_label: pod

если__meta_kubernetes_endpoint_address_target_kindЗначение Pod,__meta_kubernetes_endpoint_address_target_nameэто прометей-0, плюс;После этого они вместеPod;prometheus-0. Используйте регулярные выраженияPod;(.*)соответствовать ему, то${1}То есть взять первую группу, ее значение равно prometheus-0, и, наконец, присвоить это значение метке пода.

Таким образом, этот раздел конфигурации предназначен для добавления еще одного индекса мониторинга ко всем собранным индикаторам мониторинга.pod=prometheus-0Тег.

если__meta_kubernetes_endpoint_address_target_kindне является Pod, то метка не будет добавлена.

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

Создать это:

kubectl apply -f prometheus-config.yml

Файл правил Prometheus

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

сначала создайтеprometheus-config-rulefiles.ymlфайл со следующим содержимым:

apiVersion: v1
data:
  k8s.yml: ""
kind: ConfigMap
metadata:
  name: prometheus-rulefiles
  namespace: monitoring

Создайте:

kubectl apply -f prometheus-config-rulefiles.yml

роль и привязка ролей

Поскольку Prometheus будет использовать ранее созданный sa (serviceAccount) prometheus-k8s для запуска, то нет возможности просмотреть сервис и конечную точку с текущими разрешениями sa prometheus-k8s.

Мы используемkubernetes_sd_configКонечная точка в основном используется для обнаружения, поэтому у prometheus-k8 должно быть больше разрешений.

Нам нужно создать больше ролей и привязать эти разрешения к sa prometheus-k8s через roleBinding.Причина, по которой не используется clusterRole, заключается в минимизации разрешений.

будет создано здесьprometheus-roleConfig.yml,prometheus-roleBindingConfig.yml,prometheus-roleSpecificNamespaces.yml,prometheus-roleBindingSpecificNamespaces.ymlЭти четыре файла, их содержимое следующее.

prometheus-roleConfig.yml:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-k8s-config
  namespace: monitoring
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - get

prometheus-roleBindingConfig.yml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: prometheus-k8s-config
  namespace: monitoring
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: prometheus-k8s-config
subjects:
  - kind: ServiceAccount
    name: prometheus-k8s
    namespace: monitoring

prometheus-roleSpecificNamespaces.yml:

apiVersion: rbac.authorization.k8s.io/v1
items:
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: prometheus-k8s
      namespace: default
    rules:
      - apiGroups:
          - ""
        resources:
          - services
          - endpoints
          - pods
        verbs:
          - get
          - list
          - watch
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: prometheus-k8s
      namespace: kube-system
    rules:
      - apiGroups:
          - ""
        resources:
          - services
          - endpoints
          - pods
        verbs:
          - get
          - list
          - watch
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: prometheus-k8s
      namespace: monitoring
    rules:
      - apiGroups:
          - ""
        resources:
          - services
          - endpoints
          - pods
        verbs:
          - get
          - list
          - watch
kind: RoleList

prometheus-roleBindingSpecificNamespaces.yml:

apiVersion: rbac.authorization.k8s.io/v1
items:
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: prometheus-k8s
      namespace: default
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: prometheus-k8s
    subjects:
      - kind: ServiceAccount
        name: prometheus-k8s
        namespace: monitoring
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: prometheus-k8s
      namespace: kube-system
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: prometheus-k8s
    subjects:
      - kind: ServiceAccount
        name: prometheus-k8s
        namespace: monitoring
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: prometheus-k8s
      namespace: monitoring
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: prometheus-k8s
    subjects:
      - kind: ServiceAccount
        name: prometheus-k8s
        namespace: monitoring
kind: RoleBindingList

В приведенных выше разрешениях config используется для чтения карты конфигурации, а последнее — это необходимые разрешения, которые Prometheus использует для обнаружения k8s Наконец, привязка правил используется для привязки всех этих разрешений к prometheus-k8s sa.

Таким образом, когда следующий контейнер Prometheus будет обращаться к серверу API и компонентам в кластере, эти разрешения будут использоваться для доступа.

Окончательное приложение:

kubectl apply -f prometheus-roleBindingConfig.yml
kubectl apply -f prometheus-roleBindingSpecificNamespaces.yml
kubectl apply -f prometheus-roleConfig.yml
kubectl apply -f prometheus-roleSpecificNamespaces.yml

создать пв

Поскольку Prometheus хранит данные на диске, мы должны использовать statefulset, для которого требуется хранилище. Здесь я буду использовать непосредственно nfs. Возможно, вам потребуется создать его, поэтому я не буду упоминать его здесь.

создать первыйprometheus-pv.yml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: prometheus
  labels:
    name: prometheus
spec:
  nfs:
    path: /data/prometheus
    server: 10.1.1.3
  accessModes: ["ReadWriteMany", "ReadWriteOnce"]
  capacity:
    storage: 1Ti

Затем примените:

kubectl apply -f prometheus-pv.yml

создать сервис

У statefulset должен быть headless сервис, а еще нам нужно создать сервис для обнаружения конечных точек.Создание сервиса им как раз соответствует, но нам нужно добавить сервис к этому сервису.prometheus=k8sэтот ярлык.

поэтому создайте файлprometheus-service.yml, его содержание следующее:

apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: monitoring
  labels:
    prometheus: k8s
spec:
  clusterIP: None
  ports:
    - name: web
      port: 9090
      protocol: TCP
      targetPort: web
  selector:
    app: prometheus
  type: ClusterIP

определено вышеapp=prometheusТакой селектор тегов, значит этот тег обязательно должен присутствовать в контейнере Prometheus.

Создайте:

kubectl apply -f prometheus-service.yml

Создать секрет etcd

Если вы не планируете отслеживать etcd, вы можете пропустить его и удалить связанные с секретом монтирования в yml-файле Prometheus ниже.

Просто создайте секрет напрямую:

kubectl -n monitoring create secret generic etcd-client-cert --from-file=/etc/kubernetes/pki/etcd/ca.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.crt --from-file=/etc/kubernetes/pki/etcd/healthcheck-client.key

Для облегчения последующего использования рекомендуется добавить эту команду после--dry-run -o yaml, затем сохраните вывод вprometheus-secret.ymlсередина. потому что добавил--dry-runПосле этого выполняться не будет, также нужно вручную создать:

kubectl apply -f prometheus-secret.yml

Развернуть Прометей

На этом все предварительные работы завершены, и можно напрямую развертывать prometheus. Сначала создайте файлprometheus.yml, его содержание следующее:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app: prometheus
    prometheus: k8s
  name: prometheus
  namespace: monitoring
spec:
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: prometheus
      prometheus: k8s
  serviceName: prometheus
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: prometheus
        prometheus: k8s
    spec:
      serviceAccount: prometheus-k8s
      containers:
        - args:
            - --web.console.templates=/etc/prometheus/consoles
            - --web.console.libraries=/etc/prometheus/console_libraries
            - --config.file=/etc/prometheus/config/prometheus.yml
            - --storage.tsdb.path=/prometheus
            - --web.enable-admin-api
            - --storage.tsdb.retention.time=20d
            - --web.enable-lifecycle
            - --storage.tsdb.no-lockfile
            - --web.external-url=http://example.com/
            - --web.route-prefix=/
          image: prom/prometheus:v2.11.1
          imagePullPolicy: IfNotPresent
          livenessProbe:
            failureThreshold: 6
            httpGet:
              path: /-/healthy
              port: web
              scheme: HTTP
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 3
          name: prometheus
          ports:
            - containerPort: 9090
              name: web
              protocol: TCP
          readinessProbe:
            failureThreshold: 120
            httpGet:
              path: /-/ready
              port: web
              scheme: HTTP
            periodSeconds: 5
            successThreshold: 1
            timeoutSeconds: 3
          resources:
            requests:
              memory: 400Mi
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          volumeMounts:
            - mountPath: /etc/prometheus/config
              name: config
              readOnly: true
            - mountPath: /prometheus
              name: prometheus-data
              #subPath: prometheus-db
            - mountPath: /etc/prometheus/rules/
              name: prometheus-rulefiles
            - mountPath: /etc/prometheus/secrets/etcd-client-cert
              name: secret-etcd-client-cert
              readOnly: true
      volumes:
        - name: config
          configMap:
            defaultMode: 420
            name: prometheus
        - name: prometheus-rulefiles
          configMap:
            defaultMode: 420
            name: prometheus-rulefiles
        - name: secret-etcd-client-cert
          secret:
            defaultMode: 420
            secretName: etcd-client-cert
  updateStrategy:
    type: RollingUpdate
  volumeClaimTemplates:
    - metadata:
        name: prometheus-data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Ti
        volumeMode: Filesystem

Я не буду упоминать базовые знания, связанные со statfulset, но давайте поговорим о нескольких ключевых моментах:

  • --storage.tsdb.retention.time=20dЭтот параметр запуска означает, что данные мониторинга, собранные Prometheus, хранятся только в течение 20 дней, и это значение не должно быть слишком большим. Если исторические данные хранятся длительное время, рекомендуется записывать их в постоянное хранилище, такое как VictoriaMetrics, thanos, influxdb, opentsdb и т. д.;
  • --web.enable-admin-apiЭтот вариант запуска означает запуск апи администратора, через апи можно удалить данные мониторинга и т.д.;
  • serviceAccountЕго значение должно быть prometheus-k8s, иначе предыдущие операции расширения прав и возможностей будут напрасными;
  • стручок должен существоватьapp: prometheusЭта метка, иначе она не может быть выбрана ранее созданным сервисом;
  • Монтируются два конфигмапа, секрет и том хранилища.

Больше нечего сказать, просто сделайте это:

kubectl apply -f prometheus.yml

Затем дождитесь успешного запуска Prometheus:

kubectl -n monitoring get pod -w

Посетите Прометей

После успешного запуска к нему можно получить доступ напрямую, вместо создания ingress мы привязываем порт пода к хосту:

kubectl -n monitoring port-forward --address 0.0.0.0 pod/prometheus-0 9090:9090

Затем вы можете открыть страницу Prometheus, обратившись к порту 9090 текущего хоста. Мы нажимаем «Статус», а затем выбираем «Цели», чтобы обнаружить, что сам Prometheus отслеживается.

Как видите, он показывает еще 6 вкладок, это те, которые мы пропустили ранее.relabel_configsКонфигурация прилагается.Теперь, пока вы будете запрашивать любой индикатор мониторинга в Prometheus, будут эти 6 ярлыков. Если вы чувствуете, что вам не нужны какие-либо из этих тегов, просто удалите соответствующую конфигурацию в предыдущей конфигурации.

Затем вы наводите мышь на эти теги, и вы можете увидеть все метатеги до перемаркировки.Если вам это нужно, вы можете добавить соответствующую конфигурацию в предыдущий файл конфигурации и добавить соответствующие теги.

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

Как видите, существуют дополнительные 6 тегов, и вы можете запрашивать их в будущем.

Наконец, создайте вход для Prometheus с именем файла prometheus-ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prometheus
  namespace: monitoring
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            backend:
              serviceName: prometheus
              servicePort: 9090

Обратите внимание, что вместо example.com выше укажите ваше доменное имя Prometheus.